different alternatives for lispOS
Christopher J. Vogt
Thu, 24 Apr 1997 19:52:24 -0500
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
>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
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
Christopher (Chris) J. Vogt