different alternatives for lispOS

[Christopher J. Vogt]

At 6:40 PM -0500 4/24/97, Richard Coleman wrote:
>Ok.. I've been looking into various alternatives for
>a lispOS.  Here are some various possibilities, starting
>with the most ambitious.
>
>Alsok, I'm using the word scheme below, but take it to mean some
>type of lisp/scheme dialect.  I'm leaning toward scheme, but that
>is a detail that can be worried about later.
>
>1) Layer a scheme distribution directly on top of the Flux OS
>   toolkit (http://www.cs.utah.edu/projects/flexmach/oskit/html/)
>   This is definitely the most `ground up' method.  This is
>   apparently the route taken by the Express Project at MIT
>   (http://www.ai.mit.edu/projects/express/) using the ML dialect
>   SML/NJ.
>
>2) Layer a scheme distribution on top of a minimal Linux
>   distribution.  Strip out everything except what is need to boot
>   the system (and a few small utilities).  Merge the virtual memory
>   code and GC code.  Then slowly replace all the standard apps with
>   lisp/scheme variants.  Also change the threading on the scheme to
>   sit directly on the clone system call.
>
>3) Layer scheme on top of some virtual machine such as
>   the java VM.  Using kawa would probably be a good idea here.
>   (http://www.cygnus.com/~bothner/kawa.html)  Also, other virtual
>   machines have been proposed, and should be considered.
>
>4) Build a large lisp-based user environment instead of a whole
>   OS.  This is essentially just a generalization of (X)Emacs.  This
>   has been proposed several times (GROW project for instance).  Most
>   projects like this have been propsed to use Guilde.  The advantage
>   is that is it could be made to run just about everywhere.
>
>I'm actually leaning toward version 2.  But that would depend on how many
>people are interested in helping to hack on the sytem.  There are quite a few
>people on the list at this point, so the interest is definitely there.
>
>But as I've said on the newsgroups, it would make sense to start small and
>build on the small successes.  A two phase plan would be to start on version
>number 4, with the aim of eventually using that code to accomplish version
>number 2.

Maybe we really need to first agree on a goal.  Do we want something that
runs on as many platforms as possible (ie. easily portable) (my personal
desire).  Or is the goal something else?  Once a goal is decided on, we can
brainstorm on differnet ways of acheiving the goal.

I think your last point is very important.  I agree that we need to start
small.  Come up with the bare minimum that is useful, and then build off of
it.

Christopher (Chris) J. Vogt
mailto:vogt@novia.net
Omaha, NE
http://www.novia.net/~vogt/