Christophe Rhodes <email@example.com> wrote:
| firstname.lastname@example.org (Rob Warnock) writes:
| > Not quite -- it says:
| > Exceptional Situations: None.
| > To me, that suggests "never throws an exception".
| Really? There are an awful lot of functions described in the CLHS as
| having no /specified/ Exceptional Situations, which is what I take
| that to mean.
Looking through the description I saw nothing that could provoke an
If type-1 is a recognizable subtype of type-2, the first value
is true. Otherwise, the first value is false...
Are you suggesting that determining "a recognizable subtype" could
have some value other than "true" or "false"?
Hmmm... I think spoke too soon!! (Oops!) If one of the args isn't in
(OR CONS CLASS SYMBOL), both CMUCL & CLISP error out. And indeed, CLHS
188.8.131.52 "The ``Arguments and Values'' Section of a Dictionary Entry" says:
Except as explicitly specified otherwise, the consequences
are undefined if these type restrictions are violated.
And the args of SUBTYPEP are definitely described as "type specifiers",
so if they do not name a defined type (defined either by the language
or by the programmer), then "the consequences are undefined", and
*anything* could happen.
| > In particular, given the definition of SUBTYPEP, I should think
| > that this should be fairly reliable:
| > (defun valid-subtype-spec-p (x)
| > (multiple-value-bind (subtype-p valid-p)
| > (subtypep x t)
| > (and subtype-p valid-p)))
| Since T is the universal supertype, I think an implementation would be
| perfectly justified in always returning T, T for (subtypep x t), for X
| being of type (OR CONS SYMBOL).
Yeah, good point [except it should be (OR CONS SYMBOL CLASS)]. And indeed,
when presented with these forms:
(valid-subtype-spec-p '(some weird form))
CMUCL returns NIL for both while CLISP returns T for both.
O.k., I screwed up. I'll crawl back into my hole now...
Rob Warnock, PP-ASEL-IA <email@example.com>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607