Re: Standardization

[Guy Steele <gls@THINK-AQUINAS.ARPA>]

Here is what I think.  Common Lisp was the result of committee work that was
comparable in time, scale, openness, effort, and participation to what an
ANSI committee would have to do anyway.  A large number of people
representing diverse interests in the Lisp community were involved (yourself
included).  The work was spread over almost three years, with multiple
drafts released for reasonably public comment.  Anyone who cared to could
participate; granted that ARPANET access was essential to effective
participation, but some persons not on the ARPANET did participate (for
example, those at Texas Instruments for a while), and there were no monetary
dues (CMU footing much of the bill for replication of paper), so employees
of tiny companies and even individuals could find it convenient to
participate.  I think it is highly inaccurate to characterize this work as
"definition by implementation".

I don't view the result as cast in concrete.  Indeed, there are many parts
of it that I personally do not like and would rather see changed, but I am
willing to forego many of these issues for the sake of convergence.  On the
other hand, far from advocating acceptance of the 1984 book, I came to the
December meeting armed with a lengthy list of suggested changes, and I would
be surprised if others did not also propose changes.  But it would be
foolish for an ANSI or ISO committee to ignore the great investment of
effort that went into Common Lisp, the result of the collective wisdom of
dozens of Lisp experts, and start over again from scratch.  I say this
because I think the overall structure of the result would be pretty much the
same, resulting from a set of random compromises that everyone dislikes a
little bit but is willing to work with.  Some of the details might differ,
but the details are, after all, easier to change than the overall structure.

You are quite correct that Common Lisp is not a single thing; fear not: two
names will surely come into use as soon as there is a second thing to name.

Everyone realizes that it would be impossible simply to rubber-stamp the
1984 book because it has too many ambiguities and holes.  Some change is
necessary.  In particular the subject of error handling must be addressed,
and object-oriented programming may be useful to standardize on also.
Programming environments and subsets or cores are appropriate topics for the
committee to address.

Compare this with the work of X3J11 (C language): the committee did not
hesitate to make radical changes where they were clearly called for or where
various implementations differed wildly.  This includes the syntax and
signedness of integer constants and the syntax for declaring functions.  On
the other hand, they did not synthesize a generally C-like language from
scratch.  They started with an existing document that was widely accepted
(though recognized as faulty) and realized that public acceptance of a new C
standard depended in part on not deviating from the existing widely accepted
document without good cause.  While I served on that committee, any
discussion of a major deviation from K&R was invariably accompanied by an
explicit discussion of how to state clearly and precisely the reasons for
recommending the deviation.

I am certain that no one on the technical committee has the purpose of
simply stonewalling with the current Common Lisp definition against either
other US interests or Lisp experts in other countries.  Fahlman, Gabriel,
and I, in particular, have been working hard to interest people outside the
US in contributing to the ANSI effort and to negotiate ways in which, for
example, the Common Lisp and Eulisp communities can cooperate.

--Guy