various thoughts

[Marcus G. Daniels]

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

RC> 1) What OS to start with.  The possibilites seem to be Linux, BSD
RC> (FreeBSD, etc..), Hurd 0.2 (coming out soon I understand).  I've
RC> also had people recommend using the OS toolkit from the Flux
RC> project.  Using Linux or FreeBSD is probably the easiest, but the
RC> other might have more possibilities.

I think it is a worthy goal to be able to write almost anything in
Lisp, (e.g. device drivers), but that comprimises make sense if
significant code from *BSD, Hurd, or Linux can be leveraged.

My default approach would be a Hurd/Guile based system, enhancing
Guile with a bytecode compiler and attempting to adapt a lightweight
code generator like vcode or kaffe to run bytecode output of this
compiler (and then adapting GCC bytecodes to be like Guile's).  The
result would be 1) portable executable code with on-the-fly conversion
to native code, 2) high quality static code generation (from C) for
performance-crucial situations, and 3) the option of having portable
executable code output for source of #2.  (If there were a high
quality bytecode compiler for Scheme, perhaps #2 and #3 wouldn't be
necessary at all.)

http://www.pdos.lcs.mit.edu/~engler/papers.html
http://www.kaffe.org

The advantage of Hurd would be that one could always fall back to a
Unix-compatible development environment.  The advantage of both Hurd
Guile would be that there would be a somewhat reliable following of
people interesting in maintaining the code.

RC> 2) What Lisp to start with.  CMU seems to be the leading choice,
RC> due to good native code generation.  But other might be good.  But
RC> I understand CMU is also complicated.  So something easier to hack
RC> on, might be better.

Even Common Lisp has the problem of being complicated.  CMU Lisp
should run on this hypothetical system, but should this system really
be based on it?  I fear this makes hacking less accessible.  Perhaps
some standardized macros for compiling `conventional LispOS Scheme' with
the Python CMU Lisp compiler?

RC> 3) Lisp or Scheme.  It might make sense to use a Scheme distribution
RC>    to get started rather than Common Lisp.  Continuations might make
RC>    certain things easier.  There are plenty good ones to use (scm, guile, 
RC>   maybe Gambit-C).  Of course you lose all the Common Lisp extras such
RC>   as CLOS, etc...

I'd vote for Scheme or some other trimmed-down Lisp -- to make it
easier for both users and developers to understand.  The extras can be
added in later.  A continuation based multithread model does sound
nice to me.

RC> 4) How ambitious to be.  I'm a big believer in starting small in
RC> order to get started.  If you set initial goals that are too hard,
RC> frustation will set in.  A good starting point might be a small,
RC> minimal Linux distribution with pre-built Lisp (or Scheme or scsh)
RC> and lots of Lisp pre-installed.

I don't think much is gained by installing a dozen different
implementations, that would just reflect the chaos that exists today!
If some system utilities were written using Lisp, that would be a
start.  To make this work with Unix, this is really just a matter of
pushing enough of the Lisp implementation into a shared library.
(Guile, for one, is already organized this way.)