What is a ``reflective'' system?

[Jordan Henderson]

BRIAN SPILSBURY <zhivago@iglou.com> writes:
> 
> > Fare and others have been promoting the idea
> > of a reflective system.  I am familiar with this term
> > in several contexts and I'd like a little clarification.
> > 
> > Does reflective mean anything more than the usual
> > Lisp ability to get a hold of environments, code and
> > continuations?
> 
> I'd call that introspection.
>  
> > Does reflective extend to the 3Lisp concept of an
> > infinite reflective tower?
> 
> imho, yes, reflection is the ability to redefine the system from
> within itself. To have something able to change what it means by changing
> that it is reflecting (at the meta level).
> 
> PCL is a good example, it has a bootstrap stage in which it redefines
> CL such that CL is now CLOS, after that point PCL goes on to use
> code that is now valid in the new system which it couldn't before
> since it is now running under CLOS.

When I think of ``reflective'' I think of a system that can dump it's
state in high level to be defined on another system.  Maybe I was 
thinking of what you call introspection.

Many people have written Forth "meta-compilers" that define the Forth 
system completely in terms of Forth.  To do so, you have to write a 
Forth assembler for the target architecture and then cross-compile, 
then bring up the Forth on the new architecture and recompile itself.
Now, this may be cheating to some extent, in that you are using
assembly at some level to define the system.  If the Forth were 
compiled, you'd have to port the compiler first to the target
architecture to be able to have this "meta-compiler" scheme to work. 

Dwight has proposed trimming down CMU-CL to do the low-level stuff and
someone (Brian?) pointed out that this may be a difficult task.  Perhaps
an assembler like LAP (Lisp 1.5 originally?  I know I saw one on a DEC-10
lisp years ago) could be used to bring up a self-recompilable Lisp.

Unfortunately, you have to do quite a bit of work in assembly before you
get to Lisp this way.  You have Virtual Memory, the GC, much of the run-time to
define, and none of it would be portable.  It would be in assembly for 
a specific architecture.  Forth's machine model makes it easier to define
a lot of low level stuff in a portable way.  As to the objection that 
there may be a mismatch between the Lisp machine model and the stack-based
Forth machine model, I'd like to point out that the JVM has a forth-like
stack-based model and there's a great deal of work going on to define
other high level languages in it.  Of course, this objection may be 
completely valid.  I note that Inferno (http://www.lucent.com/inferno)
is gaining mindshare attacking this very point.

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).

Look, don't everyone get defensive about my suggestion of Forth.  It was
just a suggestion.  While it overlaps quite a bit with Flux, it could
be complementary and does solve different problems (like how to actually
write the VM, GC, etc.).  I would prefer to reduce, to as far a degree
possible, our reliance on C for low level stuff.  My view is that C is
the enemy here, it's good for low level stuff, but once you rely on it
there's just SO MUCH SUPPORT for it that it sneeks into your system at
higher and higher levels.  I'm not religious about NO C, I just feel that
there's a danger to base it on C that should be recognized.  The danger 
is that the whole thing will just be another language environment 
portable to systems with good C compilers where people will still do
most of their work in C/C++ and just use Lisp as a hobby.

This is exactly why we need some form of Project Coordination/Steering
Committee here.  I don't remember there being wide consensus on Flux and
I've even seen some ambivalence toward CMU-CL.  If people would just form
teams to research various things, then it would be clear which direction
we were working.  This would not squelch other ideas.  People who wanted
to go in different directions would just form their own teams.  It seems 
like now we are all waiting around for unanimity and then we'll all go 
off in the same direction.