7 ms·

Consider the case where a compiler compiles Scheme to C via C. The C compiler is available at compile time, but who knows if the user has a C compiler. Such com

Consider the case where a compiler compiles Scheme to C via C. The C compiler is available at compile time, but who knows if the user has a C compiler. Such compilers often solve the problem by using some kind of interpreter at runtime. Compilers that compile directly to machine code do not have similar problems. For fun, do you know a Common Lisp implementation that compiles via C? How do they implement `eval`?

ska 3y ago
Yes that's an obvious problem, but manageable I suppose by installing a toolchain or insisting on one when you install. The post I was replying to was about scheme's in general though, not scheme->c implementations, right? Anything with an intermediate language or machine language output avoids this problem... At any rate, the CL's I've used most have native compilers. I think GCL is CL via c, but can't remember the details of its implementation. In any case 'eval and 'compile are not equivalent, and the system may change whether or not 'eval compiles first or just interprets, depending on settings.
- soegaard 3y ago
  As you point out, it's quite common for Common Lisp compilers to produce machine code directly. In the Scheme world that's more rare and made Chez Scheme stand out. I think, that's what LAC-Tech hinted at - but I am not sure.
  - LAC-Tech 3y ago
    Exactly what I was hinting at (Well i was trying to say it outright but obviously not using the right words!)
  - ska 3y ago
    I've guess I've used MIT and Chez which were native, and chicken and bigloo which are (from memory) going via c. So maybe biased my feeling that native wasn't that unusual. But yes, imprecision in the original may have caused confusion. [update] I was curious, so had a look at https://get.scheme.org/ https://get.scheme.org/ Not sure how complete that list is, but that has 4 native compilers and 3 scheme-to-c, which I guess leaves the other dozen or so interpreted, but that gets muddied with intermediate languages and retargetable (e.g. gambit).
    - soegaard 3y ago
      Great to hear, that it's not rare any longer.
vincent-manis 3y ago
I'm not sure what is meant in this thread by “interpreter”. A Scheme compiler that transpiles to C or JavaScript might “interpret” if neither of these systems is available at runtime. In general, apart from student-written course projects, Scheme systems do some level of compilation (e.g., identifying variables), because this is relatively easy to do, and avoids wasting execution time. Most if not all production Lisp and Scheme systems, if they interpret at all, do so by compiling to an intermediate representation, and interpreting that.
- soegaard 3y ago
  True. On a different tangent, I am suddenly reminded of: https://blog.racket-lang.org/2011/10/on-eval-in-dynamic-languages-generally.html https://blog.racket-lang.org/2011/10/on-eval-in-dynamic-lang...
kazinator 3y ago
Lisps that are based purely on compilation implement (eval form) similarly to this: (funcall (compile nil `(lambda () ,form))) Lisps that are not based purely on compilation can have an eval function that walks the source code and interprets it. Or there could be a VM. So the question is really, how do Lisps that compile to C implement the dynamic compile function? Typically it's all part of the same framework as file compilation. There is a run-time dependency on the C compiler: for run-time compile to work, it has to be installed. The compile function writes something to a file, or perhaps a pipe. The compiler is invoked and produces a .o file; the function then loads that into the image and bind it to a funcall-able object. It's a dependency that's a bit hard to swallow, since a C toolchain is hundreds of megabytes nowadays.

ska 3y ago

Yes that's an obvious problem, but manageable I suppose by installing a toolchain or insisting on one when you install. The post I was replying to was about scheme's in general though, not scheme->c implementations, right? Anything with an intermediate language or machine language output avoids this problem... At any rate, the CL's I've used most have native compilers. I think GCL is CL via c, but can't remember the details of its implementation. In any case 'eval and 'compile are not equivalent, and the system may change whether or not 'eval compiles first or just interprets, depending on settings.

soegaard 3y ago
As you point out, it's quite common for Common Lisp compilers to produce machine code directly. In the Scheme world that's more rare and made Chez Scheme stand out. I think, that's what LAC-Tech hinted at - but I am not sure.
- LAC-Tech 3y ago
  Exactly what I was hinting at (Well i was trying to say it outright but obviously not using the right words!)
- ska 3y ago
  I've guess I've used MIT and Chez which were native, and chicken and bigloo which are (from memory) going via c. So maybe biased my feeling that native wasn't that unusual. But yes, imprecision in the original may have caused confusion. [update] I was curious, so had a look at https://get.scheme.org/ https://get.scheme.org/ Not sure how complete that list is, but that has 4 native compilers and 3 scheme-to-c, which I guess leaves the other dozen or so interpreted, but that gets muddied with intermediate languages and retargetable (e.g. gambit).
  - soegaard 3y ago
    Great to hear, that it's not rare any longer.

vincent-manis 3y ago

I'm not sure what is meant in this thread by “interpreter”. A Scheme compiler that transpiles to C or JavaScript might “interpret” if neither of these systems is available at runtime. In general, apart from student-written course projects, Scheme systems do some level of compilation (e.g., identifying variables), because this is relatively easy to do, and avoids wasting execution time. Most if not all production Lisp and Scheme systems, if they interpret at all, do so by compiling to an intermediate representation, and interpreting that.

soegaard 3y ago
True. On a different tangent, I am suddenly reminded of: https://blog.racket-lang.org/2011/10/on-eval-in-dynamic-languages-generally.html https://blog.racket-lang.org/2011/10/on-eval-in-dynamic-lang...

kazinator 3y ago

Lisps that are based purely on compilation implement (eval form) similarly to this: (funcall (compile nil `(lambda () ,form))) Lisps that are not based purely on compilation can have an eval function that walks the source code and interprets it. Or there could be a VM. So the question is really, how do Lisps that compile to C implement the dynamic compile function? Typically it's all part of the same framework as file compilation. There is a run-time dependency on the C compiler: for run-time compile to work, it has to be installed. The compile function writes something to a file, or perhaps a pipe. The compiler is invoked and produces a .o file; the function then loads that into the image and bind it to a funcall-able object. It's a dependency that's a bit hard to swallow, since a C toolchain is hundreds of megabytes nowadays.