Bad thing to be a type specifier: number

[Vinced]

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://stackoverflow.com/questions/58715076/bad-thing-to-be-a-type-specifier-number

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

[Douglas Katzman (dougk)]

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.

[Vinced (vincezd)]

and I understand better, thanks.

[Rainer Joswig (joswig-k)]

The ANSI standard disagrees:

http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_a.htm#atomic_type_specifier

"atomic type specifier n. a type specifier that is atomic. For every atomic type specifier, x, there is an equivalent compound type specifier with no arguments supplied, (x)."

Note that the Glossary is a normative part of the ANSI CL standard.

[da_vin_ci (da-vin-cii)]

@joswig-k
Can you elaborate on "The ANSI standard disagrees" ?

Do you mean by this, that being equivalent they are interchangeable ?
I'm really not an expert on this kind of issues, but isn't the standard also a reference of how to write a compliant interpreter/compiler in addition to what forms are valid ones (how to write in that language).

Because as I understand that interpretation of these 2 forms
number
(number)
have the same value equivalence, they don't have the same form equivalence (they are not written/encoded the same way)
the first one is atomic (),
the second one is (i guess) equivalent in form (but not in syntax) to
(list number) or
(cons number nil) which at the end of the day is still a cons and then not atomic
http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_a.htm#atomic
http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_a.htm#atom

That would imply (for what I understand) that an interpreter which specifically doesn't do evaluation on an atomic type specifier, and by consequence which would not understand the form (number) at a place where it's waiting for an "atomic type specifier", would still be conform to the language specifications. While the interpreter that would understand the form (number) would do a very tiny bit more interpreting work than what is legally the bare minimum required by the standard.

So to conclude:
as to program code writing specifications, I do agree with @joswig-k, but
as to interpreter writing specifications, I don't.
And as I assume the ANSI standard is the same and only standard for both occupations (write "ANSI standard CL" program code and write "ANSI standard CL" interpreters), the only way to have all "ANSI standard" codes be rightfully interpreted by all "ANSI standard" interpreters would be to cover the intersection of both area https://en.wikipedia.org/wiki/Intersection_(set_theory) and that it's then not a SBCL bug.

Quod erat demonstrandum
...or is there some biased reasoning in my views on logic or my axioms.
(I assure you i'm not a troll ^^ but just a lisp beginner trying to understand the ins and outs of this logical chaos that is the Lisp world)

[Douglas Katzman (dougk)]

Pontificating aside, it's unportable to rely on such ill-specified behavior:

--- Clozure
? (typep 3 '(number))
> Error: Invalid type specifier: (NUMBER) .
> While executing: CCL::VALUES-SPECIFIER-TYPE, in process listener(1).

-- ECL
ECL (Embeddable Common-Lisp) 16.1.3 (git:UNKNOWN)
> (typep 3 '(number))
Condition of type: SIMPLE-ERROR
(NUMBER) is not a valid type specifier.

-- CLISP
Welcome to GNU CLISP 2.49.92 (2018-02-18) <http://clisp.org/>
[1]> (typep 3 '(number))
*** - TYPEP: invalid type specification (NUMBER)

-- CMUCL
CMU Common Lisp 20d (20D Unicode), running on dougk.cam.corp.google.com
* (typep 3 '(number))
Error in function LISP::%%TYPEP: Unknown type specifier: (NUMBER)

[da_vin_ci (da-vin-cii)]

After my last comment, thinking about it while reading http://clhs.lisp.se/Body/m_declai.htm agin
- it refers to "declaration-specifier"
   http://clhs.lisp.se/Body/26_glo_d.htm#declaration_specifier
- which refers to "declaration identifier" and tells the cdr data is according to rules of each specific declaration identifier http://clhs.lisp.se/Body/26_glo_d.htm#declaration_specifier

- so "type" is the declaration identifier
   http://clhs.lisp.se/Body/d_type.htm#type
- which leads us to :
type specifier n. an expression that denotes a type.

nowhere there is any mention that it has to be an "atomic type specifier"
So I now understand @joswig-k and that it is a SBCL bug.

@dougk : sure, that's the practical thing to do when writing code, but the question is still interesting enough to be analyzed and understood.