Cleanup Issue SUBTYPEP-EMPTY-NIL
- Status
- For Internal Discussion
- Forum
- Cleanup
- Category
- CLARIFICATION
- References
- 2.15 Overlap, Inclusion, and Disjointness of Types (p33-35), SUBTYPEP (p72),
Problem Description
When a type description is restricted by range or enumeration, and the restricted type turns out to be empty, is the type a subtype of NIL?Test Cases
#1: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) => ??
#2: (SUBTYPEP '(MEMBER) NIL) => ??
Proposal (NIL-T)
Specify that empty ranges are not a subtype of NIL.
The test cases would then have to return either {NIL, T}, or {NIL, NIL}.
Rationale: The two types are different in intention.
Proposal (T-T)
Specify that empty ranges are a subtype of NIL.
The test cases would then have to return either {T, T}, or {NIL, NIL}.
Rationale: The two types are not distinguishable in practice.
Proposal (EXPLICITLY-VAGUE)
Explicitly acknowledge that the relationship between empty range or enumeration types and the type named NIL is unspecified.
The test cases could then return any of {T, T}, {NIL, T}, or {NIL, NIL}.
Rationale: This is a fall-back in case no agreement is reached.
Current Practice
For test case #1, Symbolics Genera 7.1 returns {NIL, T}.
For test case #2, Symbolics Genera 7.1 returns {NIL, T}.
Cost to Implementors
There is no cost to EXPLICITLY-VAGUE.
The cost to the other options for implementations which don't already conform is probably fairly small.
Cost to Users
Probably most users don't depend on this. Those users who do depend on it, can't rely on it in portable code because the spec is too vague.Cost of Non-Adoption
Unnecesary ambiguity.Benefits
Users will know what to expect.Aesthetics
No aesthetic impact yet identified.Discussion
Pitman mildly supports NIL-T. Steele mildly supports T-T. Probably the answer is not as important as making sure implementations agree and that users know what to expect.Edit History
- 07-Feb-89, Version 1 by Pitman