Alternatives for a LispOS

[Michael Korns]

Richad Colman suggested the following alternatives:

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 am not sure that it would meet the goals of the LispOS effort, but there
is an alternative not mentioned above. I am aware of this effort because we
use a Lisp based agent oriented database engine. So here goes. 

5) Build a Lisp engine with persistence, compilation to a VM, and DCOM,
CORBA, or COM communication capabilities. Simple transaltion from the VM to
various native instruction sets should be an easily available option. This
approach is similar to the No-Graphics versions of Smalltalk which are
floating around. The advantage of this approach is that it covers a lot of
ground, but stops short of requiring any one OS or graphics environment. It
can be added to any OS, any Graphics environment, and to any legacy
application rather easily.

Once again, this approach may not cover the goals of the LispOS effort, but
it is another alternative.





**************************************
Michael F. Korns
214 Shorebreaker
Laguna Niguel, California 92677
(714) 443-4847
mkorns@ix.netcom.com
*************************************