Thread view

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
* (foo)
X
* (compile 'foo)
FOO
NIL
NIL
* (foo)
debugger invoked on condition of type UNDEFINED-FUNCTION:
The function FOO is undefined.
Within the debugger, you can type HELP for help. At any command prompt
(within
the debugger or not) you can type (SB-EXT:QUIT) to terminate the SBCL
executable. The condition which caused the debugger to be entered is
bound to
*DEBUG-CONDITION*. You can suppress this message by clearing
*DEBUG-BEGINNER-HELP-P*.
restarts:
0: [ABORT ] Reduce debugger level (leaving debugger, returning to
toplevel).
1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop.
("varargs entry for #'(LAMBDA (&REST SB!C::ARGS) (DECLARE #) ...)")
0]
(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
value."
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))))
...)
Regards
Matthias

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
> * (foo)
> X
> * (compile 'foo)
> FOO
> NIL
> NIL
> * (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
> value."
>
> 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.
Thank you.
--
William Harold Newman <william.newman@...>
"Palantir great. Better than cable."
-- <http://home.nyu.edu/~amw243/diaries/saruman.html&gt;
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C

On Mon, May 13, 2002 at 12:09:12PM +0200, Matthias Hölzl wrote:
> * (defmacro foo () ''x)
> FOO
> * (foo)
> X
> * (compile 'foo)
> FOO
> NIL
> NIL
> * (foo)
> debugger invoked on condition of type UNDEFINED-FUNCTION:
> The function FOO is undefined.
[snip]
> 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
> value."
[snip]
Having looked at the problem, I think the underlying bug is a little
different. The ANSI specification of FDEFINITION says
The value returned by FDEFINITION when FBOUNDP returns true but the
function-name denotes a macro or special form is not well-defined, but
FDEFINITION does not signal an error.
Regrettably, in current sbcl
(defmacro foo () 'foofoofoo)
(fdefinition 'foo)
=> signals UNDEFINED-FUNCTION
So without even considering the misbehavior of COMPILE, there is a bug
in FDEFINITION. It needs to return something (arbitrary) in this case,
and if we choose to have it return the same value as MACRO-FUNCTION
would, then it looks as though the COMPILE bug will be fixed without
even changing COMPILE.
Comments?
--
William Harold Newman <william.newman@...>
"When you have a train to catch, resign."
-- <http://senseis.xmp.net/?HumourAlmostProverbs&gt;
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C