I think parent was more surprised by the idea that one would want a C-to-Lisp compiler, given that Lisp is more pleasant to write than C and C is usually more performant.

The problem with C-in-Lisp, though, is modelling the low-level behavior of C using the high-level concepts of CL.

Case in point: pointer punning. Somebody takes a 'char ', writes some stuff through it, then casts it to an 'int ' and starts reading that stuff back. ZetaLisp, having been built to implement the Lisp Machine OS in, had some low-level features that made this kind of thing doable, but those features did not make it into Common Lisp (I'm thinking of displaced arrays with mixed element sizes, though as I write this it occurs to me that it might be possible to coax an open source CL implementation into dealing with this, if you can give up on the generated code being portable CL).

If you want to look at Zeta-C, the sources and some commentary can be found here: http://wiki.alu.org/Zeta-C

The C standard doesn't actually require as much from the implementation as you might think. Pointer arithmetic and comparison is only defined for pointers into the same array object (including one past the end), so it's completely possible to implement C with bounds-checked fat pointers. The most painful requirement is probably that there is a sufficiently large integral type to represent pointers across round-trip casts. In portable CL that would require you to track all allocated objects with a unique identifier or implement your own heap.

> Case in point: pointer punning. Somebody takes a 'char ', writes some stuff through it, then casts it to an 'int ' and starts reading that stuff back.

That's only a problem when the "stuff" is indeed machine-specific bytes and not something that has type tags already. That happens when you're writing binary data from memory and reading it back in again, and mmaping files, neither of which is portable C code. There are some rules about ints being a larger number of storage units than chars in the C standard, which Vacietis does violate (everything aside from arrays and structs is 1 storage unit), but aside from that the two use cases I mentioned aren't actually required to be supported by C compilers, and they're surprisingly not frequent.

Yeah, the "back-end" is basically 3 pages of code. Most of the C control structures can be implemented with PROG.