SET-DISPATCH-MACRO-CHARACTER and SET-MACRO-CHARACTER coerce a SYMBOL to a FUNCTION too early
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
What I do and what happens (SET-DISPATCH-
(let ((rt (copy-readtable nil nil)))
(make-
(set-
rt)
LAZY-FUNCTION isn't fbound.
[Condition of type SIMPLE-TYPE-ERROR]
Backtrace:
0: (COERCE LAZY-FUNCTION FUNCTION)
1: (SET-DISPATCH-
[...]
What I do and what happens (SET-MACRO-
(let ((rt (copy-readtable nil nil)))
(set-
rt)
The function COMMON-
[Condition of type UNDEFINED-FUNCTION]
Backtrace:
0: (SB-KERNEL:
1: (SET-MACRO-
[...]
What I expected in both cases:
Usual funcall-time symbol-to-function resolution semantics.
Analysis:
It's fairly well-established practice that storing a symbol as a function designator in some data structure results in "lazy" resolution of the symbol to a function. This is especially useful for interactive development, as function redefinitions will get picked up without needing to redeclare the macro-character. I understand that this early coercion might have been done for performance concerns, but most users already pass a function, and it's easy for the user to coerce any symbol to a function themselves if that's what they want, as they already need to do for almost every other data structure. There might be performance gains from readtable functions being able to assume that GET-DISPATCH-
I found no hint in CLHS SET-DISPATCH-
SBCL version: 1.0.56
uname -a: Linux dynamorph 3.2.0-24-
*features*:
(:SWANK :QUICKLISP :SB-BSD-
:SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-EVAL
:SB-SOURCE-
:OS-PROVIDES-
:OS-PROVIDES-
:MULTIPLY-
:ALIEN-CALLBACKS :STACK-
:STACK-
:UNWIND-
:STACK-
:LINUX :ELF :UNIX :X86)
Changed in sbcl: | |
status: | Fix Committed → Fix Released |
In fa0c056d6e2e9ee f1c07cae0b3b814 099866bedb by Douglas.