A Summary of Project so far [Why ANSI CL?]
Fri, 23 May 97 20:28:36 +0200
"Dwight Hughes" <firstname.lastname@example.org> wrote:
> There is
> also the practical consideration that there does not seem to be
> a Scheme available that can compile to x86 native code *and* that is
> written almost entirely in Scheme (not C).
IMO this argument shouldn't really be relevant in this case. Scheme is
such a simple language that we can trust to be able to (re-)implement
as much of it as we want, as long as the general model of the system
isn't too bad. Also, a lacking standard about e.g. a module system or
object oriented support shouldn't be a primary problem, as long as we
can reach a consensus for our needs which is sufficiently open-ended
to add the more fancy ideas later (a basic module system is easy with
macros - I'm currently implementing just that).
For an initial period, an implementation generating C source code and
using C for some parts of the run-time support (like garbage collection)
probably wouldn't hurt, and while we're moving towards a native code
backend/runtime, it won't have to be extremely fast immediately. Clever
register allocation and floating point optimization can wait until later.
Any short-term efficiency needs for system-level hacking can most likely
be solved by problem-specific procedures/macros implemented directly at
a lower level (like some form of assembly-in-s-expressions), but using
an interface which allows a (possibly also more general) higher-level
implementation later. We probably don't need a hardware interrupt handler
in 50K lines of Lisp tomorrow.
The really important question is whether we want essentially an Integrated
Common Lisp Machine, or incorporate substantial new language level stuff.
In the former case, hacking CMU-CL is certainly close to what we need.
In the latter case, a language which does already carry too much around
does very easily get into the way - as the recent discussion about an
immutable CONS to Common Lisp should have demonstrated. (Btw, I probably
don't like the role of a language lawyer any more than others around here,
but the mentioned concerns in that debate are hairy real-world porting
problems cut down to a more easily understandable size. If you find such
discussions annoying, I doubt you'll like debugging unexpected problems
with programs assuming something else than your preferences any more.)
-- Marc Wachowitz <email@example.com>