Compiling CASE

[Hvatum@MIT-MULTICS.ARPA]

From: Steve Bacher (Draper Lab)
In-Reply-To: DCP at SCRC-QUABBIN, DFM%JASPER at LIVE-OAK.LCS.MIT.EDU,
             Masinter.pa at XEROX.COM
 
OK, the CLtL paragraph on page 57 is well known to me.  But what if
the user redefines a macro, which is presumably legal?  It may be
an error to redefine a special form, but what protection does the
LISP system have from the user doing it to a macro (or, better perhaps,
what protection does the user have from the LISP system ignoring such a
redefinition)?
 
Seems that the user will somehow have to know which macros are really
implemented as special forms, or at least special-to-compiler forms,
or else the compiler will have to be able to distinguish between
built-in macro definitions and user-provided macro definitions.
 
Probably this isn't that hard to do for an implementation developed
from scratch.  In fact, a macro like CASE could expand alternately
into SYSTEM::INTERNAL-SPECIAL-FORM-CASE sometimes, and
SYSTEM::INTERNAL-MACRO-CASE other times.
 
To Don Morrison:  What is the meaning of declaring a MACRO NOTINLINE?
CLtL doesn't imply that this is even possible.
 
(Which is not to say that CLtL implies that it ISN'T possible - I'm
being very careful with my wording here.)
 
Btw, looking at page 57 again I see that CLtL explicitly states that
the compiler may have special knowledge about forms like TYPECASE.
So I guess the only issues left are how to deal with user-provided
redefinitions, which should be properly handled by most implementations
in their own ways; and what code-walkers should do with them.
 
As far as what one code-walks for, there are two general areas:
 
(1) truly portable code-walking, e.g. looking for certain kinds of
    function or variable references.  Such walking needs to know
    only about syntax, and cares little for how constructs are
    actually implemented.  Thus, it's OK to do maximal macroexpansion
    and minimal special-form analysis.
 
(2) internal-use code-walking, e.g. the kind done by a phase of the
    compiler.  This is not limited to chunks of the compiler itself,
    as various metasystems (e.g. source transforms) may wish to
    code-walk to aid in compilation of a particular body of code.
    Here, any special knowledge the compiler has about certain forms
    must be retained, and it would be inadvisable to macroexpand such
    forms.
 
Thing is, (2) is not limited to compiler hackers; users will wish to
provide their own functions to perform such code-walking feats.
Therefore, there ought to be a standard way of telling whether a
particular symbol names a form of which the compiler has special
knowledge.  Perhaps COMPILER-SPECIAL-FORM-P?
 
(Of course, the question is then what to do with the damned thing...)
 
To Larry Masinter:  Where is the quote in CLtL that supports your
statement that it is an error to redefine any of the built-in
functions or macros defined in Common LISP?
 
The package system will not protect Common LISP from having its
functions redefined, since a user who wants to define his/her own CAR
function will likely not call it USER:CAR; thus, since there is
already a CAR in the LISP package, that's the one that will get defined.
 
Maybe you think this is a silly example.  What if the function was not
CAR, but (say) ENCODE-UNIVERSAL-TIME?  It is reasonable to suppose
that Joe Lisphacker will not wish to look up every potential
function name to see if it is already defined.  It is also not
reasonable for the compiler to reject this usage because it is an
error to redefine ENCODE-UNIVERSAL-TIME (and it is even worse for it
NOT to tell you because, after all, it's only "an error" and the user
doesn't have to be warned).  It's also likely that the interpreter
will make different choices in the same matter, probably all bad ones.
 
What we wind up with here is COBOL LISP, with 775 reserved words,
subject to increase with the next edition of the reference manual.