[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Don Cohen <email@example.com>
- Subject: commonlisp types
- From: Barry Margolin <barmar@Think.COM>
- Date: Thu, 1 Dec 88 11:04 EST
- Cc: firstname.lastname@example.org
- In-reply-to: <8812010255.AA17146@vaxa.isi.edu>
Date: Wed, 30 Nov 88 18:55:38 PST
From: Don Cohen <email@example.com>
There seems to be nothing in CLtL that answers the question:
"is x a legal type specifier?"
The description of TypeP says that the type argument may be
any of the legal type specifiers except (function ...) or
I would hope that would mean that for any such "legal
arguments" typep would not cause an error. I would also
hope that any illegal type would cause an error.
On the other hand the description of how typep handles
(satisfies ...) indicates that errors might well result.
Intuitively, it seems to me that if an error results from
that test the typep test ought to return nil, e.g.,
(typep nil '(satisfies zerop))
I'd like the spec to say that typep first decides whether
the type is legal, and signals an error if not. Then,
for things like satisfies, it applies the predicate but
catches errors, and returns nil if an error occurs.
What do you experts (and lawyers) out there think?
Since CLtL doesn't say that TYPEP must signal an error if the type
specifier is invalid, it currently "is an error" if the type specifier
is not a valid type specifer other than (FUNCTION ...) or (VALUES ...).
I don't think there has been any suggestion within X3J13 to change this.
In general, Common Lisp tends not to require implementations to do lots
of this kind of checking; at high safety optimization levels it is
informally encouraged, but not required.
Actually, in this particular case, I don't think that requiring an error
to be signalled would be too bad. TYPEP must already do a significant
amount of work to decode the type specifier, so it probably knows when
the type specifier is invalid, and signalling an error would be pretty
easy. However, putting this requirement into the CL standard would be
an incompatible change to the language definition, with only minor gain,
and I think it is kind of late for it now (we're not very far from
trying to get a draft finished).
As for your suggestion about (SATISFIES ...), I personally think that is
a bad idea. TYPEP shouldn't silently hide bugs in the programmer's
predicate. The above example should have been written as
(typep nil '(and number (satisfies zerop)))