SUBTYPEP-TOO-VAGUE (initial draft)

[sandra%cdr@cs.utah.edu (Sandra J Loosemore)]

Issue:		SUBTYPEP-TOO-VAGUE
References:	CLtL p. 72-73
Category:	CLARIFICATION
Edit History:   Version 1, 11 Jul 1988 (Sandra Loosemore)


Problem Description:

The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined.  In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier). 

Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship.  This makes it difficult to depend on
subtype relationships in portable code.


Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY

(1) Clarify that SUBTYPEP is allowed to return a second value of NIL
only when either of the type specifiers involves the SATISFIES, NOT,
AND, OR, the list form of FUNCTION, or VALUES type specifiers.

(2) If a type specifier defined with DEFTYPE is passed to SUBTYPEP,
SUBTYPEP must treat it in the same way as if its expansion were passed
instead.

(3) Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation.  For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).


Rationale:

It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
AND, OR, and NOT are messy to deal with. (MEMBER falls into the same
section but is easy to do).  I don't know how one would compare
FUNCTION or VALUES type specifiers; some rules could be established to
clarify how to compare them but I don't think it would would be
particularly useful to do so. 


Current Practice:

The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE.  Most other implementations
appear to be substantially in conformance with the proposal.


Cost to implementors:

Some implementations will have to rewrite and/or extend parts of SUBTYPEP.


Cost to users:

None.


Benefits:

An area of confusion in the language is cleared up.  Usages of SUBTYPEP
will be more portable.


Discussion:

Item (3) appeared to be the consensus from a discussion on the
common-lisp mailing list some time ago.

A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE.  For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE.  Should this proposal be
extended to deal with these issues, or is another proposal in order?

Do the rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail, or are they obvious?
-------