Weekend code warrior project

[ET]

I was looking at Lars Thomas Hansen's ffigen and had some
interesting thoughts.

For those of you who are unfamiliar with lcc, upon which ffigen is
based, (and I was unfamiliar with it until last week), lcc is a free,
retargettable, portable, ANSI C compiler developed at Princeton.
It is fairly recent and has a large community of users.  The developers
now both work at MS in their research division.

Why would a C compiler interest us?  


Foreign function interfaces generally use one of a few strategies:
1.  Compile into the target language, so that native function calls
    and foreign calls are identical.
2.  Attempt to parse the target language.
3.  Use an interface descriptor language.

The problem with the first is that you end up with a C program.
The problem with the second is that you end up with yet another
unmaintained C parser.
The problem with the third is that you have to write IDL files.

Hansen's solution is to modify the back end of a popular C compiler
to make it generate the appropriate link info.  He pointed out that he
doesn't have to maintain the parser and code generator as there is
already an army of C programmers doing it for free.  This is a
fairly compelling argument.

I thought about this for a while, and it occurred to me that if you
can get lcc to generate the ffi info for linking lisp and C, you should be
able to simply compile C into lisp.

My immediate reaction is ``why?  Isn't that the wrong direction?'' Sort
of.
The problem with a lot of C interfaces is that they tend to start invading
the Lisp code.  You have to spend far too much time in `C' world, and you
are essentially forced to have a C substrate.  If you could compile C into
Lisp, however, then the C substrate disappears (provided that the C
primitives,
such as register moves, etc. are provided to the C code).

So here are a few benefits of doing this:
1.  Free C interpreter.  Running interpreted C is trivial in this scheme.
2.  You can import C source code without having an FFI or a standalone
C compiler.
3.  Late-bound ffi.  This is the biggest benefit, I think.  Instead of
compiling
and linking to precompiled stub functions, you could wait until you
attempted
to apply a foreign function.  You could then generate the syntactic form
necessary for the call, run it through the compiler, and eval it on the
fly.
Obviously this would be *really* slow, but after you do this, I would
imagine
that you could cache the resulting code and not take a hit the next time.

Now, here's where I lame out.  I'd like to play with this idea, but I'm
writing
a device driver this week and moving next week, so it would be some time
before I could get to it.  Also, compilers are not my strong point.

SO, anyone with a little free time and a bit of experience want to try
writing a
Lisp (or preferably Scheme) back end to lcc?

~jrm