Issue SUBTYPEP-TOO-VAGUE

[Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>]

> I don't see any problem here.  My compiler has a type testing function
> that handles VALUES types itself and converts (FUNCTION ...) to just
> FUNCTION before calling SUBTYPEP, so it isn't prevented from doing anything
> that it wants.

And what does it do with a deftype'ed type which expands into a list form
FUNCTION type specifier or into a VALUES type specifier?  Did you remember to
call type-expand before doing the conversion?  Note that a user wouldn't be
able to do that, since type-expand isn't part of the language.  And what about
an OR of several FUNCTION or VALUES type specifiers?  Besides, it's wrong to
have to define the handling of the VALUES type yourself, even ignoring these
problems, since you end up with each user who wants this capability having to
write his own, rather than having the facility built into SUBTYPEP where it
belongs.

> If you want these cases to be permitted, then you will need to define what
> they mean.

Thats an ugly job.  One of us was working on it, but hasn't had much time to
devote to the problem -- probably nobody here at IIM will be able to get to
it any time soon.  Right now we mostly just don't want these to be required
signal error cases, with the intention of fully specifying them later.
(Note: some of the ugliness involves questions about what to do when the
typed lambda-lists aren't congruent (in the CLOS sense)).

kab
-------