Guidelines

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

The following is essentially the "guideline" proposal that I sent around
before.  Aside from Fry's opinion that we should do a lot of renaming
and argument shuffling in order to make the language more consistent, I
have heard no dissenting opinions.  I would like to say that the
technical committee has accepted these guidelines.  Please read the
following and let me know soon if you have any objection.  Let's not get
bogged down tuning the language too finely on this, unless there's
something that really bothers one of you -- these are guidelines, and
not a contract.

-- Scott

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

As we develop a new language definition for Common Lisp, which we intend
to propose as an official standard, an important question is how much we
are willing to change the existing Common Lisp dialect, as described in
"Common Lisp: the Language".  The following guidelines have been
accepted by the technical commitee:

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 and some interest in Europe.

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 be much larger.

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 fundamental 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 schism, but
we believe that a moderate number of small changes will 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.