What is a ``reflective'' system?
Alaric B. Williams
Tue, 13 May 1997 18:34:24 +0000
> 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:
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:
(ranged-integer <min> <max>) <- implementation chooses best word size
(cons-pointer) <- this is implicitly a pointer to a cons cell
There are code labels that can be obtained. A standard procedure
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
> 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
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!
Alaric B. Williams (firstname.lastname@example.org)
---<## OpenDOS FAQ ##>---
Plain HTML: http://www.delorie.com/opendos/faq/
Fancy HTML: http://www.deltasoft.com/faq0000.html