Guidelines for the Standard

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

Before we start discussing specific technical issues, we should discuss
in a general way what we want to achieve by this process.  In
particular, we need to think about how much we are willing to change the
language from what is described in "Common Lisp the Language".  I hope
we won't get bogged down in this discussion, but if we can set up some
explicit guidelines for ourselves now, it may eliminate a lot of
confusion about our goals later on, while we are working on technical
issues.  I say "guidelines" because there is no way we can agree to a
set of strict and binding rules at this point.  But at least if we have
a set of guidelines, the burden will be on the person who argues that we
should violate them in some specific case.

I have heard a variety of opinions on the issue of how closely we should
adhere to CLtL.  Some have argued that the existing Common Lisp is so
terribly flawed that it should not become a standard; we would be better
off starting over.  Others have argued that in the first attempt to
standardize a Lisp under ANSI and ISO, we should not deviate at all, in
incompatible ways, from the language as described in Steele.  These
people argue that we should get a stable standard in place, and then do
any necessary tuning in subsequent versions.

I think that most of us are somewhere between these two extremes.  Let
me set forth my own view of what our guidelines should be, which I think
a lot of people share.  Comments are welcome.

-- Scott

---------------------------------------------------------------------------

Despite its imperfections, Common Lisp is already a standard.  Nearly
every U.S. company with a presence in the AI market has announced some
sort of support for Common Lisp (though not always to the exclusion of
supporting other Lisps).  There is similar interest in Japan among those
companies not totally committed to Prolog.

It is now our goal to turn Common Lisp from a de facto standard into an
official one.  In the process, we have the opportunity to clarify those
things that are currently ambiguous (and which therefore weaken the
standard), to fix some problems that defeat the purpose of the standard
(e.g. problems that make it hard to write portable code), and to finish
defining some essential parts of the language that we left unfinished in
the rush to complete CLtL.

There are a number of implementations on the market, and many more in
the pipeline.  There are many hundreds of active users, and this number
is growing very fast.  A number of large software systems and AI
toolkits have been ported to Common Lisp, and again this is an
accelerating trend.  All of this says that there is a very large
investment in the existing language; by the time a standard could be
approved, this investment will probably have doubled.

The existence of a large and fast-growing user community cuts two ways.
On the one hand, for every change that we consider, we must think about
not only the merits of making the change, but also the cost in terms of
code that must be changed and users who must be retrained.  On the other
hand, if a change is unavoidable, the sooner we make it, the smaller the
cost.

Different kinds of changes have different kinds of costs:

Compatible extensions cost the users nothing (except that they make an
already complex language more complex).  The cost is to the various
Common Lisp implementors who have to put the extension into their
respective products.  If the extension is rather small, or if it will be
easy to implement (perhaps because someone supplies a public-domain
implementation of the extension), then we can consider the proposal on
its merits alone.  If the extension requires some significant
implementation to make a lot of internal changes, then the threshold is
considerably higher.

In the case of true ambiguities (where implementors really have chosen
divergent interpretations, and not just where some clever fellow can
find a loophole in the language of CLtL), it is generally worthwhile to
make a clear choice, even though one group or another is going to have
to fix things.  In some cases it will be appropriate to explicitly allow
both interpretations, but not where this tends to interfere with
portability of code.

Changes that affect a lot of existing user code should not be made
unless there are VERY strong reasons for doing so.  Changes that would
break things in subtle ways are the worst -- something like changing the
type of NIL, for example, would break all sorts of things.  Changes to
particular functions, which can be searched for by name and fixed in
straightforward ways, are not quite so bad.  Changes to obscure corners
of the language that only concern a small minority of users are not so
bad, especially if the change benefits that small community and is
favored by them.  For example, if there's some subtle issue about
roundoff that should be changed in order to make the number crunchers
happy, we could consider this.

In general, changes that affect only the implementors are less costly
than changes that affect all sorts of user code; there are fewer groups
that have to make changes, and they have more resources for doing so.
We must not overburden the implementors with changes or it will cause
delays and disruptions, and it could conceivably lead to a revolt, but
my guess is that a couple of dozen changes, each of which takes a
person-day or two to implement, would not be resented if the changes are
made for good reason.  From the time a change is approved until the time
it becomes part of some Official Standard will be on the order of a
year.  That's plenty of time to make the changes and to build and test a
new version, even for the most ponderous of companies.

There's a lot of interest in improving code portability, settling on a
workable error system, and trying to agree on an object-oriented
programming facilty (or foundation for one).  If any of these goals
requires some change, that probably counts as a good reason.  At this
point, mere aesthetic considerations are not sufficient to justify an
incompatible change.