4 ms·

"parsed and codegenned" he said. Any Lisp compilers like that?

groovy2shoes 15y ago
I believe that's how the Clojurescript compiler currently works (though I haven't looked at the code in detail). Compilers that don't do it that way usually have optimizations going on in between the parse and codegen phases, not because it's impossible to do with Lisp syntax.
- fogus 15y ago
  ClojureScript has a two-pass compiler; more if you consider GClosure a step.
- xyzzyz 15y ago
  "because it's impossible to do with Lisp syntax." The problem is not with Lisp syntax. The problem is with Lisp's semantics, which makes it much more difficult (if at all possible) to compile in one pass. Things like closures, conditions or macros are absent in Pascal.
ajross 15y ago
No, but only by definition. Passing through an s-expression representation is a requirement for a lisp compiler, because the tree to be compiled might have been built at runtime. Certainly lisp's grammar is no more complicated than pascal's. Nor, frankly, is K&R C, which is is also a very simple representation. The ANSI process added some edge cases that complicated it, but really it's pretty simple.
rayiner 15y ago
I don't know any practical algorithm for handling closures that'll let you code-gen Lisp in one pass, but in general writing Lisp compilers is frightfully easy: http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf
silentbicycle 15y ago
No, but Lua works that way.
- barrkel 15y ago
  It's easy to write very small interpreters, even ones that JIT code. So much so that some approaches to shrinking software have historically been to write a little VM interpreter, and compile the source code to target that rather than the actual CPU. A compiler that produces code that no longer requires a runtime (in the VM sense - inverted control) is slightly more work. Turbo Pascal's code generation was simple and naive. It had little optimization. It literally output the machine code as it parsed. There was no AST, not even an expression tree. (I have the source code to the final version of the Turbo Pascal compiler on my disk. It was used for Delphi 1.)
  - outworlder 15y ago
    >(I have the source code to the final version of the Turbo Pascal compiler on my disk. It was used for Delphi 1.) Is that still under copyright? And chance it could be released?
    - barrkel 15y ago
      As far as I know it is still under copyright. Anders Hejlsberg's name is in the comment headers; it was largely rewritten in 1986 and 1987 for TP4. I believe it belongs to Embarcadero, the company I work for, after they bought the developer tools division from Borland. I have no idea about releasing it. I'm entirely the wrong end of the company to ask about it.

I believe that's how the Clojurescript compiler currently works (though I haven't looked at the code in detail). Compilers that don't do it that way usually have optimizations going on in between the parse and codegen phases, not because it's impossible to do with Lisp syntax.

fogus 15y ago
ClojureScript has a two-pass compiler; more if you consider GClosure a step.
xyzzyz 15y ago
"because it's impossible to do with Lisp syntax." The problem is not with Lisp syntax. The problem is with Lisp's semantics, which makes it much more difficult (if at all possible) to compile in one pass. Things like closures, conditions or macros are absent in Pascal.

ajross 15y ago

No, but only by definition. Passing through an s-expression representation is a requirement for a lisp compiler, because the tree to be compiled might have been built at runtime. Certainly lisp's grammar is no more complicated than pascal's. Nor, frankly, is K&R C, which is is also a very simple representation. The ANSI process added some edge cases that complicated it, but really it's pretty simple.

rayiner 15y ago

I don't know any practical algorithm for handling closures that'll let you code-gen Lisp in one pass, but in general writing Lisp compilers is frightfully easy: http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf

silentbicycle 15y ago

No, but Lua works that way.

barrkel 15y ago
It's easy to write very small interpreters, even ones that JIT code. So much so that some approaches to shrinking software have historically been to write a little VM interpreter, and compile the source code to target that rather than the actual CPU. A compiler that produces code that no longer requires a runtime (in the VM sense - inverted control) is slightly more work. Turbo Pascal's code generation was simple and naive. It had little optimization. It literally output the machine code as it parsed. There was no AST, not even an expression tree. (I have the source code to the final version of the Turbo Pascal compiler on my disk. It was used for Delphi 1.)
- outworlder 15y ago
  >(I have the source code to the final version of the Turbo Pascal compiler on my disk. It was used for Delphi 1.) Is that still under copyright? And chance it could be released?
  - barrkel 15y ago
    As far as I know it is still under copyright. Anders Hejlsberg's name is in the comment headers; it was largely rewritten in 1986 and 1987 for TP4. I believe it belongs to Embarcadero, the company I work for, after they bought the developer tools division from Borland. I have no idea about releasing it. I'm entirely the wrong end of the company to ask about it.