LispOS Kernel: the Tunes approach

[Fare Rideau]

On LispOS@math.gatech.edu, it was written:
>>: Stephan Papageorgiou
>: Christopher (Chris) J. Vogt

>>question: what language would the kernel be written in
> Lisp!
>> and which services should it provide?
> All that are needed.
>
Accurate answers, but not very useful ones, to say the least!

As for the language, which Lisp do you mean?
Lisp 1.5? Standard Lisp? Common Lisp? Scheme? EuLisp? Yet Another Lisp?
Note that I'm not talking about the meta-system,
but about the core target language...


IMO, the heart of the kernel should be a highly *reflective* language,
that provides a minimal core (not even car, cdr, set!),
but insists on orthogonality and modularity (with a module for lists, etc),
together with a semantics specification system.

Thus, on each architecture, modules that describe the hardware
at a very low-level are provided.
   Device drivers come as very basic modules; but functionality
common to many device drivers can already be factored into functors
(see the Linux VFS and NET3, and whatever BSD does: functors in C -- yuck).
   Functors are then used to gradually implement higher-level objects
from lower-level ones (for obvious efficiency reasons,
and contrarily to what Linux people get with C, functors will _not_
be implemented through lame manual run-time interpretation).
   Hence, target specific modules could implement fixnum arithmetic,
and then a generic Lisp module could implement bignums from fixnums
(as suggested by hbaker previously). Other generic Lisp functors
could handle various aspects of Garbage Collection, depending on
functionality available in hardware abstraction layers.
   A functor model allows us to seamlessly integrate low-level
and high-level objects into a one environment.

Now, that's where *reflection* and *specification* are used:
instead of requiring a an explicit construction of the outer modules
from the inner ones, which would be an overspecification of
system functionality, a stubborn static constraint on objects,
an obstacle to object migration, etc,
objects use functionality of specified semantics,
but unspecified implementation (hints welcome, of course),
that the system must *dynamically* implement,
allowing for seamless migration of code over changing environments
in a completely safe way.
   Even in a "same" environment,
a given functionality could have multiple implementations, and the system
would dynamically choose which implementation to use at each point
in a way such that the combination would minimize overall cost.


Of course, for reasons of speed of implementation (and stubbornness
of both implementors and specification software),
underspecification can be used, in which case you lose as much safety.
That's a perfectly valid choice,
as long as it's voluntary rather than forced,
and as the gap can be dynamically filled
by continued specification effort with improved software.
   Feel free to use complete underspecification (i.e. no information)
as a way to do things to begin with.
Of course, functional languages make specification possible,
so that if we fully use it, we'd have the first proven-correct OS ever,
with a strong stand in the market of mission-critical and secure systems;
another way to demonstrate C's lameness,
and cast it back to hell where it belongs!

Migration may involve physical migration of code over another CPU/OS,
or a complete change in calling conventions,
a modification among the device drivers,
or any change whatsoever in the underlying *representation* of the objects.
   Semantics precisely allow us to (dynamically) specify
what is part of the voluntarily observed behavior (the invariant)
what is a cost to minimize (the variant),
what is meaningless implementation dependencies (the stuff with no name).

The "Kernel" then is just some protocol that allows functionality
to be implemented in modules.
   Modules and functors of as orthogonal functionality as possible are built.
   A heuristic system (in the beginning, with very explicit hints;
at the end, with completely implicit behavior) will combine the modules
and functors into the required behavior.

Ahem. I guess that once again, I've been describing my Tunes project.
I really do think it would be great as a LispOS core, though.

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"