Testing the waters.
Fri, 9 May 1997 08:00:36 -0500 (CDT)
Chris Bitmead writes:
> >>You won't get portability from LispOS to other versions of CL in any
> >>case, because you won't have the POS ported to the other version of
> >>CL. And POSes are always very tightly integrated with the virtual
> >>machine and garbage collector, and application code.
For maximum efficiency the POS might be tightly integrated with LispOS
internals. But, we won't have those low level facilities for some time
AND there will be a strong motivation to prototype and develop the POS
on top of an already existing system.
Although I'm no expert, it seems that CL is really a powerful, expressive
language. I see no reason why the POS can not be implemented entirely
portably. In fact, given the development tools that we'll have it seems
that you would actually have to go out of your way to develop it so that
it's difficult to port to other CL implementations. You >may< develop
some new primitives not already implemented in CMU-CL that would
best be implemented at a very low level, but these will have to be
prototyped in CL if you want to do parallel development with the kernel
guys. You >may< eventually decide that whole sections of the prototype would
be unnecessary because of VM or GC support for those sections directly, but
I see no reason not to support the CL version of these as well, if nothing
else but to have a reference implementation that you can test the low level
> >If you don't define interfaces that will make your code
> >portable (as portable as you can), then you're doing something
> >wrong. I want Lisp code to be as portable as possible.
> >********************** MAXIMIZE PORTABILITY **************************
> Ok, hands up everybody who has no idea what an object database is.
> I can see someone will have to stand up and explain this in heavy
> For now I've going home :-)
I think the whole idea of using CL is that we are using a language powerful
enough to express arbitrary complex problems in a tractable way. As a
challenge, tell me specifically those things where we will have to resort
to low-level support to get a working POS. I don't want to hear about
efficiency issues, let's make a design as efficient as possible in high
level CL before we determine where we have big wins in including low-level
My design methodology would be:
- Design and implement in CL, using only those things specified
in the standard language. If a set of low-level data access
routines are desired that do not depend on the traditional file
interfaces, then first implement them in CL, then kick back to
the kernel guys what's needed.
- If there are serious efficiency issues, see if the compiler
can be modified to automatically, transparently make the kind
of low-level changes to the resulting executable program that
would improve matters.
- Now, if there are still efficiency issues, determine where a
new set of low-level primitives could be inserted to give
clues to the compiler and OS that something special is needed
here. These low-level primitives could first be written in
CL as a reference implementation that would clearly specify
the desired semantics. Of course, LispOS or VM would have to be
written to support these efficiently. It may turn out that
the use of some of these would obviate the need for a lot of
high level code. That's OK, we can manage multiple source trees
and divergent development. It's a problem that's been conquered
for quite some time.
In the end, we still have a COMPLETE implementation in CL. It might run
significantly faster on LispOS, but one could do development using the POS
on ANY CL system.
In the end, I hope that we get an entire LispOS that can run on top of any CL
system. It might run significantly better on the one we develop for it, but
how quickly it runs will be seen as a quality-of-implementation issue of the
compiler and the VM.