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

[Marc Wachowitz]

Jordan Henderson <jordan@Starbase.NeoSoft.COM> wrote:
> Anything we do in Scheme will involve reinvention of
> a lot of wheels to make the language usable for real-world applications.

If you look at it from the viewpoint of wanting commercial distribution
with the currently available tools, that's probably true. From the view-
point of developing a whole OS with lots of new ideas, I don't think it's
actually such a heavy additional problem - you can adapt or develop most
things on the way, and at least partially by people who can't or don't
want to do kernel-hacking. There's already a lot of stuff around in Scheme,
but it's horribly scattered and implemented for lots of different systems;
thus it would to a large degree be a matter of adaption to a common standard.
For high-level libraries where it makes sense (i.e. where a substantially
different infrastructure doesn't get into the way), one could also cooperate
with the Guile project, and of course develop something useful in the VM
sub-project. All together could end much of the superfluous fragmentation
in the Scheme community, which is to a large degree due to implementations
which aren't too bad in one area, but almost useless for slightly different
purposes.

> I also feel that both Scheme and CL are insufficient to do the low-level
> "Kernel Lisp" that is often discussed here.  From my (naive) review of
> what's available, I think more useful progress can be made toward 
> implementing such things as a "Kernel Lisp" if it were done in CL than
> if it were done in Scheme.

The question is again what you want out of it: Merely some (Common Lisp)
subset of which you know it's implemented efficiently, or a more fundamental
kernel, out of which the rest of the system is built. In the former case,
Common Lisp is reasonably close as starting point, but doesn't provide room
for experimentation with new ideas with equal ease - particularly since in
practice you'll be married to the existing implementation, as the effort to
replace fundamental parts would be more costly than in a system which was
designed and implemented in a very modular style.

> Also, it seems that the Scheme world is in for a bit of upheavel coming
> soon with the introduction of R5RS. What will this do to the world of
> available Scheme systems?

As far as I can tell, there's absolutely no reason to worry about that.
It looks like the changes will be basically the incorporation of the high
level macro system (i.e. syntax-rules), the adoption of simple multible
return values (i.e. only together with call-with-values - thus much less
pervasive than e.g. Common Lisp's facilities), top-level eval (only for
expressions; i.e. no support for definitions _required_), and restructured
language documentation (making primitive vs. derived syntax/procedures
more explicit).

>  A number of the high-quality systems available
> will surely take years to come up to the new standard.

All this has been around for some time, and can be implemented relatively
easily on an R4RS system which has some form of macros (not necessarily
hygienic ones; something like traditional expanders is also sufficient).
In fact, mostly-portable implementations of such facilities are available;
it's just preferable to have those things as part of an integrated system
to provide better development support (e.g. error messages for macros) and
some optimizations (for multible values and for eval).

> I just don't see the big win with Scheme.  In >practice< continuations and
> hygienic macros are just not used that much to outweigh all of the benefits
> of using CL.

Scheme's advantage wouldn't be so much what it does have in addition to
Common Lisp (hygienic macros aren't really that difficult to add, assuming
you don't plan to disturb the result too much with symbol/package-level
surgery), but the overhead which it doesn't need to carry around (including
the conceptual overhead for full ANSI Common Lisp, which is substantial).

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>