Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!world!paradigm!gjc
From: gjc@paradigm.com
Newsgroups: comp.lang.lisp
Subject: "fine commercial lisps" vs KCL vs other ways
Message-ID: <1353@paradigm.com>
Date: 2 Nov 90 14:02:11 GMT
References: <1990Oct26.123828.7308@cs.nott.ac.uk> <20220001@hpfcdj.HP.COM>
Organization: Paradigm Associates Inc, Cambridge MA
Lines: 32

You know what would improve the state of the art of lisp implementations
a bit? If somebody wrote a LISP front-end to GCC. 

Really, it should be easier than the C++ stuff that was done with GCC.
Just handle the syntactic and lexical scoping issues (GCC already handles
most of the control construct issues that come up), and *dont* *worry*
about garbage collection.  Pass lisp arguments just like arguments
to C procedures. 

A definite must: Implement numeric declaration optimizations, fixnums
and floats, for expression evaluation, argument passing and return values.

Another must: Translate the names of arguments and local variable symbols
as little as possible, make sure compiled code can be debugged effectively
using GDB.

As far as the GC goes, don't sweat it. I have some minor (in terms of
understandability) extensions to the techniques used in SIOD that handle
the C object vs. C object ambiguity extremely well in practice and while
supporting the more modern lisp data structures.

The result: A production-quality lisp that lives up to the standards of
PDP-10 maclisp and more. A portable lisp with an understandable and
nearly universally supported compiler.

Maybe RMS will spend some of that MacArther money he won on a lisp
front end for GCC.

Or maybe somebody good enough will decide to stop screwing around
with stuff like KCL and go for the brass ring.

-gjc