Re: A Lisp compiler?

["Matthew X. Economou" <xenophon@irtnog.org>]

>>>>> "KR" == Ken Raeburn <raeburn@cygnus.com> writes:

Thanks for the quick reply, Ken.

    KR> Consider targeting languages that would be helpful to the GNU
    KR> project, like Emacs Lisp or (better, IMHO) Guile, which is
    KR> Scheme based.

I believe that Common Lisp is a little more featureful than Emacs
Lisp.  Syntactically, the languages are identical, so building some
kind of library/package that implemented those special forms,
functions, and macros unique to Elisp is (famous last words) "fairly
trivial".

In which case, I'd argue it is better to have the more portable Common
Lisp environment with which to start.

(The same kind of argument goes for GUILE versus R4RS/R5RS Scheme.
It'd be preferable to have the standard (and very powerful) Scheme
environment to begin with, then build up the extension language from
there.  Building an extension language out of some kind of base
language is something the Lisp language family is VERY good at.)

    KR> Translating to C would likely be easier; do you gain much by
    KR> compiling directly?  The generated C code can even be
    KR> platform-independent, meaning it could be shipped along with
    KR> the original lisp source for those who don't have the lisp
    KR> compiler. (E.g., in the Emacs or Guile distributions.)

You may very well be correct, here.  In this case, GNU Common Lisp
already does translate to C.  (GCL follows CLtL1 pretty closely.  It
isn't quite ANSI-compliant, but it is pretty close.  If you're
interested, compiling to C is described in Christian Queinnec's
excellent _Lisp in Small Pieces_, chapter 10.)

Personally, I think machine code generation would be a much cooler
hack, especially since the run-time environment must include
facilities for interpretation (aka EVAL).

    KR> I'd suggest guile over elisp because the lexical scoping plays
    KR> more nicely with such notions as multi-threaded programming.
    KR> Seems to me with multi-threaded lisp, either you have to have
    KR> cooperative threading and wind/unwind the local `let' bindings
    KR> on each thread switch (not consistent with using pre-emptive
    KR> threading packages and other languages), or each variable
    KR> reference may have to walk a list of bindings looking for the
    KR> "most local" value for the variable.  With lexical scoping, a
    KR> `let' binding translates to an automatic variable. This also
    KR> leaves more room for optimization when calling arbitrary
    KR> functions.

I didn't understand a word in this paragraph.  Would you take a shot
at explaining this to me off-list?

    KR> Also, Guile is intended to work as an extension language for
    KR> multiple programs (a la Tcl), so compiling it would
    KR> (eventually, in theory) help people maintaining or extending
    KR> those programs.

No arguments here.  Finding a portable way to interface C (or other
languages) to Lisp (and vice versa) would be a Good Thing, regardless
of the specific Lisp variant being compiled.

    KR> But if there is more to be gained by translating directly to
    KR> assembly, that you couldn't get translating to C (or, say, GNU
    KR> C with one or two new extensions), then go for it.

Does hubris count?  :)

    KR> Certainly the debugging information would be more likely to
    KR> reflect the original code instead of the intermediate C code.
    KR> But then you want gdb support too. :-)

But of course!  And exception handling, and run-time type information,
and... and... and...!  ;)

    KR> This is all just MHO; there are minds on this list more wise
    KR> in the Ways of Many Parentheses than mine.

Me too.  And goddess only knows if this "project" will survive the
month; at this point I'm too ignorant to just give up now.  *wink*

Is there anyone else out there in EGCS-land with comments on yet
another GCC front-end (and run-time system), one that will handle
Common Lisp?

-- 
"BABYLON 5!  A five-mile long cement mixer of truth, pouring out the
 Concrete of Nice-Nice in a long, grey ribbon into the future, to form a
               ***SIDE WALK OF JUSTICE!!***"
                                   - The Tick on Babylon 5