4 ms·

Why? I.e. why not some sort of Scheme? I absolutely don't meat starting a "holy war", the question is intended purely for sake of learning more about Common Li

Why? I.e. why not some sort of Scheme? I absolutely don't meat starting a "holy war", the question is intended purely for sake of learning more about Common Lisp, what features does it have which make it a right tool for this job in particular.

orthoxerox 6y ago
They had people who knew Common Lisp and garbage collection. Plus Scheme has no batteries included.
- lifthrasiir 6y ago
  But the target language in this case (C++) is also light in terms of batteries. It is most likely that CL was at their disposal and Scheme wasn't.
hajile 6y ago
20 years ago, Common Lisp was a mature, stable environment. Scheme was (and is) much less stable. Even if Scheme were just as mature and stable, I'd guess that Common Lisp would still be an easier choice if the output target was C++. Scheme is rather functional by nature and has a core reliance on things like proper tail calls and continuations. These require elaborate, whole-program compilation so they can be optimized away. A side effect of that kind of in-depth manipulation will necessarily be output code that is far removed from the layout of the original source (making it harder to understand what is happening or hunt down bugs). Common Lisp can do functional things, but the core of the language is much more imperative. You'll wind up writing looping constructs instead of tail calls (tail calls aren't actually part of the spec though some/most implementations support them). CLOS can probably map onto C++ classes without too much trouble as well. These lower-level constructs make it easier to reason about performance. That alone isn't everything. Common Lisp allows you to provide type hints and type specifiers to the compiler. Aside from the speedups they allow in CL, they would certainly make things easier when translating to C++. If that isn't enough of a boost, basically every major CL implementation allows you to define an inline assembly block. These things certainly could be done in Scheme (for example, typed racket), but the reader and unhygenic macros in CL certainly make it easier.

orthoxerox 6y ago

They had people who knew Common Lisp and garbage collection. Plus Scheme has no batteries included.

lifthrasiir 6y ago
But the target language in this case (C++) is also light in terms of batteries. It is most likely that CL was at their disposal and Scheme wasn't.

hajile 6y ago

20 years ago, Common Lisp was a mature, stable environment. Scheme was (and is) much less stable. Even if Scheme were just as mature and stable, I'd guess that Common Lisp would still be an easier choice if the output target was C++. Scheme is rather functional by nature and has a core reliance on things like proper tail calls and continuations. These require elaborate, whole-program compilation so they can be optimized away. A side effect of that kind of in-depth manipulation will necessarily be output code that is far removed from the layout of the original source (making it harder to understand what is happening or hunt down bugs). Common Lisp can do functional things, but the core of the language is much more imperative. You'll wind up writing looping constructs instead of tail calls (tail calls aren't actually part of the spec though some/most implementations support them). CLOS can probably map onto C++ classes without too much trouble as well. These lower-level constructs make it easier to reason about performance. That alone isn't everything. Common Lisp allows you to provide type hints and type specifiers to the compiler. Aside from the speedups they allow in CL, they would certainly make things easier when translating to C++. If that isn't enough of a boost, basically every major CL implementation allows you to define an inline assembly block. These things certainly could be done in Scheme (for example, typed racket), but the reader and unhygenic macros in CL certainly make it easier.