Testing the waters.

[Jordan Henderson]

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
support against.

> >
> >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
> detail.
> 
> 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
support.  

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. 

-Jordan Henderson
jordan@neosoft.com