CL defmacro bug report

[kddlab!atr-la.atr.co.jp!myers@uunet.UU.NET (John K. Myers)]

The following problem is reported for your information.
It was observed on an Allegro CLiP 3.0.3 [sequent] system.

\subsection{Compiling a Function Once Does Not Deinstall a Macro with the
Same Name}  Sometimes known as the ``Undead Macro'' or the ``Macro From
Hell'' problem, this
feature is particularly nasty.  If a macro is changed into a function
with the same name, the system will still use the macro definition
instead of the function definition for the {\em source code}, apparently
until the time after the file containing the new function has been
compiled and loaded.
Thus, the next compilation will reuse the old macro definition.
The symptoms of the problem are consistent with the following behavior:
The function definitions are saved as the file is compiled, and
installed on their symbols after the end of the file is reached.
However,  macro definitions are installed on their symbols as they are defined.  Any
macro that was previously defined remains in effect until it is
redefined in the source code by another defmacro, or until after the file
containing a new function definition has been compiled and loaded.
A function does not redefine a macro until after it has been loaded.
Thus, if a function redefines a macro at the beginning of a file, the
redefinition will not take effect until the file has been completely
compiled and loaded--and all the calls to the function will have been
compiled as calls to the old macro.  The way to fix this feature seems
to be to both compile and load the program, twice.  Note that the source
code must be a different version in order for {\tt :cl} to consider
recompiling it--modify one character up and back and then save the new
result to get a new version.

As an example, say that you are debugging a difficult macro (e.g. {\tt
my-format}) that has problems with the level of evaluation of its
arguments--it comes up with the wrong answer.  Of course, the macro is
defined before the test routines that use it in the source code.  Now
say that you decide to turn the macro into a function-building function, because
the level of evaluation should be different.  You change the source
appropriately, compile and load the program.  You run the compiled test
routine, but you get the same mistakes.  The compiler secretly reuses
the old definition of the macro, even if the function definition is before the
test code calling it in the source.  However, if you test {\tt my-format}
by hand directly at the interactor level, it uses the {\em new} definition,
thus adding to the confusion.  If you are lucky, you change something
else in the code, recompile, and the old macro definition has gone away
so you get the new function definition this time.  If you're not lucky,
you spend half a day chasing down a bug that's not there.

Note that no warning messages are given when a function redefines a
macro in the environment.
Also, even if a function redefines a macro in the same file,
no warning message is presented.
Also, if a macro redefines a macro in the same file, no warning message
is presented.

------------------
(end of bug report)

John Myers

myers@atr-la.atr.co.jp