


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:
    But this would presumably fail to work in an implementation that
    compilied minimally with SUBTYPEP-TOO-VAGUE.
    Of course, *BREAK-ON-WARNINGS* doesn't solve this problem, it just
    dodges the one occurance of it that involves standard condition types.