What is a ``reflective'' system?

[Alaric B. Williams]

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

Hmmm, I always thought of it the other way around!

The LispVM can run on Web browsers, a POSIX-able implementation you 
run... or on top of LispOS.

But then again, there's the "LispOS" of utilities and suchlike...

so we really have:

Lisp Kernel
LispVM
LispOS

LispVM being the execution model - a Lisp dialect with OOFS primitives,
by the looks of things; Lisp Kernel a fast native implementation; and
LispOS the set of tools written for LispVM to Get Work Done (tm) :-)
 
> 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.

I once considered the problem of a portable assembler, and got to the
stage of considering a register transfer language, where there are:

a) global monomorphic registers
b) lexically nestable procedures that aren't first class
c) stack-based local monomorphic registers
d) instructions are of the format:

(<procedure-name> <list of input regs> -> <list of output regs>)

Eg, there is no explicit "passing of references", although it
can be implemented as such - it just makes data flow clearer.

The typing of registers is a real pain to make portable. Basically,
I decided upon types as being:

(pointer <any-type-not-just-first-class>)
(ranged-integer <min> <max>)   <- implementation chooses best word size
(cons-pointer)   <- this is implicitly a pointer to a cons cell
(symbol)
etc...

There are code labels that can be obtained. A standard procedure
does jumps.

Arrays could be allocated statically, but they weren't
first class; only pointers could be passed. In that
respect, it's a lot like C, with more portable
numeric typing!

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

Me Too :-(
 
> 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!

My idea of a system was a single VM that spawned child VMs on
demand, passing down services from a set of system-level services
depending upon security capabilities, and providing the top-level IPC
mechanism. Each VM could, in turn, be another system - good for
debugging the IPC mechanism! 

ABW
--
Alaric B. Williams (alaric@abwillms.demon.co.uk)

   ---<## OpenDOS FAQ ##>---

Plain HTML: http://www.delorie.com/opendos/faq/
            http://www.deltasoft.com/faq.html

Fancy HTML: http://www.deltasoft.com/faq0000.html