What is a ``reflective'' system?

[Jordan Henderson]

> 
> >
> > The big problem with this idea (making a Lisp Assembler which assembles to
> > a LispVM) is that the system is not fully 'reflective', the LispVM could
> > not be defined in terms of it.  Using a Scheme/Lisp->C compiler to try to
> > write the lowest level stuff still means that the GC, Virtual Memory and
> > some other low-level stuff will be written in C.
> > 
> This reflects the point that LispVM is going to target the existing Web client
> platforms, providing a place for Lisp and Scheme apps to run outside of LispOS.
> As long as there is binary portability and runtime interoperability between
> LispOS and remote LispVMs, then what VMs end up as under LispOS is a bit of a
> separate issue, and one that has yet to be clearly defined and agreed to. 

I've heard this expressed.  I agree that it should be >targeted< for web
stuff, but I see no reason why there shouldn't be a LispOS that runs on
top of LispVM.  

If, for a new machine, we had a good compiler for LispVM code then the 
performance should be acceptable and there are huge wins for portability.  
It should be fairly easy to port the LispVM to a new architecture using Flux 
(or whatever) and then bring up the LispOS immediately.  A second stage could 
then be writing the Lisp compiler back end for the new architecture/environment 
and bringing up the "optimized" environment.  Of course, we may never have 
to get to this second stage if the LispVM ran acceptably well in the new 
environment.  AND, if we don't implement LispOS in terms of LispVM then
getting to a reflective system seems harder.  I've outlined an approach
to get to a reflective system with everything but the LispVM included.  
We would still have to provide a low-level language that doesn't depend
on GC or Virtual Memory, etc. to define these things in.  Perhaps a Lisp
Assembler for the target machine could be a way to go here.  Note that if
we took the Lisp Assembler part that was written for LispVM and hand
translated to native assembly for the target architecture then this is
just about the same as having a compiler for LispVM->native.

Note that using native Lisp Assembler can allow us to make a fully 
reflective system while taking a portability hit, while LispVM Assembler
is not fully reflective (you have to implement the LispVM separately, 
even as a compiler->native).  Come to think of it, maybe the approach
would be to always have native Lisp Assembler to define the LispVM
compiler and then implement the rest of the system in LispVM.  We could
have an intermediate step of having a compiler for a small language that
compiles to Lisp Assembler (or directly to binary) that is directed at
low-level systems programming and use that to define as much of the 
machine code as possible.  Of course, we still have to deal with the
machine code of the target architecture in that compiler.  It seems that
the goals of portability and reflectivity fight against each other.  The
more portable it is (defined in terms of LispVM seems most portable to me)
the more of the system needs to be defined outside of the reflective part 
(the LispVM).  Complete reflectivity has us defining a lot of machine
level generation in high-level, which perhaps make it more difficult to
port. 

There are others who are not concerned with these problems at this time.
They want to hack CMU-CL to come up under Flux and have a LispOS.  This
may be the best starting point of all.  It's better to have something
running on metal than to debate it to death.  

I guess it sounds kind of old by now, my calling for project coordination.
I really think we need it.  I feel like a hypocrite.  I probably won't 
contribute too much to whatever real software is written, I just like
to talk (or write text, not software).  I've got personal commitments 
that probably prevent me from being a big force in this effort.  I just
want to eat the bread, and criticize the bakers, "you are planning on 
using too much yeast" or  "no NO! Not THAT kind of oven, use this kind!"
I'm more than happy putting in half-baked ideas though.

> 
> As to how VMs play in LispOS, I liked the idea someone (was it Alaric?) had
> about VMs being first class objects under LispOS -- this would be great for
> multi-tasking. 

I like that idea, too.  If the system was implemented on top of a LispVM 
then perhaps this LispVM could be cloned to support this.  If the system
was implemented on a compiled LispVM, then we would have to write the
LispVM in LispVM (or Lisp) to support this.  How would that be for 
reflectivity!

> 
> Consider a roving LispVM agent, gathering data by migrating between client
> workstations and non-LispOS Web servers. Whenever the roving agent needed to,
> it could instantiate another VM object on the LispOS server and have it execute
> some expensive process, concurrent with all the other things it might be doing.
>  I could think of a few applications for that. <g>
> 
> I'd also like to see some objects for managing roving agents built. A roving
> agents manager could do things like track the agents that had been sent forth,
> ping the agents, display their whereabouts, and for debugging, being able to
> inspect a log of interactions between the agent and LispOS. Having these kinds
> of things provided with LispOS/LispVM would give people an added incentive to
> use the platform.
> 

These are all great ideas.  I think one really positive thing to come out of
the JavaVM is that people don't think of VMs as completely unworkable, slow,
backword ways to implement systems.  It's one thing to do with all the 
extra horsepower the chip makers are giving us that really helps, at least
in portability.

> > 
> > -Jordan Henderson
> > jordan@neosoft.com
> >
> 
> Bill House
> --
> http://www.dazsi.com
> The views expressed are mine alone,
> unless you agree with me.
> 
> 
>