Flux toolkit as LispOS base

[Tim Pierce]

> Date: Fri, 02 May 1997 16:06:14 -0700
> From: Kelly Murray <kem@Franz.COM>
> 
> > It will get us a big head start without forcing us to carry
> > a lot of Unix baggage that is likely to force us to twist the design of the
> > system for the sake of compatibility.
> 
> I'm not sure I follow this.

Here is what Arthur's response means to me: if our initial
approach is to link a Unix kernel with a Lisp interpreter and
start tossing out the bits we don't like, we run the risk of
unconsciously allowing the bootstrapping process to shape our
goals.  In such a situation, it is very easy to let the
limitations or philosophies of the development environment to
affect the way you approach problems.

	Q. ``How do you carve a statue of an elephant?''
	A. ``Take a big block of marble and carve away everything
	     that doesn't look like an elephant.''

This approach is the ``everything that doesn't look like an
elephant'' school of operating system design.  It's possible to
do, but it is ambitious: if you're not extremely careful, you can
easily wind up with the big block of marble.  I want the
elephant.

> I think throwing out the file system is sufficient to eliminate a
> whole lot of UNIXisms.   

Just to name an example, it still leaves you with the pipe model
of interprocess communication: everything is a stream of bytes.
Ripping out pipes and replacing them with some more sophisticated
object-passing system isn't going to be so easy.  You also still
have Unix signals, whereas a more fundamentally derived Lisp
system might want to implement asynchronous traps with
exceptions.

These are examples of how difficult it is to get to the elephant.
If you just throw out the file system, you may easily wind up with
a very blocky-looking statue, by leaving in all of the Unixisms
that you forgot about or didn't realize could be abandoned, or
coded yourself into such a corner that you rely upon them.

But don't argue -- go thou and do it!  Prove that I'm wrong: show
me it can be done.  We need hacking as well as discursion.

> As someone mentioned, it is difficult to get started writing code
> with a persistent object system when you don't have one.
> However, ACL has a "dumplisp" capability that saves the state of
> an entire Lisp process.  So transient CLOS objects can be saved this way.

Neat!  Can Franz contribute Allegro source to help make this
happen?