different alternatives for lispOS

[Marcus Daniels]

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

RC> 1) Layer a scheme distribution directly on top of the Flux OS
RC> toolkit

I suspect this is too hard, and won't result in utility that will keep
people engaged in improving the system.  On the other hand, a more
novel approach might keep the attention of a smaller group of hackers
(perhaps academically oriented).  It seems that is already occuring, as
you noted with Shivers' group.

RC> 2) Layer a scheme distribution on top of a minimal Linux
RC> distribution.  Strip out everything except what is need to boot
RC> the system (and a few small utilities).  Merge the virtual memory
RC> code and GC code.  Then slowly replace all the standard apps with
RC> lisp/scheme variants.  Also change the threading on the scheme to
RC> sit directly on the clone system call.

I think a microkernel approach would help here, because it would be
easier to attach a debugger to user level code.  Debugging GC is hard
enough: to have the entire system crashing because such bugs would
really be fun!  Still, I think #2 is the best approach, though,
because it could go in a number of different directions without too
much pain.

RC> 3) Layer scheme on top of some virtual machine such as the java
RC> VM.  Using kawa would probably be a good idea here.
RC> (http://www.cygnus.com/~bothner/kawa.html) Also, other virtual
RC> machines have been proposed, and should be considered.

(not necessarily incompatible with #1 or #2, of course)

RC> 4) Build a large lisp-based user environment instead of a whole
RC> OS.  This is essentially just a generalization of (X)Emacs.  This
RC> has been proposed several times (GROW project for instance).  Most
RC> projects like this have been propsed to use Guilde.  The advantage
RC> is that is it could be made to run just about everywhere.

This is a LispOS mailing list, right? 

RC> I'm actually leaning toward version 2.  But that would depend on
RC> how many people are interested in helping to hack on the sytem.
RC> There are quite a few people on the list at this point, so the
RC> interest is definitely there.

Sounds good to me!

RC> But as I've said on the newsgroups, it would make sense to start
RC> small and build on the small successes.  A two phase plan would be
RC> to start on version number 4, with the aim of eventually using
RC> that code to accomplish version number 2.

Some degree of focus is needed.  I know I'll continue to have my
application oriented interests that I'll be pursuing, and my
experience is that there a natural tendency to integrate.