Bad thing to be a type specifier: number
Bug #1851437 reported by
Vinced
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
New
|
Undecided
|
Unassigned |
Bug Description
I wanted to use NUMBER as a type specifier with DECLAIM like this, as I do with float:
(defparameter *foo* 0)
(declaim (type (number) *FOO*))
but this throws:
bad thing to be a type specifier: (NUMBER)
[Condition of type SIMPLE-ERROR]
We must use
(declaim (type number *FOO*))
According to R. Joswig on this SO answer, (NUMBER) would be a valid type specifier and some implementations accept it.
https:/
Is it missing, or is there a reason for this?
Regards
SBCL 1.4.5.debian
Linux 4.15.0-65-generic #74-Ubuntu SMP Tue Sep 17 17:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
To post a comment you must log in.
By analogy with (REAL) and (FLOAT), you might think (NUMBER) should work, but it can't take bounds as parameters, so it's not at all.
CLHS make an implication in the opposite direction: _if_ a specifier can be a list, then the form which is just an atom must work and is equivalent to the list with no optional parameters.
But we should not support this.
CCL agrees that it's an error:
? (typep 3 '(number))
> Error: Invalid type specifier: (NUMBER)
CLISP agrees that it's an error:
[1]> (typep 3 '(number))
*** - TYPEP: invalid type specification (NUMBER)
ECL agrees that it's an error:
> (typep 3 '(number))
Condition of type: SIMPLE-ERROR
(NUMBER) is not a valid type specifier.
So it's an error.