A Summary of Project so far [Why ANSI CL?]

[Marc Wachowitz]

"Dwight Hughes" <dhughes@intellinet.com> 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 <mw@ipx2.rz.uni-mannheim.de>