What is a ``reflective'' system?
Mon, 12 May 1997 05:51:07 -0500 (CDT)
BRIAN SPILSBURY <firstname.lastname@example.org> writes:
> Having a LispVM does not exclude also have alternatives.
> Consider that most lisps will happily mix byte-code and native
> compiled code.
> Write a LispVM compiler in lisp.
> I don't think that's really an issue.
Well, one potential big win is to make the LispVM handle all of low, low
level stuff like Virtual Memory (to bad that the term 'VM' is overloaded),
GC, threads, exception support, etc. We then have a completely reflexive,
portable system defined with the LispVM assembler. This system could run
on top of other OS's or be run with multiple versions on the same physical
machine by just varying the LispVM implementation.
The problem with this is that it pushes a lot of the important, hard
work down into the LispVM. We would have a clear development path by
bringing up a LispVM in C in some hosted environment with lots of
good tools. Then, bring up the LispVM in C under Flux, adding in the
tough stuff like Virtual Memory, etc. that we deferred and we are done.
As I stated earlier, I think the best thing now is to get something
working to demonstrate. This quick path is straight 386 back-ended
CMU-CL on top of Flux. Here are the steps from there:
- Do a Lisp Assembler for 386, replace all of the
C glue we put into Flux and device drivers, etc. with
Lisp (+ assembler).
- Do a LispVM natively in assembler.
- Redo the 386 parts in LispVM.
- Rehost itself in LispVM and we're done.
This plan is quick compared to geological times scales. We may be
many years from the LispVM only implementation. The problem is that
if we wait for a good LispVM we may lose momentum. It's best to have
a dev platform that will be all Lisp, to get people thinking and
working in Lisp and to wean people off of their UNIX tools. The
danger is that if we hang around Linux too long we'll just develop
another novelty language environment for Linux.
I dunno, I may be full of crap.