What is a ``reflective'' system?

Jordan Henderson jordan@Starbase.NeoSoft.COM
Sun, 11 May 1997 12:44:28 -0500 (CDT)

Bill House wrote:
> Jordan Henderson wrote:
> >
> >[snip]
> >
> >Perhaps the Lisp assembly could assemble down to the LispVM.  But, what 
> >will the LispVM be written in?  C?  This might work well with Flux OS, 
> >which seems to define it's interfaces in C language terms.  Also, if 
> >we're assembling down to a LispVM, then we could influence the LispVM 
> >design to make sure there are good subroutine and exception mechanisms 
> >built into it at a low level, and then make the assembler a very high 
> >level assembler, complete with all kinds of syntactic sugar and 
> >syntactic support for exceptions.  Maybe I need to be posting this to 
> >the LispVM list.  I hope they are looking at Dis from Inferno.  
> >There's reason to believe that a register based VM like Dis is orders 
> >of magnitude simpler to implement as a JIT compiler and much-much 
> >smaller (I understand that Acer and other's have chosen Inferno to build 
> >NetPCs on instead of Java because they estimate the VM and support will 
> >be 1 MB of RAM instead of 4 MB of RAM required for JVM).
> >
> I like these ideas. LispVM is in all likelihood going to be written in C,
> although I suppose there's some merit to the idea of writing it in Scheme using
> Gambit-C.
> FWIW, the AgentBase VM runs its SmartLisp test suite in 2MB.

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.

I think that perhaps the goal of full reflectivity is not best.  If we could
define a LispVM separately, perhaps with several implementations (C, JIT,
interpreted Lisp for prototyping) then the rest of the system could be 
fully reflective assembling/compiling to this.  It would require that a 
LispVM backend be written for CMU-CL eventually.  I can see objections 
already.  We have people who want to use CMU-CL with native compilation
for everything, without regard to whether this is a good idea or not.  I 
think these people have "come in late from the picture show" and didn't 
hear that we were going to have a LispVM.

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

-Jordan Henderson