Issue: SUBTYPEP-EMPTY-NIL (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

Issue:        SUBTYPEP-EMPTY-NIL
Forum:	      Cleanup
References:   2.15 Overlap, Inclusion, and Disjointness of Types (p33-35),
	      SUBTYPEP (p72), 
Category:     CLARIFICATION
Edit history: 07-Feb-89, Version 1 by Pitman
Status:	      For Internal Discussion

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 (SUBTYPEP-EMPTY-NIL: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 (SUBTYPEP-EMPTY-NIL: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 (SUBTYPEP-EMPTY-NIL: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.