(FUNCTION MACRO-OR-SPECIAL-OPERATOR) at top-level doesn't throw an error.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Fix Released
|
Low
|
Unassigned |
Bug Description
What I do and what happens:
#'multiple-
=> #<CLOSURE (LAMBDA (&REST SB-C::ARGS)) {9CA86C5}>
#'destructuring
#<CLOSURE (LAMBDA (&REST SB-C::ARGS)) {A09FF6D}>
(funcall #'destructuring
error -->
The function COMMON-
[Condition of type UNDEFINED-FUNCTION]
What I expected to happen:
I expected a compile-time ERROR.
Analysis:
First of all the current behavior is indeed conforming, as CLHS FUNCTION (special operator) states:
"It is an error to use function on a function name that does not denote a function in the lexical environment in which the function form appears. Specifically, it is an error to use function on a symbol that denotes a macro or special form. An implementation may choose not to signal this error for performance reasons, but implementations are forbidden from defining the failure to signal an error as a useful behavior."
However I think it would be better to report this error at compile-time, as we don't want someone to try #'macro in the REPL and come to the conclusion that this is a valid way to get at the macro definition. In fact, here's a very similar situation that does report a compile-time ERROR:
(macrolet ((foo ()))
#'foo)
error -->
Compile-time error:
found macro name FOO as the argument to FUNCTION
SBCL version: 1.0.51
uname -a: Linux dynamorph 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:08:37 UTC 2011 i686 GNU/Linux
*features*:
(:SWANK :QUICKLISP :SB-BSD-
:COMMON-LISP :SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE
:SB-EVAL :SB-SOURCE-
:SB-THREAD :LARGEFILE :GENCGC :STACK-
:C-STACK-
:RAW-INSTANCE-
:STACK-
:CYCLE-COUNTER :INLINE-CONSTANTS :MEMORY-
:LINKAGE-TABLE :OS-PROVIDES-DLOPEN :OS-PROVIDES-DLADDR :OS-PROVIDES-PUTWC
:OS-PROVIDES-
Changed in sbcl: | |
status: | Triaged → Fix Released |
Though I'm marking this as triaged, I'm not sure if this should be WONTFIX instead. IIRC there is a good reason why we do things this way, but I can't remember it offhand right now.