[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Exact type
- To: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
- Subject: Re: Exact type
- From: kempf%hplabsz@hplabs.HP.COM
- Date: Mon, 28 Sep 87 13:54:27 MST
- Cc: firstname.lastname@example.org
- In-reply-to: Your message of Tue, 22 Sep 87 11:25:11 -0500. <2768315111-8803361@Jenner>
>x is of exact-type X if it verifies:
>Let Y be a type such as (SUBTYPEP X Y) is true,
>then (TYPEP x Y ) is false.
Yes, except I think what you want the compiler to verify is
"If for all such Y, (TYPEP x Y) is false, then x is of EXACT-TYPE X".
>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.
In addition, declarations in Common Lisp have a certain flavor of
implementation dependency to them anyway, as this quote from CLtL,
pg. 153 should indicate:
With one exception, declarations are completely optional
and correct declarations do not affect the meaning of a
correct program. The exception is that SPECIAL declarations
_do_ affect the interpretation of variable bindings and
references, and so _must_ be specified where appropriate. All
other declarations are of an advisory nature, and may be
used by the LISP system to aid the programmer by performing
extra error checking or producing efficient compiled code.
Note that it is considered an error for a program to violate
a declaration (such as a TYPE declaration), but an implementation
is not required to detect such errors (though such detection,
where feasible, is to be encouraged).
While I don't particularly agree with this policy, I think that it gives
implementations so much latitude already that restricting EXACT-TYPE would
However, if anyone else feels strongly about this, or has a good counter-
argument, I'd be willing to change the specification.
- Exact type
- From: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>