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
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  Edit
Everyone can see this information.

Other bug subscribers