Re: SUBTYPEP-TOO-VAGUE (initial draft)

[Rob.MacLachlan@WB1.CS.CMU.EDU]

    From: Eric Benson <edsel!eb@labrea.stanford.edu>
    Message-Id: <8807120027.AA00951@blacksox.lucid.com>
    To: sandra@cs.utah.edu
    Subject: SUBTYPEP-TOO-VAGUE (initial draft)
    
    AND, OR and NOT are only messy to deal with if any of the type
    specifiers involved use SATISFIES.  Otherwise they are well defined.
    I think you should remove AND, OR and NOT from the "exceptions list."
    
I would change that to say that AND OR and NOT are only *impossible* when
they involve uses of SATISFIES.  They are plenty messy otherwise.  In a
compiler I am working on, I have 1500 lines of hairy and reasonably dense
code for a SUBTYPEP that only partially understands OR and AND, and doesn't
handle NOT at all.  I strongly recommend that SUBTYPEP not be made too firm
until a public domain SUBTYPEP that implements the proposal is available.

How about:
    (subtypep 'integer
	      '(or (rational * (6)) (member 6) (integer 7 *)))

It is fairly easy to see that this is true, but not so easy to see how to
to write a program to solve the general problem.  It might even be a Hard
Problem, given that we have the capability to describe infinite sets.


Even Sandra's proposal may be more hairy than it is worth forcing on the
Common Lisp community.  The MEMBER specifier can also be pretty perverse,
for example: 
    (subtypep '(integer 3 11) '(member 3 4 9 5 6 10 7 11 8 17 15)) => T, T

Any how many SUBTYPEPs correctly recognize that float types are finite?
    (subtypep `(short-float 0s0 (,(* short-float-epsilon 4)))
	      `(member 0s0
		       ,(* short-float-epsilon 1)
		       ,(* short-float-epsilon 2)
		       ,(* short-float-epsilon 3))) => T, T

  Rob