Wow, yeah, I'm glad I failed to talk him out of it!
Still, looking at his list of "big things that need to be done" -- this is not yet a general-purpose C compiler.
I should have asked what his goals for the project were. If he wants a compiler that handles all of C and produces code good enough that people would actually want to use it -- say, within a factor of 5 of optimized GCC output -- I think it's still clear that that's a huge project. But if he just wants to port hardware drivers, which appears to be his primary purpose, yeah, I can see that that might not be so hard. Driver code tends not to use the whole language, though it can do some weird low-level stuff like pointer type punning that can be hard to model in CL. And performance is probably not critical for most drivers since they do little computation.
Actually, I started working on one this past weekend as an exercise. The only real work is the front-end; your Lisp compiler itself can serve as the back-end.
It's not all that shocking; Prolog-in-Lisp is a common exercise, and in Let over Lambda there is a chapter about Forth-in-Lisp.
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.
Wow, Mirai. Haven't heard that name in a long time. So many good stuff came out of it. It just wasn't received widely for some reason. I got a demo CD from nichimen with it, I bet I still have it somewhere.
This is Mirai: http://www.youtube.com/watch?v=ubgvomRTW80 Here is Bay Raitt working with it. Note the year. Also note that is the guy that worked on Golum (and later at Valve). Modeling in that video seems like a normal workflow by today's standards, however at the time NURBS/Patch modeling was all the rage and box modeling was a novelty most users were skeptical of. Mirai provided workflow which pushed it onto a new level. Prior to that Lightwave had something similar with its MetaNURBS.
IIRC, it was a time when Maya finally caught on (ver 2 I believe) and new Softimage (codename Sumatra, later XSI) was getting adopted too. Interesting fact is that Softimage bought nichimen's modeling toolset and integrated it into XSI.
So many firsts were spawned from Mirai. Some due to technical achievements/features, some by its users. Bridge poly tool comes to mind, and of course, box modeling pioneered by Bay Raitt and Mirai peers for production. Truly defining time for 3D. A year later we all learned about skybox/GI/FG, and a couple of years later Zbrush came out. Nothing was the same anymore.
ZBrush was an amazing piece of software when it came out. I stopped following developments in 3d graphics around the time that happened, but I remember that most of the remaining Mirai users active on the web back then moved over to it.
Dave Cooper of Genworks (http://www.genworks.com) told me that he met some of the Mirai developers (they're still around: http://www.izware.com/) at a conference not too long ago, and that they're working on the next iteration of Mirai.
A next generation Mirai ? Wow... wasn't even aware that this company trully still exist, since they seem dead for almost 10 years now (no update or anything).
Funny thing is that, since it's in Common Lisp, when there's a problem, you were dumped into the debugger, which was scary... only now do I know that it's an amazing opportunity to access the underlying system in fact !
Ah yes, the mythical Mirai 1.5! I'm afraid nothing will ever come of it. Last update to anything from Izware(nichimen) was in 2005 and even then was a bit of a surprise and it was an update to Nendo. Mirai belongs to the history now. We now have far superior software and features than we had with Mirai, but Mirai was still a cool concept.
I don't see myself ever using Clojure. It's missing too many of the good things from Common Lisp: readtables, imperative constructs (PROG, LOOP, etc.), separate function/variable namespaces. Lispworks and Gambit have better concurrency primitives than Clojure. I've never needed Java interop, interfacing with C libraries is much more important. If I ever go back to doing functional programming it's going to be in Haskell again because it's not worth giving up imperative programming unless you get the combination of static typing and monads in return.
Currently, I develop in Clozure and SBCL alongside, and it's true that SBCL compilation speed (and memory consumption) can be prohibitive at times, but in return it may give up to 3-4 times execution speed increase. So it's a real trade-off worth considering. We now use CCL for interactive development and SBCL on the server.
I don't understand: " I really like Azul Systems' hack of using the EPT/RVI virtualized page tables as a hardware read barrier for real-time garbage collection, and with a single-address space operating system I think you can do the same thing on hardware with a regular MMU."
I understand real-time garbage collection, but what is EPT/RVI virtualized page?
