CLHS says:
Macro DEFUN
Syntax:
defun function-name lambda-list [[declaration* | documentation]] form*
=> function-name
Arguments and Values:
function-name---a function name.
and the glossary:
function name n. 1. (in an environment) A symbol or a list (setf symbol) that is the name of a function in that environment. 2. A symbol or a list (setf symbol).
Therefore (defun f () ...) should return the symbol F, not the function F.
Unfortunately, after having loaded quicklisp, it looks like abcl switches to another definition, which returns a function instead of a name:
(macroexpand '(defun (x) (1+ x)))
Before: (SYSTEM:%DEFUN (QUOTE F) (LAMBDA (X) (BLOCK F (1+ X)))) (correct)
After: (PROGN (SYSTEM:%DEFUN (QUOTE F) (SYSTEM:NAMED-LAMBDA F (X) (BLOCK F (1+ X))))) WRONG.
On Sat, Nov 20, 2010 at 7:26 AM, Pascal J. Bourguignon pjb@informatimago.com wrote:
CLHS says:
Macro DEFUN
Syntax:
defun function-name lambda-list [[declaration* | documentation]] form*
=> function-name
Arguments and Values:
function-name---a function name.
and the glossary:
function name n. 1. (in an environment) A symbol or a list (setf symbol) that is the name of a function in that environment. 2. A symbol or a list (setf symbol).
Therefore (defun f () ...) should return the symbol F, not the function F.
Unfortunately, after having loaded quicklisp, it looks like abcl switches to another definition, which returns a function instead of a name:
(macroexpand '(defun (x) (1+ x)))
Before: (SYSTEM:%DEFUN (QUOTE F) (LAMBDA (X) (BLOCK F (1+ X)))) (correct)
After: (PROGN (SYSTEM:%DEFUN (QUOTE F) (SYSTEM:NAMED-LAMBDA F (X) (BLOCK F (1+ X))))) WRONG.
I don't know what's causing the definition of DEFUN to change; but anyway both of your code snippets correctly return the symbol F. Are you sure that's the exact macroexpansion you get? (btw, the macroexpand form should be (macroexpand '(defun F (x) (1+ x))) -- f was missing). I'll try later to load quicklisp and reproduce the problem.
Cheers, Alessio
Hi Alessio, Pascal,
The definition of DEFUN changes when the compiler is loaded (because it's redefined in precompiler.lisp).
In this case you're correct Alessio, that they return the same thing. However, the form should have been (PROG1 ...) instead of (PROGN ...), because if there's documentation, the docstring will be returned, I think. (it'll contain an additional (SETF (fdocumentation ...) ...))
My guess is that Pascal is running into issues with functions with documentation at the start of the body.
Is that it?
Bye,
Erik.
On Sat, Nov 20, 2010 at 10:32 AM, Alessio Stalla alessiostalla@gmail.com wrote:
On Sat, Nov 20, 2010 at 7:26 AM, Pascal J. Bourguignon pjb@informatimago.com wrote:
CLHS says:
Macro DEFUN
Syntax:
defun function-name lambda-list [[declaration* | documentation]] form*
=> function-name
Arguments and Values:
function-name---a function name.
and the glossary:
function name n. 1. (in an environment) A symbol or a list (setf symbol) that is the name of a function in that environment. 2. A symbol or a list (setf symbol).
Therefore (defun f () ...) should return the symbol F, not the function F.
Unfortunately, after having loaded quicklisp, it looks like abcl switches to another definition, which returns a function instead of a name:
(macroexpand '(defun (x) (1+ x)))
Before: (SYSTEM:%DEFUN (QUOTE F) (LAMBDA (X) (BLOCK F (1+ X)))) (correct)
After: (PROGN (SYSTEM:%DEFUN (QUOTE F) (SYSTEM:NAMED-LAMBDA F (X) (BLOCK F (1+ X))))) WRONG.
I don't know what's causing the definition of DEFUN to change; but anyway both of your code snippets correctly return the symbol F. Are you sure that's the exact macroexpansion you get? (btw, the macroexpand form should be (macroexpand '(defun F (x) (1+ x))) -- f was missing). I'll try later to load quicklisp and reproduce the problem.
Cheers, Alessio
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On Sat, Nov 20, 2010 at 10:38 AM, Erik Huelsmann ehuels@gmail.com wrote:
Hi Alessio, Pascal,
The definition of DEFUN changes when the compiler is loaded (because it's redefined in precompiler.lisp).
In this case you're correct Alessio, that they return the same thing. However, the form should have been (PROG1 ...) instead of (PROGN ...), because if there's documentation, the docstring will be returned, I think. (it'll contain an additional (SETF (fdocumentation ...) ...))
My guess is that Pascal is running into issues with functions with documentation at the start of the body.
Is that it?
You're right Erik, it should be PROG1, because PROGN returns the docstring as you said; I verified it by loading the compiler and then issuing a DEFUN with docstring. However, Pascal says DEFUN returned the function object, not the docstring, so there may be even another case (perhaps still caused by the incorrect PROGN).
Alessio
On Sat, Nov 20, 2010 at 10:45 AM, Alessio Stalla alessiostalla@gmail.com wrote:
On Sat, Nov 20, 2010 at 10:38 AM, Erik Huelsmann ehuels@gmail.com wrote:
Hi Alessio, Pascal,
The definition of DEFUN changes when the compiler is loaded (because it's redefined in precompiler.lisp).
In this case you're correct Alessio, that they return the same thing. However, the form should have been (PROG1 ...) instead of (PROGN ...), because if there's documentation, the docstring will be returned, I think. (it'll contain an additional (SETF (fdocumentation ...) ...))
My guess is that Pascal is running into issues with functions with documentation at the start of the body.
Is that it?
You're right Erik, it should be PROG1, because PROGN returns the docstring as you said; I verified it by loading the compiler and then issuing a DEFUN with docstring. However, Pascal says DEFUN returned the function object, not the docstring, so there may be even another case (perhaps still caused by the incorrect PROGN).
Anyway, I committed the fix changing PROGN to PROG1 in precompiler.lisp.
Hi Alessio,
I think the key is a bit higher up; something must be causing quicklisp to load precompiler.lisp, but not the actual compiler.
Higher up, there's an expression (fset ...); I'm not sure, but I think that might be returning the expression, not the function name.
Bye,
Erik.
On Sat, Nov 20, 2010 at 10:45 AM, Alessio Stalla alessiostalla@gmail.com wrote:
On Sat, Nov 20, 2010 at 10:38 AM, Erik Huelsmann ehuels@gmail.com wrote:
Hi Alessio, Pascal,
The definition of DEFUN changes when the compiler is loaded (because it's redefined in precompiler.lisp).
In this case you're correct Alessio, that they return the same thing. However, the form should have been (PROG1 ...) instead of (PROGN ...), because if there's documentation, the docstring will be returned, I think. (it'll contain an additional (SETF (fdocumentation ...) ...))
My guess is that Pascal is running into issues with functions with documentation at the start of the body.
Is that it?
You're right Erik, it should be PROG1, because PROGN returns the docstring as you said; I verified it by loading the compiler and then issuing a DEFUN with docstring. However, Pascal says DEFUN returned the function object, not the docstring, so there may be even another case (perhaps still caused by the incorrect PROGN).
Alessio
On Sat, Nov 20, 2010 at 11:04 AM, Erik Huelsmann ehuels@gmail.com wrote:
Hi Alessio,
I think the key is a bit higher up; something must be causing quicklisp to load precompiler.lisp, but not the actual compiler.
Higher up, there's an expression (fset ...); I'm not sure, but I think that might be returning the expression, not the function name.
Yes, I see. Actually if I understand it correctly it will only be used in file compilation; yet it could cause problems with "strange" forms like (setq foo (defun ...)) where foo will be set to the function object instead of the function name, only when loading the FASL, not when loading the source. I'll experiment a bit with this and if I'm right, I'll commit another fix.
Thanks for the tip!
Later, Alessio
On Sat, Nov 20, 2010 at 11:36 AM, Alessio Stalla alessiostalla@gmail.com wrote:
On Sat, Nov 20, 2010 at 11:04 AM, Erik Huelsmann ehuels@gmail.com wrote:
Hi Alessio,
I think the key is a bit higher up; something must be causing quicklisp to load precompiler.lisp, but not the actual compiler.
Higher up, there's an expression (fset ...); I'm not sure, but I think that might be returning the expression, not the function name.
Yes, I see. Actually if I understand it correctly it will only be used in file compilation; yet it could cause problems with "strange" forms like (setq foo (defun ...)) where foo will be set to the function object instead of the function name, only when loading the FASL, not when loading the source. I'll experiment a bit with this and if I'm right, I'll commit another fix.
With r13045 (http://trac.common-lisp.net/armedbear/changeset/13045) I committed the change to DEFUN in compiled files, so now it should return the function name in all cases. I verified this doesn't break any unit test in our suites. If you want, I can backport both this change and the previous one (13032) to the 0.23 branch.
armedbear-devel@common-lisp.net
-
Alessio Stalla -
Erik Huelsmann -
pjb＠informatimago.com