SUBTYPEP-TOO-VAGUE, version 2

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

I am mostly in favor of SUBTYPEP-TOO-VAGUE:CLARIFY, but have a few
suggestions:

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

VALUES and the list form of FUNCTION are not valid arguments to SUBTYPEP
(p.72 says the arguments to SUBTYPEP have to be valid for TYPEP, p.47 says
the list form of FUNCTION is invalid for TYPEP, p.48 says VALUES isn't
really a type-specifer [sic] at all).  So you can strike those two from
the list.

I'm a little unhappy about excluding MEMBER.  I think you should exclude
MEMBER only when it's the second argument and the first argument is not
MEMBER.  MEMBER as the first argument is a useful and easy to compute
case: it's just the conjunction of a bunch of calls to TYPEP.

I think if an implementation defines a new type with a name not in CLtL,
the implementation should be permitted to add that type to the list of
types that SUBTYPEP doesn't understand.

The behavior of SUBTYPEP on types defined by DEFSTRUCT and DEFCLASS
should be fully specified.  Require it to be the obvious behavior.

    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?

I think it's likely to be complex enough that it needs to be another
proposal.  Perhaps acceptance of this proposal will make that one easier
to write, since you can define the behavior in terms of SUBTYPEP.

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

The former.  Fortunately the only difficult cases are COMPLEX, ARRAY and
its subtypes, and numerical ranges.  Just to make matters worse, I
believe there is a proposal on the table to change the ARRAY rules.  I
forget the issue name.

If you don't think numerical ranges are non-obvious, what is

  (subtypep '(single-float 0.0 (1.0))
	    `(single-float 0.0 ,(- 1.0 single-float-epsilon)))

SCL returns NIL T, which is wrong since these two type specifiers
denote identical finite sets.  Once you think you know the answer to that,
translate the example into rationals, replacing (- 1.0 single-float-epsilon)
with a rational that is so close to 1 that any rational that was
closer could not be represented in the implementation because you
would run out of memory!  I think the answer to that is that for floats
there is a concept of the next value, and hence a translation from
exclusive to inclusive ranges, but for non-integer rationals there is not.
I can't predict the mathematical implications of this, though.