copy-symbol with copy-properties=T fails on macros

Bug #1951915 reported by Douglas Katzman
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
New
Undecided
Unassigned

Bug Description

Unclear whether this is legal:
* (copy-symbol 'and 't)
debugger invoked on a SB-INT:SIMPLE-REFERENCE-ERROR in thread
#<THREAD "main thread" RUNNING {10022FC103}>:
  #<FUNCTION (:MACRO AND) {10008AD7BB}> is not acceptable to (SETF SYMBOL-FUNCTION).
See also:
  The ANSI Standard, Function FDEFINITION

This is allowed in a bunch of other lisp implementations.
----

CLHS says:
"If copy-properties is true, then the initial value of new-symbol is the value of symbol, the initial function definition of new-symbol is the functional value of symbol ..."

"functional value n. 1. (of a function name N in an environment E) The value of the binding named N in the function namespace for environment E; that is, the contents of the function cell named N in environment E. 2. (of an fbound symbol S) the contents of the symbol's function cell; that is, the value of the binding named S in the function namespace of the global environment. (A name that is a macro name in the global environment or is a special operator might or might not be fbound. But if S is such a name and is fbound, the specific nature of its functional value is implementation-dependent; in particular, it might or might not be a function.)"

incidentally, the "might or might not be fbound" certainly seems to suggest that FBOUNDP is allowed to return NIL on macros and special operators, which I guess I had forgotten.
Since that's the case, I think we should stop installing "guard" functions on non-functions. Just one extra check in SYMBOL-FUNCTION to have it return something for those would be fine.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.