······@lavielle.com (Rainer Joswig) wrote:
> I wonder how many people have looked into the ISLisp standard docs.
> Not that its value solely depends on this number - but it
> might be an indicator of the interest in ISLisp.
While I didn't buy the formal standard, I did read carefully several of
the electronically published free intermediate documents, since quite
early in its development, including the last one [1], from which the
standard was derived. If it had developed more useful for my interests,
I would even have implemented it (and made it available). Unfortunately,
several IMO quite important features for serious usage in non-trivial
programs are not only lacking, but also hard to add as a true superset
of ISLisp. I've tried to design a static (i.e. compile-time-only) module
system providing separate compilation, name space management, and hints
for optimization on top of ISLisp, which should work well with its form of
macros, but didn't come up with anything I'd really want to use both in
relatively small "scripts", as a simple, orthogonally defined and modular
extension language in otherwise non-Lisp applications, and in large Lisp
applications - all with the potential for good performance on ordinary
hardware, with ordinary operating systems, and without needing a heroic
compiler which either knows the whole program in advance or re-optimizes
code at or after load time. What I hoped for would have been similar to
Henry Baker's ideas in "Critique of DIN Kernel Lisp Definition 1.2" [2],
and this is still something I'd call my Lisp Dream. Sure, I don't strictly
"need" a Lisp standard to implement something like that, but I don't have
the illusion that I, just a single person doing this in my free time, am
the best designer, implementor and manual/tutorial writer for a Lisp which
would fulfill such interests. Given many existing attempts to provide
a selection of similar traits as extensions of Scheme, and an appearant
growth of interest in "scripting/extension languages" (of which most are
quickly revealing their poor design as soon as some programs get complex,
or should become reusable modules of a larger infrastructure, which tends
to happen quite frequently, despite the more optimistic expectations of
people to keep things small - at the moment, I see only Python as working
reasonably well for larger systems), I'm even confident that there are a
lot of developers and projects which could make good use of such a system.
EuLisp also showed some movement towards such goals, but it seems that it
somehow got stalled (still lacking a seriously usable macro system and a
clear specification of translation phases and their dependencies, among
other things).
[1] ftp://ftp.harlequin.co.uk/pub/kmp/iso/v20/
[2] ftp://ftp.netcom.com/pub/hb/hbaker/CritLisp.html
-- Marc Wachowitz <··@ipx2.rz.uni-mannheim.de>
From: Hannu Rummukainen
Subject: Re: Who needs another Lisp _standard_? (Was: Re: islisp)
Date:
Message-ID: <m34suhmb4b.fsf@mu.tky.hut.fi>
> [2] ftp://ftp.netcom.com/pub/hb/hbaker/CritLisp.html
That's quite an interesting article there. I wonder which current Lisp
systems would come closest to Mr. Baker's ideal. Is anyone seriously
working in such a direction, i.e. sacrificing backwards compatibility
for parallelism and heavy-duty optimizations?
Hannu Rummukainen