Bad thing to be a type specifier: number

Bug #1851437 reported by Vinced on 2019-11-05
This bug affects 1 person
Affects Status Importance Assigned to Milestone

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.

Is it missing, or is there a reason for this?


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) wrote :

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) wrote :

and I understand better, thanks.

Rainer Joswig (joswig-k) wrote :

The ANSI standard disagrees:

"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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers