Minimum set of primitives?

[Kragen]

On Thu, 19 Mar 1998, Christian Lynbech on satellite wrote:
> I am not all together convinced that we (that is in the context of a
> lisp OS) should think about primitives such as define or case/if. In
> my vision, the lisp OS should provide more basic services allowing
> easy and efficient porting of *existing* implementations. Since CMUCL
> or GUILE Scheme already has done efficient implementations of all
> this, I see no reason to reimplement it.

I like your idea.

> So what do I mean by "basic services"? Well, this is of course common
> infrastructure such as a filesystem, other I/O and memory
> management. 

I'm not convinced that a filesystem is necessary.  If, instead, the OS
simply lets you map disk into memory, periodically saving the entire contents
of virtual memory, that would be sufficient, efficient, and much more
flexible.  KeyKOS worked this way.

The question is, basically, what should we put in the kernel?  We
should put in things that it is useful to share between different
programs.  Memory management with garbage collection is obviously a big
win to share between programs -- it lets you do IPC by simply passing a
single pointer, and lets you do security by running threads in barren
environments.  Preemptive multithreading is obviously a big win -- it's
necessary to make sure that one endless loop can't lock up the system.
Secure multiplexing of I/O is a big win -- it means that your programs can
access I/O devices without being worried that other threads will be accessing
those devices at the same time.

What else is needed?  Anything?  What else would be much more useful in the
kernel than anywhere else?  

> Taking any one lisp implementation, combine it with the Fluke kit, 

I'm afraid I don't know what the Fluke kit is.  Is this a FAQ?

> and hack up the missing parts would probably be a rather easy road to
> soemthing that could boot a machine up into lisp, but to me, the real
> promise of a lisp *OS* would be the ability to *integrate* wildly
> different implementations into one coherent working environment.

That would be nice.

It might not even be necessary, though.  The primary usefulness of a
particular implementation of Lisp is that certain Lisp programs run
happily on it.  If we were to build a Lisp OS that was flexible enough,
we could easily implement different flavors of Lisp on top of it.

What are other people's thoughts on the work involved with each approach?

Kragen