Generating C code as a "portable assembly language", to take advantage of deeply evolved optimizing C compilers, is a common practice that apparently originated with the first C++ compiler, Cfront. At the time, the technique was not widely understood, and Cfront was often dismissed, sometimes dishonestly, sometimes ignorantly, as "just a preprocessor".
Nowadays, it has become more common to target LLVM, instead, and all our compilers may be similarly dismissed as "just preprocessors" for that. Or not.
So we might wonder why this library does not generate LLVM, instead. One good answer would be that there are still execution targets for which there is an adequate C compiler but no LLVM target.
I was language-lawyering in the comp.lang.c newsgroup in the 1990's and early 2000's.
That bit come up from time to time: "hey you stupid, there is no such language as c/c++!" I participated in that myself, sadly.
Most of the time, it wasn't what the person meant (that there is such a language). Just that they are looking for a solution in either C or C++ or whatever.
(In fact, there is a language that could be plausibly be called "C/C++": useful programs can be written that compile as either C or C++. The easiest way to code that way is to stick to the C90 dialect, and avoid the few C++ incompatibilities that it has. I have considerable experience in this area, that is ongoing.)
In this case, the generator can perhaps be used for C, if C++ features are avoided, so it means C or C++. Just like "if/when" or "he/she".
HN guideline: Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
I stick to the fact. Generally when people use the expression, it is because they have not thought about the meaning, and thinking it through leads them to one of several, more specific, alternatives that the reader could not reliably have chosen correctly among.
It is always better to write what you mean, and not make people guess.
One possibility that I can see is generating code that will run on microcontrollers. While there are some LLVM+microcontroller experiments, I'd say this is probably not an easy way to go. And trying to run some kind of Lisp on a microcontroller will also only get you so far.
Sometimes what you want to generate is code that other people can build upon. For example, given a specification of some message protocol, you could generate classes that represent those messages and can do the parsing/serializing by themselves.
You could generate LLVM code that does that, but the point is integrating the generated code in a bigger project
This looks like an awesome project! Just stumbled upon it myself this week too while looking around for libraries supporting transpilers written in Common Lisp. Looks like one of the more complete ones.
Generating C code as a "portable assembly language", to take advantage of deeply evolved optimizing C compilers, is a common practice that apparently originated with the first C++ compiler, Cfront. At the time, the technique was not widely understood, and Cfront was often dismissed, sometimes dishonestly, sometimes ignorantly, as "just a preprocessor".
Nowadays, it has become more common to target LLVM, instead, and all our compilers may be similarly dismissed as "just preprocessors" for that. Or not.
So we might wonder why this library does not generate LLVM, instead. One good answer would be that there are still execution targets for which there is an adequate C compiler but no LLVM target.