Rules of the game and stability

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

The charter committee has indeed been too inactive of late, and even
when we were active we were concentrating more on organizational issues
than on the proper philosophy for stability versus fixing things.  I'll
try to fire this discussion up again, once I get finished with some
immediate demands on my time.  I sort of put things on hold until we all
could get some idea of what services the DARPA/ISI contract was going to
provide, and when.

I agree with Guy's list of the kinds of changes that might be
considered, in increasing order of disruptiveness.  I would only add
that there is a lot of variation in each of these categories: an
incompatible change in the cut points of obscure trig functions is not
going to disrupt things as much as, say, an incompatible change in the
handling of special variables.  Additions to the language are not a
burden if accompanied by portable code that implements the addition.
Other additions might not be implementable in a portable way, but would
obviously require only very minor and local changes to implement.

I also agree that Common Lisp 84 should be considered frozen in the way
that Guy proposes: only compatible or absolutely essential changes
should be made at this point.  There should be no fundamental additions
to Common Lisp 84 either, though there is no harm in putting together a
body of quasi-standard code that can be trivially added to any complete
and correct implementation, with the understanding that these features
go into the base language the next time around.  Library files could
begin assuming the existence of these additions right now.

But having said that, I should also say that the language as it stands
is still very young, relatively untried, and full of known flaws.  We
should therefore allow for a reasonably fast evolution at the start.  I
think that for the next few years, it would be optimal to an updated
specification appear every year, or at most every two years.  I
certainly don't want to wait until 1989 or whenever in order to fix the
small but important problems that we've already identified.

I'm not talking about a major upheaval every year -- I'm sure that we
will carefully weigh the benefit of each change against the cost both to
users and implementors -- but once we've decided that a change is worth
making, we should not have to wait too long for the next release cycle
to come around.  At any time, there will be one well-defined version of
Common Lisp that corresponds to the latest official release, and another
that includes the changes that have been approved for the next future
release.  Nobody would be required to track the latter until the release
date rolls around, but some of us (in universities, maybe) should
install any such changes right away in order to verify that they do
their job as intended.

In any event, I think we should be aiming for another release as early
as possible in 1986, and the incompatible changes we have been
discussing should be considered to be proposals for that next release.

-- Scott