Keyword extensions to Compile

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

Since day one we have emphasized that, while Common Lisp should be a
perfectly usable language in its own right, many implementations would
be supersets of Common Lisp.  That was an essential part of the original
treaty.  The participation of Symbolics, in particular, was absolutely
conditional on this point of view, since many beloved Lisp Machine
features (beloved by Symbolics people at the time, anyway) obviously
made no sense in a language that also had to be implemented on stock
hardware.  For many years, Symbolics people made a fetish of always
referring to "the Common Lisp subset" rather than just "Common Lisp",
though that seems to have gone away.

For implementation X to be a superset of Common Lisp means that Common
Lisp programs written according to the manual will run in X, but that
many legal programs in implementation X will not be portable Common Lisp
and will not necessarily run in implementation Y.  Or, put another way,
you make a superset by taking various cases that are errors in vanilla
Common Lisp and by giving them useful interpretations in your superset.
This is usually done with undefined functions, but it can also be done
by adding new keywords to old functions or by extending type-specific
functions to take new types of arguments that would otherwise be in
error.  There is some controversy over whether it is allowable to extend
an implementation by returning extra values from built-in functions; I
favor allowing this, but it is possible (not natural, but possible) to
write legal Common Lisp code that would be screwed by this.

I think that we should require an implementation to document any such
extensions, and encourage implementors to provide a "portable" compiler
mode that flags any use of non-standard extensions.  But to outlaw
extensions at this late date is impossible.  I agree that it would be a
good idea in an implementation to have a package (not necessarily the
LISP package) in which nothing but pure Common Lisp is visible.  I think
we can encourage this, but I'm not sure about requiring it.

    Put another way, I think that every implementation should pick some other
    package and put all their extensions on that package and leave the LISP
    package pure. We've hashed this one out at length. If someone doesn't
    think that there was overwhelming concensus that this was the right
    thing, I'd like to hear from them.

I don't think that consensus was reached on this.  There was mail on
both sides, and in the absence of a decision procedure, the discussion
eventually petered out.  This will certainly be among the issues we want
to get a final decision on as the ANSI spec is developed.

Since you ask, my own view is (still) that each implementation will want
to provide a default Lisp environment for their users, including all of
Common Lisp plus some implementation-specific extensions, and that this
is what should live in the LISP package and be inherited by default in
other packages such as USER.  It is certainly a good idea to have some
other package that is pure Common Lisp, but this should not be the
default environment for users.  The mix of things in the default
environment should be a local option.

-- Scott