[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
- To: cl-cleanup@sail.stanford.edu
- Subject: Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 12 Dec 88 20:48 EST
- In-reply-to: <881212-160109-5511@Xerox>
[X3J13 removed]
I approve this, but there are some obvious mistakes:
Why is RANDOM-STATE missing from the list of built-in types? Probably others
are missing as well, I did not check the list carefully.
(SUBTYPEP (TYPE-OF x) (CLASS-OF x)) => T T for all x, seems to
have been intended but is not actually said. I think this should
be added to the proposal section.
The first three points in the proposal section are identified with
letters, but the last three points are not.
Re the discussion section:
The comment about the relation of CLASS-OF and TYPE-OF, while it may be
true, only indicates confusion in an earlier CLOS spec and detracts from
understanding the point of this proposal.
If you want "to eliminate the possibility that TYPE-OF might return a
non-portable implementation-specific value" you will have to define
the concept of portable objects versus implementation-dependent objects,
since obviously an implementation that has an entirely new kind of
object cannot return a portable type-specifier for that object. Also what
about implementations that have implementation-dependent subtypes of
built-in types, especially if those subtypes are defined with DEFSTRUCT
or DEFCLASS -- the spec simultaneously requires TYPE-OF to return the
class name or structure name, and to return a portable value distinct
from the class or structure name. For a concrete example, Genera has an
implementation-dependent subtype of PATHNAME for each type of file
system supported, and TYPE-OF returns the class name. I think the
proposed implementation recommendation cannot be portably specified
and hence should be discarded.