Issue: TYPE-OF-UNDERCONSTRAINED, v.5

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

This version looks okay as far as making the amendments goes, but
in reading it over I noticed some problems that are really with
the original proposal.  If we have to go over this issue again,
I think we should consider fixing these problems too.

(1) Why are the following types omitted from part (a), the list
of types for which TYPE-OF must be specific:
  BIT-VECTOR NULL SEQUENCE

I constructed this list from 88-002R pp.1-16 and 1-17, and from the
specifications of which types are exhaustive partitions, I didn't
make it up randomly.

(2) Why are the following types omitted from part (a), the list
of types for which TYPE-OF must be specific:
  BIGNUM FIXNUM KEYWORD STANDARD-CHAR STRING-CHAR
  (replace STRING-CHAR with BASE-CHARACTER if that proposal passes)

Unlike the first list, I constructed this one randomly out of my head.
It's all the standard "interesting" subtypes of the types that are
already listed in part (a), excluding the simple array subtypes.

(3) The statement "For all objects for which CLASS-OF returns a class
with a proper name, TYPE-OF returns that proper name." is questionable.
For example, part (a) requires that TYPE-OF a single-float must return
SINGLE-FLOAT or a subtype of it, but 88-002R requires that CLASS-OF a
single-float be a class whose proper name is FLOAT, or an implementation
dependent subclass of that class.  This proposal will force
implementations to create such subclasses, which should be done on its
own merits, not through the back door.  Another example is that for
arrays, TYPE-OF will not be able to return a list that encodes the
element-type and dimensions, unless there are implementation dependent
classes corresponding to every such type specifier.  There is a really
baroque way to get around this, which is to define an implementation
dependent subclass of ARRAY that has a non-null name that is not its
proper name; this slips through a loophole in the proposal and allows
TYPE-OF to return any subtype of ARRAY.  I claim that loophole is a
bug too.

To fix these bugs, I suggest removing the four paragraphs that contain
the three references to CLASS-OF, and replacing them with:

(d) The type returned by TYPE-OF is always a subtype of the class
returned by CLASS-OF, and is a subtype that the implementation's
SUBTYPEP can recognize.

(e) For objects of metaclass STRUCTURE-CLASS or STANDARD-CLASS,
TYPE-OF returns the proper name of the class returned by CLASS-OF
if it has a proper name, and otherwise returns the class itself.

In particular, for objects created by the "constructor" function
of a structure defined with DEFSTRUCT without a :TYPE option,
TYPE-OF will return the structure name.

(4) I suggest modifying part (c) to exclude SATISFIES, AND, OR,
NOT, and VALUES in addition to MEMBER and T.  Of course part (c)
is a very weak restriction, since TYPE-OF is perfectly free to
return a symbol that is DEFTYPEd to one of these type specifiers,
as long as the other requirements are met.