[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
- To: Dan L. Pierson <email@example.com>
- Subject: Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 16 Mar 89 15:30 EST
- Cc: CL-CLEANUP@Sail.stanford.edu
- In-reply-to: <8903161622.AA07142@mist.>
Date: Thu, 16 Mar 89 11:22:50 EST
From: Dan L. Pierson <firstname.lastname@example.org>
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.
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.