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

[Fare Rideau]

Dear NILists,

>: Henry G. Baker <hbaker@netcom.com>

> 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.
>
Well, again, that's where I really see two projects
even in this mailing list (with lispvm, that's three):
1) some want a CommonLISP-based environment so that a last
 we can manipulate all our user-level stuff using a same real language.
2) others (like me) want a Lispy architecture as a clean basis
 to found a computer system upon.

The two projects are in no way opposite, but complementary,
in as much as members of both projects are willing to adapt theirs
to the requirements of the other, as they appear.


> 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,
which is what I've tried to define in my Tunes project.

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,
and more generally, specification of semantical invariants and variants.
I would like that there be system-aided enforcement of user-defined
semantics, but I'm not sure how to do that in Lisp.
BTW, that's why I rejected Lisp as it is as the High-Level Language of
my TUNES project, though I recognize it is the best existing approximation.

> 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.
>
I believe Edwin already did all/most of it.
Which raises again the question of which LISP dialect to choose,
or rather, (HOW? (CAN LISPOS (SUPPORT (MULTIPLE (LISP DIALECTS)))))
as I don't think LispOS can reasonably qualify as an OS
if it is unable to provide such support.

> Pull Emacs apart into more modular pieces so that one
> doesn't _have_ to have such a large thing to start with.
>
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.

> 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.
>
That's exactly the TUNES philosophy.

> Lisp-on-JavaVM is a necessary part of this evolution, as is Lisp/captivex.
>
I disagree, but I'm confident that there will be someone to do that anyway.

> The synergies of a whole LispM project come from the ability to
> continually reuse ideas, tools, code, etc.
>
That's meta-programming. I'd like to go further,
and build a reflective architecture. See the Tunes project.

> 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 !  :-) :-)
>
Funny that you suggest that, but that's precisely
the thing I was doing in the Tunes OTOP subproject (On Top Of Posix)!
However, I didn't get very far off, as I realized that all the Lisp->C
compilers should already have code for that, so I should better steal it.
However Lisp->C compilers do not usually support full C syntax;
a program that does is Tom Lord's C parser&analyzer, as found in ~twaddle.
I don't think he made it part of Guile, but didn't check -- see around
http://www.eleves.ens.fr:8080/home/rideau/Tunes/Review/Other.html

Best regards,

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"