What is a ``reflective'' system?

[Dwight Hughes]

| From: Jordan Henderson <jordan@Starbase.NeoSoft.COM>
| 
| Well, one potential big win is to make the LispVM handle all of low, low
| level stuff like Virtual Memory (to bad that the term 'VM' is
overloaded),
| GC, threads, exception support, etc.  We then have a completely
reflexive,
| portable system defined with the LispVM assembler.  This system could run
| on top of other OS's or be run with multiple versions on the same
physical
| machine by just varying the LispVM implementation.
| 
| The problem with this is that it pushes a lot of the important, hard 
| work down into the LispVM.  We would have a clear development path by
| bringing up a LispVM in C in some hosted environment with lots of
| good tools.  Then, bring up the LispVM in C under Flux, adding in the
| tough stuff like Virtual Memory, etc. that we deferred and we are done.
| 
| As I stated earlier, I think the best thing now is to get something
| working to demonstrate.  This quick path is straight 386 back-ended
| CMU-CL on top of Flux.  Here are the steps from there:
| 
| 	- Do a Lisp Assembler for 386, replace all of the
| 	  C glue we put into Flux and device drivers, etc. with
| 	  Lisp (+ assembler).
| 
| 	- Do a LispVM natively in assembler.
| 
| 	- Redo the 386 parts in LispVM.
| 
| 	- Rehost itself in LispVM and we're done.
| 
| This plan is quick compared to geological times scales.  We may be 
| many years from the LispVM only implementation.  The problem is that
| if we wait for a good LispVM we may lose momentum.  It's best to have
| a dev platform that will be all Lisp, to get people thinking and 
| working in Lisp and to wean people off of their UNIX tools.  The 
| danger is that if we hang around Linux too long we'll just develop 
| another novelty language environment for Linux.
| 
| I dunno, I may be full of crap.

This is all very fine and quite sensible. The only real problem I have with
Virtual Machines (and I actually like them very much) is that the VM forms
an opaque layer beyond which nothing is known to the system above
(usually).
We might also have a representation of the VM inside the LispOS which we
could develop further, simulate new developments, and regenerate the VM
from in a new form. This *I* would consider a truly reflective system.
(This has been done in Squeak Smalltalk - though it generates C code for
the VM from the Smalltalk code - plus some explicit C code contained in
the Smalltalk methods.)

-- Dwight