(FUNCTION MACRO-OR-SPECIAL-OPERATOR) at top-level doesn't throw an error.

[Jean-Philippe Paradis]

What I do and what happens:
#'multiple-value-bind ; Special operator
=> #<CLOSURE (LAMBDA (&REST SB-C::ARGS)) {9CA86C5}>

#'destructuring-bind ; Macro
#<CLOSURE (LAMBDA (&REST SB-C::ARGS)) {A09FF6D}>

(funcall #'destructuring-bind)
error -->
The function COMMON-LISP:DESTRUCTURING-BIND is undefined.
   [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-SOCKETS-ADDRINFO :ASDF2 :ASDF :ASDF-UNIX :ANSI-CL
 :COMMON-LISP :SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE
 :SB-EVAL :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :X86 :UNIX :ELF :LINUX
 :SB-THREAD :LARGEFILE :GENCGC :STACK-GROWS-DOWNWARD-NOT-UPWARD
 :C-STACK-IS-CONTROL-STACK :COMPARE-AND-SWAP-VOPS :UNWIND-TO-FRAME-AND-CALL-VOP
 :RAW-INSTANCE-INIT-VOPS :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-VECTORS
 :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-FIXED-OBJECTS :ALIEN-CALLBACKS
 :CYCLE-COUNTER :INLINE-CONSTANTS :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS
 :LINKAGE-TABLE :OS-PROVIDES-DLOPEN :OS-PROVIDES-DLADDR :OS-PROVIDES-PUTWC
 :OS-PROVIDES-SUSECONDS-T :OS-PROVIDES-GETPROTOBY-R :OS-PROVIDES-POLL)

[Nikodemus Siivola (nikodemus)]

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.

[Douglas Katzman (dougk)]

There could not possibly be a "good" reason for this other than a slight performance win.
sb-fasteval doesn't have this behavior.
sb-eval does, mainly out of laziness - it does not check for macro-function (signaling an error), and then fdefinition if not a macro.
The simple evaluator (if no full eval implementation is built in) also exhibits the misbehavior.

[Jean-Philippe Paradis (hexstream)]

Thanks for the fix! :)