Subject: Re: New CL (Was Re: Lisp per se)
From: Erik Naggum <>
Date: 1997/04/21
Newsgroups: comp.lang.lisp
Message-ID: <>

* P. Srinivas
| CL is now at cross roads. If we miss the chance, it might die, not
| because of its weekness as lisp language, but because of our neglect. 20
| years from now somebody will come along and say tghings such as lisp is
| not a good language and give the example of CL that would have
| disappeared by then.

Common Lisp has only recently been standardized.  give us all a rest while
we're trying to digest the standard, make marginal notes on improvements
and ambiguities, form the intelligent questions we need to ask, and let the
vendors produce completely conforming Common Lisp implementations that can
be _trusted_ for the next 10 years.  we're really not in the hurry that
plagues the Windows/Intel world.  Lisp projects are big enough investments
to be affected by climate and standards committees.  most of the "modern"
stuff out there is small enough to be affected by weather and advertising.

the period following a standard's approval is generally one of resignation.
a lot of people didn't get what they wanted, while others face the task of
building conforming implementations.  many very good people will see that
their task is done, and leave, exhausted.  but businesses need to recover
the losses they took while being heavily engaged in the standards actitivy
over many years.  standardization is like foreign aid -- those who don't
engage in it are short-term winners, but those who set the agenda for a
developing industry can reap vast profits later.  but unlike foreign aid,
businesses have definite goals and need to reap those profits before they
can go on.  please don't deny them that opportunity.

a hurried deconstruction of the trust and stability that has been built
into the enormous document known as ANSI X3.226 will surely kill Common
Lisp.  spread uncertainty, and people won't plan on using your improving
technology until it has, in fact, improved.  (something brand new will be
given the benefit of the doubt, but something that works well, but somebody
tells you will be improved, doesn't get that benefit.)  in times of rapid
change, the range of people's planning is reduced from decades to months.
please don't inflict that on Common Lisp.  (if you don't kill Common Lisp,
you will kill all the incentives to produce conforming implementations.)

yes, there are things I want to change, too, but I trust that I can work
with the vendor of the Lisp I use to get it, and I can code most of it
myself if not.  maybe in 5 years' time, I'll be able to join a roomful of
Lisp experts in ANSI X3J13 and be able to contribute something instead of
just being a rebel without a clue.  maybe other people will need less time,
but my take on the standard is that not even the brilliant people who
brought it forward to completion know _exactly_ what it says at this time.

having taken part in a standardization process, I know how hard it is to
remember the _final_ of the many wordings used in drafts, and with all the
context that we carry around when writing, there may be inconsistencies
caused by the time of last update, if nothing else.  if we hurry this
process, we will undo the careful construction of precise meaning that goes
into requirements in a standard.

ANSI X3.226 is due for a 5-year review in 1999.  at the first review of a
standard, it is usual to clarify, not change.  at the second review of a
standard, it usually becomes necessary to make changes.  that's 10 years.
if a standard is worth having in the first place, 10 years is not a long
time for it to live.

ANSI X3.159 was approved in 1989.  it is facing a serious make-over in ISO
these days.  the Committee Draft was recently sent out for registration.
the standard should be approved and published within two years, if the
schedules are met.  that's also 10 years.  (X3.159 is C.)

ANSI X3.159 received an enormous number of requests for clarification in
its first few years.  I don't know of any requests for clarification to
ANSI X3J13.  (I asked when I ordered my copy of ANSI X3.226.)

as I have argued elsewhere, standardization and evolution should not
overlap.  if there is significant evolution, a standardization process
might kill it or we might standardize prematurely.  both are bad.

right now, I want most of all to see perfectly conforming implementations
built and sold with significant profits by the very good people who produce
Common Lisp systems.  I want this for two reasons: (1) I want to point to
Common Lisp the Standard and say like Guy Steele said in 1990: "Common Lisp
has succeeded".  if I can't do that, I really can't argue for the success
of a pie-in-the-sky _improved_ Common Lisp, either.  (2) I want to uncover
all the things in Common Lisp that are hard to implement, not used in
practice even it is implemented right, either because it's insufficient or
because it doesn't address the envisioned problems, 

I don't think we learn what's right from mistakes, we learn what's wrong,
what _not_ to do.  if we can't do something right after such an enormous
effort like that which went into Common Lisp the Standard, I for one would
have very slim hopes of doing it better the next time.  after a mistake has
been uncovered in a standard or any specification, you wouldn't believe the
number of "good ideas" that surface from know-it-alls.  all the old rejects
crawl out of the woodwork at such a time and some standards aren't improved
simply because the editor has to put a cap on the "good ideas".

if Common Lisp shall be improved, it must be done by people who think what
we have today is _not_ a product of mistakes, but the best that could be
done at the time, and they have to understand the reasons why it was the
best that could be done.  only then can they improve on it with any hope of
getting actual improvement, even if it means changing directions somewhat.
the biggest problem with this approach is that people who really understand
something as big as Common Lisp the Standard are very hard to come by.

on a related note, I attempted to post a question on "designators" to
comp.std.lisp a couple months ago.  I neither heard from the moderator nor
saw the article posted nor got any replies.  if we wish to discuss renewed
standardization of Lisp, I suggest that whoever is in position to revive
comp.std.lisp do so.  such debates should not go in comp.lang.lisp, and
probably not in wide open fora like USENET in the first place.

Bastard Sex Therapist from Hell: "Read the F*cking Manual!"