[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: SUBTYPEP-EMPTY-NIL (Version 1)
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Issue: SUBTYPEP-EMPTY-NIL (Version 1)
- From: Rob.MacLachlan@WB1.CS.CMU.EDU
- Date: Wed, 08 Feb 89 13:07:42 EST
- Cc: email@example.com, CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: Your message of Wed, 08 Feb 89 09:37:00 -0500. <890208093740.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
The NIL T proposal isn't adequate as currently presented. If an empty
numeric range or member type isn't equivalent to NIL, what is it equivalent
to. Is (integer (0) (0)) == (float (0.0) (0.0))? Is an empty member type
equivalent to an empty numeric type?
If these types are placed somewhere in the hierarchy other than at the
bottom, then we must say where. Presumably each of these new empty types
is a lower bound on some existing collection of types, and we need to say
I am personally in favor of making all of these types == NIL, since it
seems simpler. This seems also to be more compatible with the "types
are sets" view stated in CLtL. All type specifiers that designate the
empty set should be equivalent.
I think that your example is pretty contrived. Regardless of the type
system, the compiler can't do much with type specifiers that are
constructed at load time. The right way to do this would be with a
DEFTYPE, which could be expanded at compile time.