rainer joswig

In article
<f4b6620f-82dd-4b3c-85b7-f5ce5b788dbc@p69g2000hsa.googlegroups.com>,

These are technical issues that come up when you think
about Lisp implementations. For example the absolutely
excellent book 'Lisp in Small Pieces' by Christian Queinnec
has a whole chapter devoted to this topic:
Chapter 2: Lisp, 1, 2, ... infinity http://pagesperso-systeme.lip6.fr/Ch.../WWW/LiSP.html

It does not make sense to bind terms to things that happen
to be popular. Popularity changes. Languages change.
Lisp is now 50 years old. It has seen many dialects and
we will see many more. Still some of the basic principles
of Lisp implementation are independent of the dialect
that happens to be popular at any one time.

ISLisp is still used. There are also lots of other Lisp dialects
in usage. Some only inside companies (say as extension language)
or single applications.
(I heard that a disk drive vendor has a Lisp in their
firmware.). I'm always careful to not exclude other Lisp dialects.
For some it may not be important, since they have never
used anything else from Scheme or Common Lisp. Some
others feel that there is need for more experimentation,
diversity or a clean-up. EuLisp especially was such an
attempt to create a cleaned-up Lisp. One that has some
properties that were important to its designers: smaller,
less historical baggage, 'elegant', efficient, object-oriented.

I feel that it is not a good idea to attach technical issues
to a particular dialect. Then you also would need to start a lot
of renaming. Generic Functions would be 'functions like
in CLOS' and so on. Other Lisp dialects also have Generic Functions. ....


Check out Queinnec's book where he discusses the technical
issues in context of various implementation strategies.
He also mentions that (some) Scheme compilers internally transform
Lisp-1 code to Lisp-2 code.


EuLisp and ISLisp come after Scheme. Like Common Lisp.
Common Lisp was also designed after Scheme.
I see that ISLisp is also a Lisp2. A new revision of the standard
has been published in 2007:
http://www.open-std.org/JTC1/SC22/WG.../standard.html

Some dates when some Lisp dialects were designed:

Scheme: 1975- 2007 (R6RS)
Lisp Machine Lisp: 1978 (first spec) -?
Common Lisp: 1981 (first discussions) 1984 (CLtL1) -
1990 (CLtL2) - 1994 (ANSI Standard)
EuLisp: 1985 (first discussion) - 1993 (0.99 spec)
ISLisp: end of 1980s-1997 (spec published) - 2007 (revision)


The Common Lisp designers had two main concerns when
it comes to Lisp1 vs Lisp2: existing practice (which also
means lots of existing code) and efficiency for (compiled)
code. Efficiency was important, both for vendors (and their
customers) and users. If somebody had a large piece of software,
it should not run slower in the new language, just because
somebody added more baggage to it. Common Lisp was a
compromise - it looks and feels that way. It was built
on a lot of existing experience. It was certainly more safe
to use existing practice, than to adopt radical new stuff.
There was already enough 'new' stuff. For example
the introduction of 'lexical binding' (by default) in a
MacLisp-derived language.