From: <Mat...@t-...> - 2002-05-13 10:09:20
|
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 |
From: William H. N. <wil...@ai...> - 2002-05-13 22:42:56
|
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 <wil...@ai...> "Palantir great. Better than cable." -- <http://home.nyu.edu/~amw243/diaries/saruman.html> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: William H. N. <wil...@ai...> - 2002-05-15 16:10:02
|
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 <wil...@ai...> "When you have a train to catch, resign." -- <http://senseis.xmp.net/?HumourAlmostProverbs> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: William H. N. <wil...@ai...> - 2002-05-19 22:51:32
|
On Wed, May 15, 2002 at 11:08:18AM -0500, William Harold Newman wrote: > 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 [snip] > Regrettably, in current sbcl > (defmacro foo () 'foofoofoo) > (fdefinition 'foo) > => signals UNDEFINED-FUNCTION I seem to have been somewhat confused. As far as I can see today, your fix is fine, and I have merged it in sbcl-0.7.3.21. Thank you. -- William Harold Newman <wil...@ai...> "We are playing a variant of the ancient game of 'Chicken,' a game popular with adolescent males and great statesmen." -- <http://www.daviddfriedman.com/laws_order/index.shtml>, ch. 8 PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |