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

[Dan L. Pierson <pierson@mist.encore.com>]

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.

    2. Or SUBTYPEP supporting MEMBER 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* '(MEMBER WARNING FROB))

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.