Maclisp compatibility

[Fahlman at CMU-20C]

I would like to second RMS's views about Maclisp compatibility: there are
many goals to be traded off here, and any rigid set of guidelines is
going to do more harm than good.  Early in the effort the following
general principles were agreed upon by those working on Common Lisp at
the time:

1. Common Lisp will not be a strict superset of Maclisp.  There are some
things that need to be changed, even at the price of incompatibility.
If it comes down to a clear choice between making Common Lisp better
and doing what Maclisp does, we make Common Lisp better.

2. Despite point 1, we should be compatible with Maclisp and Lisp
Machine Lisp unless there is a good reason not to be.  Functions added
or subtracted are relatively innocuous, but incompatible changes to
existing functions should only be made with good reason and after
careful deliberation.  Common Lisp started as a Maclisp derivitive, and
we intend to move over much code and many users from the Maclisp
world.  The easier we make that task, the better it is for all of us.

3. If possible, consistent with points 1 and 2, we should not do
anything that screws people moving over from Interlisp.  The same holds
for the lesser-used Lisps, but with correspondingly less emphasis.  I
think that Lisp 1.5 should get no special treatment here: all of its
important features show up in Maclisp, and the ones that have changed or
dropped away have done so for good reason.

-- Scott
-------