Divergence

[Jon L White <JONL at MIT-MC>]

You raise an extremely important point;  the slow evolution of Lisp
which has taken place over the past 10 years has been mostly "conservative"
(i.e., upward-compatible including bugs and misfeatures).  The several
"radical" departures from basic Lisp failed to get wide acceptance for just
that reason -- e.g., XLISP at Rutgers and MDL here at MIT.

    Date:  5 MAR 1982 1129-PST
    From: MASINTER at PARC-MAXC
    Divergences in Common-Lisp from common practice in the major dialects
    of Lisp in use today should be made for good reason.
    The stronger the divergence, the better the reasons need to be.
    The strength of the divergence can be measured by the amount of
    impact a change can potentially have on an old program:
     little or no impact (e.g., adding new functions)
     mechanically convertible (e.g., changing order of arguments)
     mechanically detectable (e.g., removing functions in favor of others)
     not mechanically detectable (e.g., changing the type of the empty list).
    . . .

However, I'd like to remind the community that COMMON-LISP was never
intended to be merely the merger of all existing MacLISP-like dialects.
Our original goal was to define a stable subset which all these
implementions could support, and which would serve as a fairly complete
medium for writing transportable code.  Note the important items:
	stability
	transportability  (both "stock" and special-purpose hardware)
	completeness      (for user, not necessarily for implementor)
	good new features
Each implementation has to "give a little" for this to be a cooperative
venture; I certainly hope that no one group would be refractory to
another group's issues.

Previous notes from RMS and myself tried to make the case, as succinctly
as possible, for () vs NIL;  these arguments may be better appreciated
by a relative newcomer to Lisp [and it is the future generations who will
benefit from the "fixes" applied now].  I believe that many in the current
user/implementor community *** who have already adapted themselves to the
various warts and wrinkles of Lisp *** have overestimated the cost of
the NIL/() change and underestimated the impact of the "warts" on future
generations.

My note titled "How useful will a liberated T and NIL be?"
attempts to show that only the worst malice-aforethought cases will
cause problems, despite the potential loophole for failure at
mechanical conversion.  As Benson put it, probably the only place
where the "compatibility" approach [i.e., setq'ing NIL to ()] may
fail is in instances of "'NIL", and similar constructs.