Given a variable that claims to name a type, is there a way to find out
that it really names a type?
I.e., can I do this: (typep foo 'type) ?
type is not defined as a type, so I cannot. Is there another way to get
the same effect?
Feel free to call me a fool, but first tell me which chapter of CLtL2 to
read. Yes, I read chapters 2 and 4, did I miss something?
ralph hill
Bellcore
In article <······················@walter.bellcore.com>, ···@thumper.bellcore.com (Ralph Hill) writes:
|> Given a variable that claims to name a type, is there a way to find out
|> that it really names a type?
No, because types are not first class objects, and therefore are not discriminable by the type discriminating functions ;-) Types are *named* by type specifiers, which are combinations of symbols and lists. [CLtL2, p 49]
On the other hand, if you have CLOS in your Lisp then you could use the function FIND-CLASS to determine the existence of any atomic type (i.e., class) except those defined vis DEFTYPE. Examples:
(defstruct GLORF)
(find-class 'glorf) => #<Structure-Class GLORF>
(deftype FROG ()
'symbol)
(find-class 'frog) => Error....
..................................................
Len Charest, Jr.
JPL Artificial Intelligence Group
·······@aig.jpl.nasa.gov
In article <······················@walter.bellcore.com> Ralph Hill <···@thumper.bellcore.com> writes:
>Given a variable that claims to name a type, is there a way to find out
>that it really names a type?
No, there isn't. X3J13 considered adding a TYPE-SPECIFIER-P function, but
we couldn't agree on its requirements. In particular, how much syntax and
validity checking would it have to do? Would (type-specifier-p '(integer
n)) return T (because it has the correct format for an INTEGER type
specifier) or NIL (because the argument to the INTEGER type specifier isn't
an integer or *)? Should (type-specifier-p '(satisfies foo)) check whether
FOO currently names a function?
It gets even harder when user-defined type specifiers are involved. If we
decide that TYPE-SPECIFIER-P must detect invalid type specifier arguments,
then there must be a way for it to determine this for types defined with
DEFTYPE, so it must catch errors that they signal. This then leads to
strange cases like this:
(deftype random-type ()
(if (zerop (random 2))
'integer
(error "No such type")))
(type-specifier-p 'random-type) would randomly return T or NIL. If the
intent were to do
(when (type-specifier-p foo)
(typep object foo))
in order to prevent errors from the TYPEP, it wouldn't work.
But if TYPE-SPECIFIER-P doesn't try to detect invalid arguments to type
specifiers then it isn't much use.
We eventually punted. If you're calling TYPEP or SUBTYPEP with a
caller-supplied type specifier and you're not sure whether it's valid, put
a condition handler around the call. This isn't guaranteed to work (for
some reason TYPEP is specified as having undefined consequences, rather
than signalling an error, if the type specifier argument isn't a type
specifier), but it will probably work in most implementations.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar