Common or rare Lisp ?

[Dwight Hughes]

| From: Jordan Henderson <jordan@Starbase.NeoSoft.COM>
| 
| Ingemar Hulthage <hulthage@cinenet.net> writes:
| > 
| > 
| > I don't understand the purpose of these discussions about whether
| > certain features of Common Lisp are worthwhile or not.  One of the
| > strongest arguments for common lisp is that it's an ANSI standardized
| > OO language. To depart from that standard is suicide for any lisp, as
| > far as I can see.
| > 
| 
| I can't agree with the above more strongly.  What we need is
infrastructure,
| infrastructure, infrastructure.  We need a critical mass of Lisp tools
and
| high quality Lisp environments so we can start to gain momentum.  The
only
| way I can see this happening is if we focus on extending CL and CLOS.
| 
| A lot of the advanced language ideas expressed here are totally valid.  
| I would recommend that people set off to implementing these ideas >in
CL<.
| Write a testbed VM in CL and use CL to generate VM compilers for your 
| new languages, or compile to X86, or whatever.  From all reports, CL,
| despite all it's flaws, makes an excellent application development 
| environment.  Language compilers are applications.  If you have an
| idea for a low level language that's needed to support our overall goals
| (whatever those might be), then get started working on that low level
| language.  I would recommend that you implement it first in CL.  If 
| reflectivity is crucial, write your compiler first in CL and then port
| your compiler to be defined in terms of itself.  
| 
| Such a strategy that I've outlined above is a big win from the standpoint
| of developing the kind of infrastructure needed to make a LispOS a 
| reality.

Sure, and I'd like to have a common backend between CL and the new Lisp
(NL?) -- it would probably need to be a bit more general than the one
now in CMU-CL to support some of the excellent ideas set forth by many
for a new hyper-efficient lisp. Eventually I would like to see it develop
into a layered construction with CL built on the NL and using as many of
its concepts as is practical (perhaps not at "user" level but at
implementation
level at least).

I think we will need to create a cross-compiler environment to start the
*real* LispOS (Lisp-to-the-metal) effort anyway, just out of practicality.
We can take advantage of the tools in un*x, of which, for now, CMU-CL is
one. Assuming Flux is the way we go, we can also take advantage of its
remote debugging features to ease the startup phase.

To answer Ingemar's comments: I don't think anyone here has any intention
of abandoning CL (in spite of the fact that some of us consider it
analogous to a 2000 pound gorilla). There is too much code we would like
to have and use and port back and forth. Having the standard is important.
Using it for development of the upper level LispEnv is fine. We would
like CLIM too. However, CL is not the beast we need to tackle the lower
level OS development in. We *could* develop an OS in CL, but we
would have to add quite a bit of assembly code in a number of places
to get the performance (and control) necessary - hard to write, hard to
modify, non-portable, non-reflective; it would make certain critical parts
of the OS as opaque as hardware, hindering easy development and
customization.
This is why we are looking at a new lower-level Lisp -- we can then truly
have
"Lisp-to-the-metal" (not "CL-plus-lots-of-assembly-code") and all the
advantages that brings. The new Lisp in turn could just be the intermediate
code that CL/CLOS compiles to, and everyone's happy.

-- Dwight