Rules of the game

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

    Date: Wed, 22 May 85 21:20 EDT
    From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM@think>

				 ... I think it's important that we decide
    what our philosophy is about "changes to Common Lisp", particularly in
    light of the fact that the manual has been published and is now on the
    shelves of bookstores.  What does it mean for us to "make a move"?

				  ...  I just think we'd spend our time
    better if it were somewhat more clear what game we are playing and what
    the rules are, and I'm worried that we're spending a great deal of time
    and energy designing Common Lisp after the horse has been let out of the
    barn.  Are we really designing a new second-generation Common Lisp?  Or
    are we proposing to tell the world shortly that the book isn't really
    the Real Common Lisp, please make the following forty changes to your
    copy?  Once we have answered this question, then we can agree on a general
    philosophy about what degree of change is allowable.

My attitude is that the horse is indeed out of the barn.  I believe that changes
of the following five kinds are appropriate.  I list them in order of increasing
seriousness and likeliness to cause disruption:

(1) Typographical and editorial corrections (such as a better index!).  In
this category I would place changes in terminology that would leave code
unaffected.  For example, changing the term "special form" to "special
operator" would fall into this category, but renaming SPECIAL-FORM-P to
SPECIAL-OPERATOR-P would not.

(2) Substantive elucidations of intent.  An example of this is my reply earlier
today elucidating what is supposed to happen when adjusting an array to which
another array is displaced.

(3) Compatible extensions to the language (such as adding a quaternion data type,
or flavors, or Bessel functions, or PARSE-BODY, or the proposed three-variable
&BODY feature for DEFMACRO).

(4) Incompatible changes to existing features because they cannot possibly
operate correctly as specified.  An example is the recent report that
GET-SETF-METHOD needs to take an environment argument.

(5) Incompatible changes required to bring Common Lisp into conformance with
an external standard.  This category is fraught with danger, and the benefits
must be weighed carefully.  An example is the proposal to change the branch
cuts of arctangent to conform to expected practice by the APL and IEEE
proposed floating-point communities.


I believe that it is too late for incompatible changes for the sake of
clarity, consistency, or convenience.  Therefore I would strongly oppose
renaming or removing any existing function or feature.  (This represents a
reversal of my previous position on the proposal to eliminate expansion of
macros into declarations.)

--Guy