[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exact type

     Date: Mon, 28 Sep 87 13:54:27 MST
     From: kempf%hplabsz@hplabs.hp.com
     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
     be inappropriate.

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.