NIL (was Re: goals of LispM, etc.)

Henry G. Baker
Wed, 30 Apr 1997 19:16:51 -3100 (PDT)

> > 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.
> >
> What you're describing is a reflective architecture,


> BTW, mix and _Match_ makes me think about pattern matching and ML
> (another language that I'd like be well-integrated in a real OS),
> and reminds me that there's still something that bothers me: type systems,

Mitch Wand used to have an ML type system & type inferencer for Scheme.
I happen to think that that is a good idea for certain tasks -- I just
wouldn't want to make it a _requirement_ before code is allowed to execute.
Supporting such things should be encouraged.

> Which raises again the question of which LISP dialect to choose,
> as I don't think LispOS can reasonably qualify as an OS
> if it is unable to provide such support.

I don't think that it is necessary to choose one dialect over all
others if you provide for reasonable hooks.  E.g., it should be
possible to support both CL hairy arguments as well as Scheme
continuations.  One of the first things SMBX had to do was to get Dave
Dyer to port a large Interlisp package and develop an Interlisp
compatibility package.

> Maybe we need a good module system to begin with.
> Will you help us design one?
> One goal is that it should do
> as well as ML module systems (SML's and OCAML's),
> including typechecking, in as much as there are declared types.

I wouldn't get too carried away here.  There are plenty of opportunities
for theses (undergrad, masters, phd), but I don't think that you want to
hold up progress by requiring that someone finish such a thesis before
work can proceed.  If the system is loose enough and productive enough,
then much can be retrofitted with better ideas downstream.  Isn't that
the beauty of Lisp?

Henry Baker
www/ftp directory URL: