Issue: TYPE-OF-UNDERCONSTRAINED (Version 1)

[masinter.pa@Xerox.COM]

I never wrote this up, even though it seems to be required in some of the
COERCE discussions.

Should TYPE-OF be required to be more specific on condition subtypes?

!
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
			

Category:      CLARIFICATION/CHANGE

Edit history:  Version 1,  1-Dec-88, Masinter

Problem description:

The specification of TYPE-OF in CLtL is so weak as to leave it useless for
portable applications, outside of structures. In particular, there are 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 must be at least as specific as follows:

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, 
CONS, 
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME

CONDITION, RESTART.

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 recognized subtype of it.

The result of TYPE-OF must satisfy 
(TYPEP object (TYPE-OF object)).

The result of TYPE-OF must be an acceptable input to SUBTYPEP.

The result of TYPE-OF cannot contain be a MEMBER type specifier, or T.

For objects which are instances of anonymous classes (i.e., where
(CLASS-NAME (CLASS-OF object)) is NIL), the result of TYPE-OF should be 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.)

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).

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:

Inability to use TYPE-OF in portable code except for information display.

Performance impact:

Likely none.

Benefits:

Removal of "cost of non-adoption".

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.


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