[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Exact type
- To: email@example.com
- Subject: Re: Exact type
- From: Patrick H Dussud <DUSSUD%Jenner%csl.ti.com@RELAY.CS.NET>
- Date: Tue, 29 Sep 87 13:45:27 CDT
- Cc: common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: Msg of Mon, 28 Sep 87 13:54:27 MST from firstname.lastname@example.org
Date: Mon, 28 Sep 87 13:54:27 MST
Subject: Re: Exact type
>But allowing the other COMMON subtypes would makes programs non portable:
>The list of subtypes of a type is implementation dependent. We say (page
>1-14) that individual implementation can add additional subclass
>relationships as long as they don't violate CLtL.
But the subtype relationships in CLtL must still hold. Thus, any
importabilities will be the result of importabilites in the Common
Lisp type system, not in the CLOS addition. Reading the rules on
pg. 33-35, it's difficult to discern importabilities, but, talking
to Gregor (who has some experience in this area), they do exist.
However, I think the place to address the problem is to tighten up
the Common Lisp type system, not restrict EXACT-TYPE.
I don't think it's a problem with the CLtL type system. Implementations
can always specialize a built-in type without breaking the portability
of program relying on TYPEP and SUBTYPEP. However it can break the
portability of code relying on EXACT-TYPE. The user shouldn't expect
that an argument will be exactly of this built-in type. On some
machines, you cannot expect an cons cell argument to be always of the
exact type CONS.
While I don't particularly agree with this policy, I think that it gives
implementations so much latitude already that restricting EXACT-TYPE would
My way of restricting EXACT-TYPE would prevent the user from expecting
things he cannot always get.
I still think EXACT-TYPE makes sense for user defined type though.