Date: Thu, 23 Feb 89 16:00:17 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
...
Once I ran into a problem in VaxLisp where one of the multiple value
macros was treated as a special form by the compiler. It
macroexpanded into some really terrible code and I was getting a
noticible performance hit by having my codewalker just blindly
expanding it. Even though the macro definition was semantically
correct, I ended up adding a whole bunch of macros to the list of
things my codewalker treated as "special forms". I suspect that other
implementations do similar things -- I know my A-Lisp compiler also
treated some of the multiple value macros specially as well.
Just for the record, this is something that I had worried about with the
Cloe Flavors code walker running under Symbolics Genera, but I found
that the Genera compiler had optimizers for many of the scary-looking
idioms that these macros produced, so the compiled code was identical
regardless of whether I compiled the expanded or unexpanded expression.
I have to say that this is as it should be from a `reasonable compiler'
anyway since if there are two seemingly equivalent ways to do something
and the language spec itself does not suggest that one is likely to be
more efficient than the other, the programmer should not have to fear that
just because he didn't say the right incantation, he won't get efficient
code.
...
It ought to be OK for things that are documented as special forms to be
implemented as macros that expand into other implementation-dependent
special forms, since code analyzers are expected to have special
knowledge about them instead of using the macro expansion.
This is a very good point. However, if it were to become accepted
theory, though, it should be explicitly stated. It affects whether I do
a MACROEXPAND-1 or a MACROEXPAND after the call to SPECIAL-FORM-P.
Normally I consider it safe to do either -- and slightly less cumbersome
to do the latter. However, your remark suggests that I might be safer
doing the former.