Issue: TYPE-OF-UNDERCONSTRAINED, v.5

[masinter.pa@Xerox.COM]

I think Guy missed a couple of the amendments that passed
at the last meeting. This is what I started to send out
to X3J13, but since I've tried to "patch" the wording a bit
since it seems that some of the constraints put on TYPE-OF
by this proposal are overlapping, I thought I would send
it to cl-cleanup first. (Since this was raised at the last
meeting, there's not a problem about the 'two-week' rule,
I think.)


Version 3 of this proposal was raised at the January 1989
X3J13, and passed with three amendments:

a) add RANDOM-STATE to the list of types
b) add the requirement that TYPE-OF is a subtype of CLASS-OF
c) change the relation to CLOS to say
 "for all objects
  for which CLASS-OF returns a class with a proper name, TYPE-OF returns
  that proper name."

It was noted that SHORT-FLOAT, LONG-FLOAT and RATIONAL were 
omitted inadvertently. We would like to ask that the proposal
be reconsidered so that these types could also be included.
This version includes those amendments, and also
adds SHORT-FLOAT, LONG-FLOAT, and RATIONAL
to the list of types in part (a) of the proposal.



!
Forum:	Cleanup
Issue:      TYPE-OF-UNDERCONSTRAINED

References: TYPE-OF (CLtL)
            88-002R (Class-of)
            88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
                DATA-TYPE-HIERARCHY-UNDERSPECIFIED
                FUNCTION-TYPE
                ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
                COERCE-INCOMPLETE
			

Category:       CLARIFICATION/CHANGE

Edit history:   Version 1,  1-Dec-88, Masinter
		    Version 2,  9-Dec-88, Masinter
		    Version 3, 12-Dec-88, Masinter (fix "egregious bug")
		Version 4, 3-14-89 Steele
		Version 5, 16-Mar-89, Masinter (add other amendments)

Problem description:

The specification of TYPE-OF in CLtL is so weak as to leave it 
nearly useless, if any implementor actually took the specification
seriously.In particular, there are almost no constraints on the
value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.

This means that implementations could return T for all other objects.

Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS): 

Specify that the result of TYPE-OF satisfies the following:

(a) For any object for which (typep object built-in-type) is true when
built-in-type is one of 

INTEGER, RATIO, FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, COMPLEX, NUMBER,
SYMBOL, 
STRING, VECTOR, ARRAY, RANDOM-STATE,
CONS, 
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
CONDITION, RESTART,
RATIONAL, SHORT-FLOAT, LONG-FLOAT

the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a subtype of it (a subtype that the 
implementation's SUBTYPEP can recognize.)

(b)  For all objects, (TYPEP object (TYPE-OF object)) will be true.
(this implies that it will not be NIL, since no
object is of type NIL.)

(c) will not be a MEMBER type specifier, or T.

The type returned by TYPE-OF is always a subtype of the class
returned by CLASS-OF.

For all objects for which CLASS-OF returns a class with a proper name,
TYPE-OF returns that proper name.

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.

For all objects for which (CLASS-NAME (CLASS-OF object)) is NIL),
the result of TYPE-OF will return the class object itself.

(The CLOS specification has already specified that class objects are
acceptable wherever type specifiers are, and in particular, as input to
SUBTYPEP and TYPEP.)

This proposal is intended to be consistent with 88-002R, 
and not to conflict with any of the definitions in that document.

Examples:

It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).

 Given:

   (defvar *foo* (make-array 5 :element-type t))
   (class-name (class-of *foo*))  =>  SIMPLE-VECTOR
  It is legal for
   (type-of *foo*)                =>  (SIMPLE-VECTOR 5)


Rationale:

The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended. 

Current practice:

Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.

Cost to Implementors:

Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal. 

Cost to Users:

Apparently none.

Cost of non-adoption:

TYPE-OF would remain potentially inconsistent.

Performance impact:

Likely none.

Benefits:

Bring the specification of TYPE-OF in like with its common
implementation, while requiring it to be generally useful.

Esthetics:

Little effect.

Discussion:

Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.

The accepted CLOS specification does not define CLASS-OF
in terms of TYPE-OF, but an earlier draft did. 

This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.

If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass, 
and this proposal does pass, it may be that the only way an 
implementation can satisfy (TYPEP array (TYPE-OF array))
would be to have (TYPE-OF array) return VECTOR or ARRAY
as appropriate, i.e., with no element type qualification.

It is possible to constrain TYPE-OF further, e.g., to eliminate
the possibility that it might return a non-portable 
implementation-specific value. For example, 
(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]

We would like to make this as an implementation recommendation,
however, rather than as a constraint, at this point.



     ----- End Forwarded Messages -----