Newsgroups: comp.lang.lisp
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Subject: Re: CLtL2 is not official
Message-ID: <1991Apr5.002613.26490@Think.COM>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <1991Apr3.060648.13283@Think.COM>
Date: Fri, 5 Apr 91 00:26:13 GMT

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