Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 16 Mar 89 11:22:50 EST
    From: Dan L. Pierson <pierson@mist.encore.com>

    Oops, braino.  The previous version of this message used MEMBER when I
    meant OR.  Here is a corrected version:

	Sorry for the late reply on this.
    
	The only problem with this proposal is that *BREAK-ON-SIGNALS* seems
	to implicitly depend on either:
    
	    1. Having all condition types you want to control in one inheritance
	       tree, or
    
	    2. SUBTYPEP supporting OR type specifiers.
    
	For example, suppose you create a new subtype of CONDITION, disjoint
	from WARNING, called FROB, that does not break by default.  Now
	suppose you want to break on both WARNING and FROB, but not on another
	disjoint subtype of CONDITION, say BLAT.  The only way I can see to do
	this would be:
    
	    (SETQ *BREAK-ON-SIGNALS* '(OR WARNING FROB))
    
	But this would presumably fail to work in an implementation that
	compilied minimally with SUBTYPEP-TOO-VAGUE.
    
I don't believe this is a real problem, because the signaller has a
condition object in its hand, so it would be calling TYPEP, not SUBTYPEP.
TYPEP has no problems working with OR.

In fact SUBTYPEP has no problems working with OR as the second argument,
so you have also pointed out a bug in SUBTYPEP-TOO-VAGUE; it should not
allow SUBTYPEP to fail when just the second argument involves OR.  I think
this has been pointed out before.