goals of LispM, etc.
Henry G. Baker
Wed, 30 Apr 1997 13:07:56 -0700 (PDT)
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
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
* 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?)
www/ftp directory URL: