EuLisp

[Marc Wachowitz]

hbaker@netcom.com (Henry G. Baker) wrote:
> I suggest that bignums _not_ be part of the core language, but built
> on top of the core language _in Lisp_ using the appropriate primitives
> (fixnum+fixnum -> fixnum + fixnum(carry)), etc.

For a new open Lisp, I'd agree - as with most of your points in that
paper (except that I'd want to make modules as read-only name spaces
and units of separate compilation more explicit, and fully declarative
[obviously after macro-expansion in the module]). If there's serious
interest in designing an expressive and potentially very efficient Lisp
in layers, I'm all for it, but not only as entertainment with a result
which won't work for serious programming and delivery in a variety of
environments.

However, my comment was about small but necessary changes to EuLisp as
it is, not about designing a new Lisp. I doubt this forum is really
interested in anything like this _and_ would then proceed with the
necessary patience, care and discipline to get something which wouldn't
remind me of a big assembly of Perl and Java with Lisp-syntax and some
euphory for making everything in sight first-class. I'm afraid it would
do more harm than just using Common Lisp or EuLisp, extending it where
really needed (and as far as possible remaining within the standard).

For LispOS, I suggest Common Lisp. It may not be the most elegant Lisp,
but the people who worked on the ANSI specification had a lot of experience
from various backgrounds, from development to efficient compilation; thus
CL has at least been defined with such problems in mind, in contrary to
some existing much smaller Lisp variants, which may work well for the few
application areas which their creator(s) had in mind, but are incapable
of adapting efficiently to other needs.

As far as the "VM" discussion is concerned, this might even be a hook for
your proposal, and this is also what I tried to allude to referencing
Gabriel's paper on "How to Win Big": Common Lisp appears to be monolithic,
but even without using that as an application strategy, it may be helpful
to have a more layered/modular description, with a kernel of special forms
around which everything else is build - with the means of the language. I'm
no expert about the needs of excellent Common Lisp optimizers like Python,
but it may be conceivable that even such a layered implementation (with a
lot of compiler macros etc., to be sure) could be quite fast, and we could
use such a kernel-layer (i.e. "VM" - to keep people with a terminology-
addiction satisfied ;-)

> This and a number of suggestions are made in
> 
> ftp://ftp.netcom.com/pub/hb/hbaker/CritLisp.html  (also .ps.Z)
>
> Perhaps, due to the interest in LispOS, it is time to reread this
> paper?

I certainly second that - I'm merely pessimistic.

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>