[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
- Subject: Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
- From: Dan L. Pierson <email@example.com>
- Date: Thu, 16 Mar 89 11:22:50 EST
- Cc: CL-CLEANUP@Sail.stanford.edu
- In-reply-to: Your message of Thu, 16 Mar 89 10:41:15 -0500. <8903161541.AA07042@mist.>
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
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.
Of course, *BREAK-ON-WARNINGS* doesn't solve this problem, it just
dodges the one occurance of it that involves standard condition types.