Issue: SUBTYPEP-EMPTY-NIL (Version 1)

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

Sorry, but this is a serious attempt to get a clarification.

I don't see that any criterion has been advanced by CLtL for believing
NIL T is any better or worse than T T.  If CLtL is clear and I've just
missed the passage, by all means cite it.  Alternatively, you may have some
personal criterion which you'd like us to buy into. If you propose that
criterion and no one contests, I'll be quite happy to see the issue
turn out to resolved by a non-controversial vote.

Here's some extra data on the problem as I see it...

Btw, another pair of test cases which has occurred to me since then are:
 (SUBTYPEP '(INTEGER (1.0) (#,(+ 1.0 SINGLE-FLOAT-EPSILON))) '())
 (SUBTYPEP '(INTEGER (1.0) (#.(+ 1.0 SINGLE-FLOAT-EPSILON))) '())
The integer range denoted in both cases is empty. If we assume that the
compiler works by calling READ, then a compiler can in principle recognize
the first as portable code so would not want to complain about it, but he
cannot recognize the second as portable as portable. An implementator who
likes to build in lots of checking to promote portability might be bothered
by this disparity. It is this kind of issue I meant of when I referred to
programmer "intention".

Note that in recent discussions of array types, we have acknowledged
any notion of programmer intention in permitting
 (SUBTYPEP '(ARRAY FIXNUM) '(ARRAY T))
and
 (SUBTYPEP '(ARRAY T) '(ARRAY FIXNUM))
to both return T. We did this not because we wanted these particular
operations to return T -- since I would assume it's clear that in an
ideal world that would be undesirable -- but because it was possible 
to better optimize a now-win situation by permitting this behavior in
order to achieve some other, more important, relationships. Perhaps
the same has to be true of SUBTYPEP for the new situation this issue 
addresses.