SPECIAL-OPERATOR-P should return true only for the 25 standard special operators
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Invalid
|
Undecided
|
Unassigned |
Bug Description
What I do:
(let ((cl-package (find-package '#:cl))
cl
others)
(do-all-symbols (symbol
(when (special-operator-p symbol)
(if (eq (symbol-package symbol) cl-package)
(push symbol cl)
(push symbol others)))))
What happens:
Output:
---OTHERS---
SB-C::%
SB-C::%CLEANUP-FUN
SB-C::%ESCAPE-FUN
SB-C::%FUNCALL
SB-SYS:%PRIMITIVE
SB-C::%
SB-CLTL2:
SB-C::GLOBAL-
SB-EXT:TRULY-THE
9
---CL---
BLOCK
CATCH
EVAL-WHEN
FLET
FUNCTION
GO
IF
LABELS
LET
LET*
LOAD-TIME-VALUE
LOCALLY
MACROLET
MULTIPLE-VALUE-CALL
MULTIPLE-
PROGN
PROGV
QUOTE
RETURN-FROM
SETQ
SYMBOL-MACROLET
TAGBODY
THE
THROW
UNWIND-PROTECT
25
What I expected to happen:
SPECIAL-OPERATOR-P should only return true for the 25 standard special operators.
Analysis:
From CLHS SPECIAL-OPERATOR-P:
"Returns true if symbol is a special operator; otherwise, returns false."
From the glossary entry for "special operator":
"one of a fixed set of symbols, enumerated in Figure 3-2, that may appear in the car of a form in order to identify the form as a special form."
I'm aware that special forms can be implemented as macros and vice-versa, nevertheless SPECIAL-OPERATOR-P should return true only for the 25 standard ones. This behavior also makes much more sense for code walkers than the current one. Portable code-walkers do need to treat the 25 special operators specially, while they can completely ignore any extraneous implementation-
SBCL version: 1.0.42
uname -a: Linux dynamorph 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:21 UTC 2011 i686 GNU/Linux
*features*:
(:SWANK :QUICKLISP :SB-BSD-
:SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-EVAL
:SB-SOURCE-
:LARGEFILE :GENCGC :STACK-
:COMPARE-
:STACK-
:STACK-
:CYCLE-COUNTER :INLINE-CONSTANTS :MEMORY-
:OS-PROVIDES-
All these are defined by DEF-IR1-TRANSLATOR macro, which marks them as special operators. Can we redefine these nine operators in some other way? This is an interesting question.