[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Wed, 8 Apr 87 01:39 EDT
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?
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?