Compiling CASE

[Don Morrison <dfm@JASPER.PALLADIAN.COM>]

    Date:  Wed, 8 Apr 87 01:39 EDT
    From:  Hvatum@MIT-MULTICS.ARPA

    From: Steve Bacher (C.S.Draper Lab)
 
    The question of CASE compiling into a computed GOTO uncovers an
    interesting dilemma.  Should the compiler have special knowledge
    about certain forms which are normally macro calls, because it knows
    that they can be compiled into particular machine-code sequences,
    or should it always honor the macroexpansion?  Consider the case
    (n.p.i.) where the user provides an alternate macro definition for
    his/her own use (possibly because he/she doesn't remember that
    there already is a CASE macro).
 
    This could affect a whole class of "non-special-forms", i.e. things
    like AND, OR, COND, PROG, which are supposed to be macros in CL but
    are generally special forms in (older?) LISP implementations, and
    recognized by the compiler in order to generate optimal code.  Or
    should there be a class of "quasi-special-forms" which the compiler
    may deal with on a basis similar to that of true "special forms"
    so that the best code can get generated?  Should it be "an error" to
    redefine such macros?
 
    After all, the rationale here is to keep the number of true
    "special forms" to a small finite number to enable portable
    code walking (not "portable-code" walking), though I don't wish
    to open up THAT can of worms again.  But if this means that the
    compiler is constrained from doing clever things with AND, OR, or
    CASE, is it worth it?
 
							- SEB
 

Open compiling a macro isn't really any different in this respect than open compiling
an ordinary function like car or mapcar, which most implementations do for a great
many functions.  The rational is that so long as the user hasn't declared a function
notinline and the open coded sequence does the same thing as the real function you're
well within your rights to open code it; the same follows for macros.  Note that if
the open compiled version does the same thing as the macro, you can still code walk
(well at least that's the theory; I suspect how successful it is in practice depends
on exactly why you're code walking).

I wonder, however, if all implementations do the right thing if you declare a macro
which is treated specially as notinline?