What is a ``reflective'' system?

[Jordan Henderson]

Brian Spilsbury wrote: 
> 
> Well, one thing to consider is that if you're using word-codes then
> you have 4 billion of them. That is before you start to fold arguments into
> 'em. But this means that we can for example have 'defun' create a new
> word-code. Essentially word codes can be any reference.
> 
> This gives you your reflectivity as we can now also redefine word-codes
> not only in terms of other word codes, but in native code.
> 
> It also means that you can have the idea of a lispVM word-code vm
> merge into a more common lisp. Its good to remember that lisps are in
> many respects themselves virtual machinesm, one reason that they're close
> to operating systems anyhow.
> 

I think this sounds great as long as we don't make the VM so high-level
that it will be difficult to have JIT compilers.  On the other hand, the
more functionality you can cram into the codes mean you get a lot of 
bang for your buck in communication times when you have distributed
LispVM applications (I'm referring to modem download times to web
browsers primarily).

> I don't know how useful these idea are to you, but it does mean that
> we can work in any given direction probably in the two different
> directions at the same time and still be able to have them integrated.
> 
> If word-codes are for example implemented as immediate values inside a
> reference, ie as the value of the pointer not what its pointing at,
> and we tag them as we would immediates, then we've already sliced the
> word-code space such that we can have 'word-codes that aren't word-codes'
> looking at whatever is on the other side of the reference, and then handling
> it as appropriately as possible.
> 
> This lets us cheat and plug in 'format' as a word-code, it also lets us
> prototype word-codes in plain lisp, without hacking the word-code
> interpreter itself.
> 
> Does this seem like a good thing or a bad thing?
> 

Ultimately a good thing.  The big win I see is getting a compiler like CMU-CL
generate VM code directly.  In this case, we probably have the program already
pretty well digested and we are ready to put out fairly low level codes out.
Or does CMU-CL just generate a subroutine call to _format?  If this is the
case, then it could generate the VM code just as easily.     

> JH> I dunno, I may be full of crap.
> 
> I don't think so :)
> 

Well, here is my problem with myself.  I've thrown out a lot of ideas about
a lot of things that I don't have much experience about.  I don't know 
ANYTHING about CMU-CL internals and I'm recommending how to redo the back-end
for a new machine (the LispVM).  I need to do more reading and less talking
(typing).  

I need to research:

	1) CL in general.  I've never written a single CL sexpr.

	2) CMU-CL internals.

	3) Flux toolkit.

Fortunately, I've detected these problems in myself.  If I'm not 
qualified to design or work on a reflective system now, at least I
have a reflective system working between my ears that can correct
this problem.

I'm just so excited about the real prospect that within a few years I 
might be able to use a system for real-world applications that is 
based, at it's root, on a language that is truly extensible, expressive,
powerful, manages memory FOR me (GC), reliable (no pointer problems,
although perhaps some type problems, hey let's put a good ML system on
top of LispOS someday!), etc.

I see so much energy being plowed into systems that, I feel, are rotten
to their core.  I find it really disgusting that 99% of the people that 
the world at large see as "computer experts" think that one or all of the 
following are cutting edge (C++, Windows95/NT, UNIX). 

> Brian
> 
> 

-Jordan Henderson
jordan@neosoft.com