Lisp to the metal

[Ingemar Hulthage]

"Marc Wachowitz wrote: "
...
> It seems we're still very far from even a near consensus what a Kernel
> Lisp should be good for, or a rough outline of what it might contain.
> Before that's clear, I doubt it makes much sense to get down to concrete
> proposals (thus I'm not yet going into that).
> 
> I think a Kernel Lisp should be both simple to understand, and implementable
> very efficiently without excessive compiler magic on common hardware, without
> needing much support from an operating system. It should enable e.g. Common
> Lisp to extend and compile into it without considerable overhead.
> 
> If I'm interpreting the recent comments correctly, it seems a realistic
> tendency (perhaps the only one) towards a reasonably broad consensus may
> be to take Common Lisp as a "middle layer", extending it "downwards" with
> more primitive facilities
...
> Maybe I'm confused or just insufficiently informed about CLOS, but
> I've got the impression that the behaviour is too distributed (through
> time, ranging from separate compilation to loading until execution,
> and potentially throughout a complete program compiled in many parts)
> for a decent modular static analysis, without excessive reliance on
> run-time code generation or whole program analysis. Creating another
> metaclass doesn't appear to improve this very much. 
...

This all make a lot of sense and full featured CLOS is probably not
efficient enough for low level code.  On the other hand it seems to me
that the main strength of the 'Lisp to the metal' idea, would be to
make the hardware, file system etc. appear to be classes and objects.
These classes could be implemented in some special way (e.g. statically) 
but they should appear to be regular CLOS objects to higher levels, 
for the most part.

Ingemar

I know LispOS is already adopted, but this suggest another name -- CLOSOS