Using CL with Linux or Hurd

[Marcus Daniels]

>>>>> "RC" == Richard Coleman <coleman@math.gatech.edu> writes:

RC> Ok... it seems there is a fairly good consensus that using Common
RC> Lisp such as CMU-CL is the way to go.  So let's proceed with this
RC> assumption at this moment.

I'm all for entertaining this possibility, but could we please slow
down a bit?  I'd like to do some Scheme advocacy, but I don't have
time to do so at the moment which sufficient depth.

Briefly, I don't think the body of systems-oriented *free* Common Lisp
code, is so much superior to what exists for Scheme.

Scheme is easier to learn, the implementations are less complex, and
there are even some of similiar high quality (MIT Scheme or Scheme 48
vs CMUCL).  There are even packages like scsh where thought has
been given to the tasks that Unix is pretty good at and people are
accustomed to doing. 

Some other random points that come to mind:
     
   o Few Lisp programmers use all the features in CLOS or CLCS --
     simple inheritance and method dispatch with catch/throw or
     continuations go a long way. 

   o Quality numerical libraries exist as C and C++ libraries
      (e.g. Bruno Haible converted CLISP's to C++ and extended it for CLN).

   o As for the stack groups vs continuations thing that's an independent 
     issue to Common Lisp vs Scheme (I, for one, was only stating an aesthetic 
     preference API-wise -- sure, there are a lot of parts that need to 
     be there either way). 

   o In the hybrid C/Lisp model, (besides being unfree) CLIM isn't
     relevant because of the economy and reliability of using well tested
     and maintained C and C++ toolkits like Tk or Motif.  Even in the pure
     Lisp model it might make more sense to use OOP messaging or web
     technology to talk to GUI software.

   o I also think it is also worth keeping in mind that the (Scheme) DSSSL SGML
     standard that is generating significant interest, and has broad
     commercial potential (there's even a free implementation, Jade).
   
   o If Scheme people hate Common Lisp, that *is* a disadvantage.
     Scheme people are almost always capable and smart folks.

     [Personally, I rather like Common Lisp, but just think this
     preference comes at a high cost (speaking as a person that helps
     maintain a Common Lisp implementation).]

We should consider Richard Gabriel's notion of "worse is better" for a
moment.  I understand the potential benefits that come from having one
rich and integrated lisp implementation, but what gets left out is
that someone has to *maintain* this thing.  The bigger and more
complex the essential parts are, the harder that is to do for
independent volunteers.  Scheme + gobs of libraries may be flaky when
it comes getting everything/everyqbody in sync, but I think that goes
with the territory whenever busy people try to work on something like
this (at least in the early days).

RC> Next is the choice of base OS.

RC> 1) Flux toolkit - most people believe this is too ambitious, and I
RC> agree.  It would be different it this was a funded project with
RC> full-time programmers.

If there are really people that the time, energy, and skill to start
at this low a level, I think it would really make more sense to do the
Pure Lisp thing, e.g. starting with cross compiles on CMUCL, or some
such.  But if portability is important, this is very large task.
Perhaps it is feasible, though, given Linux, BSD, Mach, Flux, etc. as
device knowledge references (and some of the veteran Lisp hackers that
have already spoken).

I worry many non-Lisp folks couldn't be converted; I think many would
regard it as freakish, and wouldn't use it or contribute.  Frankly,
I'm not particularly comfortable about saying the body of C/Unix code
that has been developed over the last 15 years is just crap all for
the experience of "feeling the bits beneath my toes".  I already enjoy
some of that with Emacs, and frankly, some clumps of bits are kind of
sharp and not fun to walk on -- if someone enjoys writing Ethernet
drivers in C and does it well, I'm more than happy to dynamically link
in their code!

RC> 2) Linux - next alternative is using a minimal Linux distribution
RC> as a base and then proceeding from there.  Phase 1 would be to
RC> just create a small Linux distribution with CMU-CL installed.
RC> This would give people writing applications a place to start.
RC> This could be started fairly quickly.

How is a Red Hat + CMU-CL < bare Linux kernel + CMU-CL.  I don't yet
understand the need for creating such a stripped-down development product.
Rather, it seems to me the work in #2 is more or less equivalent to
adding a multithread implementation to CMU-CL, and integrating it with
kernel threads; in this model we should get behind the CMU-CL effort 
(definitely a worthy project, IMO).

RC> 3) Hurd - now that glibc 2.03 is out, I'm assuming Hurd 0.2 is
RC> coming soon (at least that's what I heard TB say).  First this
RC> would require porting CMU-CL to the Hurd (which is useful in its
RC> own right).  Then it would proceed like version 2 above.  The nice
RC> thing here is that you could be running both the lispOS
RC> environment and the standard environment at the same time (great
RC> for debugging).  Also, given the architecture of the Hurd, parts
RC> of lispOS could be useful to people who have no interest in lisp
RC> (such as using translators written in lisp).

As I understand David Gadbois, he's not talking about layering this
LispOS over a microkernel or oskit.  What I understand him to mean is
building up an OS around Lisp code *only*.  Even if I'm
misunderstanding him, this should be enumerated as another option.

I'm still in the Hurd camp because 1) I don't think the hacker
demographics that existed prior to Linux catching-on exist or can be
evolved for a Lisp-only machine, 2) I think adapting Linux to do
be a tightly integrated OO persistent store and do elaborate GC tricks
will be really hard, and 3) without tight integration, I think it
makes more sense to focus on Win32 and Unix portability.