On Mon, May 13, 2002 at 12:09:12PM +0200, Matthias Hölzl wrote:
> The function COMPILE does not seem to handle macro definitions
> correctly. Using sbcl 0.7.2 I get the following behavior:
> * (defmacro foo () ''x)
> * (foo)
> * (compile 'foo)
> * (foo)
> debugger invoked on condition of type UNDEFINED-FUNCTION:
> The function FOO is undefined.
Yep, that looks broken.
> (I cannot currently bootstrap sbcl on my system, but the relevant code
> is not changed in sbcl 0.7.3)
> The reason for this behavior is that COMPILE always compiles the
> FDEFINITION of the symbol and only then checks whether to install it as
> MACRO-FUNCTION or FDEFINITION. According to the HyperSpec the behavior
> should be
> "If a non-nil name is given, then the resulting compiled function
> replaces the existing function definition of name and the name is
> returned as the primary value; if name is a symbol that names a macro,
> its macro function is updated and the name is returned as the primary
> The definition of /macro/ points to /macro name/:
> "macro name n. a name for which macro-function returns true and which
> when used as the first element of a compound form identifies that form
> as a macro form."
> Therefore I think that the correct fix would be to change the initial
> value for DEFINITION in the function COMPILE to
> (defun compile (name &optional (definition (or (macro-function name)
> (fdefinition name))))
OK, that sounds pretty reasonable. In my currently-checked-out copy of
SBCL I'm already busy with some fixes to GET-MACRO-CHARACTER, so I
won't do it immediately, but after I finish testing, possibly fixing,
and checking in the GET-MACRO-CHARACTER stuff I can try fixing COMPILE
bug along the lines you suggest.
William Harold Newman <william.newman@...>
"Palantir great. Better than cable."
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C