This is the mail archive of the egcs@egcs.cygnus.com mailing list for the EGCS project. See the EGCS home page for more information.
Two thoughts:
1) Consider targeting languages that would be helpful to the GNU
project, like Emacs Lisp or (better, IMHO) Guile, which is Scheme
based.
2) Translating to C would likely be easier; do you gain much by
compiling directly? The generated C code can even be
platform-independent, meaning it could be shipped along with the
original lisp source for those who don't have the lisp compiler.
(E.g., in the Emacs or Guile distributions.)
I'd suggest guile over elisp because the lexical scoping plays more
nicely with such notions as multi-threaded programming. Seems to me
with multi-threaded lisp, either you have to have cooperative
threading and wind/unwind the local `let' bindings on each thread
switch (not consistent with using pre-emptive threading packages and
other languages), or each variable reference may have to walk a list
of bindings looking for the "most local" value for the variable. With
lexical scoping, a `let' binding translates to an automatic variable.
This also leaves more room for optimization when calling arbitrary
functions.
Also, Guile is intended to work as an extension language for multiple
programs (a la Tcl), so compiling it would (eventually, in theory)
help people maintaining or extending those programs. Though I don't
know of many programs using it *yet*, aside from gimp.
I believe there's already a Scheme->C translator available for Guile,
but I don't know the specifics. But if there is more to be gained by
translating directly to assembly, that you couldn't get translating to
C (or, say, GNU C with one or two new extensions), then go for it.
Certainly the debugging information would be more likely to reflect
the original code instead of the intermediate C code. But then you
want gdb support too. :-)
This is all just MHO; there are minds on this list more wise in the
Ways of Many Parentheses than mine.
Ken