goals of LispM, etc.

[Henry G. Baker]

Re LispVM, native Lisp, etc.:

Keep the goals of the project a little fluid.  What you really want
are a whole host of overlapping goals and tools -- e.g., you want Lisp
interpreters, Lisp compilers, Lisp editors, Lispy syntax for C, etc.

The goal should be to use Lisp _ideas_ more than a particular Lisp
environment.  By having Lisp ideas at all levels -- scripts, macros,
VM's, compilers, lisp-in-lisp memory managers, lisp-oriented
persistent storage managers, etc -- you can mix-and-match things to
make solutions for specific instances.

By all means, build upon existing tools & environments -- e.g., emacs
lisp.  Perhaps a good place to start would be to rehost emacs to a
better environment -- e.g., the current emacs gc is a bit of an
embarrassment.  Emacs lisp also needs to move more away from dynamic
scoping.  Pull Emacs apart into more modular pieces so that one
doesn't _have_ to have such a large thing to start with.

The overall LispOS should _evolve_ naturally as all the various pieces
come together in such a way that fewer and fewer non-Lisp components
are required.

Lisp-on-JavaVM is a necessary part of this evolution, as is Lisp/captivex.

The synergies of a whole LispM project come from the ability to
continually reuse ideas, tools, code, etc.

I think that one piece of standards work that needs to happen
relatively quickly is a standard mapping of C and C++ syntax into
S-expressions, together with a parser and pretty-printer.  This solves
several problems:

* you get the ability to use Lisp as a preprocessor
* you get the ability to read .h files to gather information
* you automatically get a decent C/C++ pretty-printer !  :-) :-)

It is probably also necessary to program the silly C preprocessor in
Lisp in order to gain compatibility.  (Perhaps Dick Gabriel knows what
became of all of Lucid's old code?)

-- 
Henry Baker
www/ftp directory URL:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html