barmar@think.com (Barry Margolin) (04/03/91)
I've seen a couple of references here to "Common Lisp: The Language, 2nd
Edition" this week that suggest to me that a reminder is in order. First,
there was a reply in the comparison between Lucid and Franz that pointed
out that one of them is "only" conformant to CLtL1. Tonight I saw a
posting looking for MS-DOS CL, "preferably CLtL2".
Folks, CLtL2 does not describe Common Lisp, unless you ignore all the parts
marked with change bars (except the notices of correction, which mark clear
errors in the original edition). All the new material is simply a snapshot
of a work in progress, that being the ANSI CL standard. No attempt was
made to coordinate the X3J13 process with Guy Steele's book revision
schedule; he simply incorporated all the votes that we'd taken at the time
of his deadline. The purpose of including this stuff was to let Lisp users
and implementors who don't have representatives on the committee know where
the language is going so that they won't be caught completely by surprise,
not to define a new version of the language. Read the preface to the 2nd
edition for more details on this point. CLtL1 plus the corrections from
CLtL2 is the most correct definition of Common Lisp at this time.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmarbarmar@think.com (Barry Margolin) (04/05/91)
I'm following up to my own posting, since I've received several replies. I
want to point out that CLtL2 should not necessarily be shunned, but users
should be "careful" with it.
The most useful stuff in the new material is information about portability.
There are many new "it is an error" situations, because we noticed that
different implementation has interpreted CLtL differently. In many cases,
rather than X3J13 deciding on a particular interpretation, we decided to
make it explicit in the language that depending on such choices is not
portable. This merely makes the status quo official, since it was already
the case that programs that assumed a particular behavior were not portable
to implementation that provide the other behavior.
What users should be careful with are the *new* features. I'm told that
MCL 2.0 implements most of CLtL2. That's fine, if you only need to run
your program under MCL 2.0, and it will probably work pretty well under a
future ANSI CL. But suppose you want to port it to Lucid, Symbolics, or
Allegro before they implement ANSI CL? If you made use of lots of new
CLtL2 features, you may be out of luck.
By the way, at its last meeting, X3J13 decided to remove all the new stuff
that provides direct access to lexical environments (AUGMENT-ENVIRONMENT,
DEFINE-DECLARATION, etc.). We had determined that there were serious
design flaws with them. There were proposals to fix the problems, but many
of us weren't confident that new bugs wouldn't pop up right after, and felt
that we'd rammed this new stuff in too close to the completion of the
project. We encourage implementors to implement this stuff, but we're just
not going to require it as part of ANSI CL.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar