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

[Jordan Henderson]

> 
> "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>
> 
> 

I think this is an important question.  I would prefer Scheme, but I must 
admit that I'm not an expert in the area.

The BIG win with making a committment, at the start, to supporting CL as
a standard programming language/environment is that ANSI CL is already
a real-world application programming language with a certain amount of
industry support.  Anything we do in Scheme will involve reinvention of
a lot of wheels to make the language usable for real-world applications.

With CL, we already have CLIM, CLX, CLOS, good (free!) language manuals,
a number of implementations that are to a very large extent compatible 
(unlike the Scheme world, where significant systems are always married
to a particular implementation), and a number of commercial vendors supporting
the industry.

I think this last point is important.  I don't want a system just for
my tinkering, or to prove that it can be done.  I want a system that I can
use, for real-world work, in industry.  I believe that the commercial
vendors will support whatever we do, in one way or another. Using their
compiler technology instead of what we distribute will be one way, but
there are a number of other ways commercial support can help LispOS as
a product.  This will mean that I will have some chance of using the
LispOS in industry soon.  I think I could justify the use of such a
system to management with the history and support that CL has, but
I doubt that a LispOS that was programmed in Scheme could break through.

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.

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?  A number of the high-quality systems available
will surely take years to come up to the new standard.  This will mean 
that either we'll be stuck using R4RS (from all reports fairly limited
for real-world applications), or we'll produce a lot of code that won't
work in someone's favorite Scheme system.

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.

Of course, these are uninformed opinions, and I admit it.  

-Jordan Henderson
jordan@neosoft.com