[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue status, 12/12/88 (issue COMPILER-DIAGNOSTICS)
- To: "firstname.lastname@example.org"@multimax.encore.com (Sandra J Loosemore)
- Subject: Re: issue status, 12/12/88 (issue COMPILER-DIAGNOSTICS)
- From: Dan L. Pierson <email@example.com>
- Date: Tue, 13 Dec 88 14:53:31 EST
- Cc: firstname.lastname@example.org
- In-reply-to: Your message of Mon, 12 Dec 88 17:58:55 -0700. <8812130058.AA03353@defun.utah.edu>
I believe that the original intent of the NOTICE condition type was to
make it something disjoint from SEVERE-CONDITION and WARNING, right?
As Pitman pointed out some time ago, introducing a new condition type
requires more than just saying it exists. Making the condition type
used for these kinds of compiler diagnostics a subtype of WARNING has
the advantage of simplicity -- it can simply borrow all the same
mechanisms as WARNING conditions, including the WARN function and the
MUFFLE-WARNING restart to disable printing of messages. Doing all of
this from scratch for a disjoint condition type would be more
complicated than I have the time to figure out right now. If you feel
ambitious enough to tackle this, feel free. I agree that there is no
inherent reason why we cannot define a new condition type on our own.
Actually, there isn't that much special about warnings in the
condition system (Rev 18, as passed at the June meeting):
WARN string &rest arguments
Can't be used because it signals exactly type WARN, not a subtype.
WARN condition &rest arguments
Useable, but no advantage; it's the same (except for trivial
error checking) as:
SIGNAL condition &rest argments
Obsolete, use *BREAK-ON-SIGNALS*.
Would be useful, but since it's just a standard function it
would be easy to add another one. However, This is one of the
two strongest arguments in favor of making NOTICE and INFO
subtypes of WARNING.
The real issue is the CONDITION type hierarchy. It currently looks like:
+--------------+------+----------------+---- . . .
| | |
| | |
SIMPLE-CONDITION SERIOUS-CONDITION WARNING
+-----+--------------------------+--- . . .
+------------+--+-------------------+--- . . .
| | |
| | |
SIMPLE-ERROR ARITHMETIC-ERROR CONTROL-ERROR
. . . . . .
It is explicitly legal to add new intermediate types as long as the
specified subtype and disjointess relationships are not violated. As
I see it, we have the following options:
1. Make NOTICE (and INFO subtypes of WARNING). This supports
unchanged to use MUFFLE-WARNING, and *BREAK-ON-WARNINGS* but
does not allow the use of WARN. My objection to this is that I
want the INFO condition and I just can't see INFO as a type of
WARNING. The biggest advantage of this is that it doesn't
change the second level of the current condition hierarchy.
2. Add a new subtype of CONDITION, say MESSAGE, with WARN, NOTICE,
and INFO as subtypes. Add the restart function MUFFLE-MESSAGE.
This supports MUFFLE-MESSAGE, *BREAK-ON-SIGNALS*, and SIGNAL.
Some people might well object that WARNING should be disjoint
from both MESSAGE and ERROR.
3. Add a new subtype of CONDITION, say MESSAGE, with NOTICE, and
INFO as subtypes. Add the restart function MUFFLE-MESSAGE.
This supports (and requires) MUFFLE-MESSAGE, MUFFLE-WARNING,
*BREAK-ON-SIGNALS*, and SIGNAL.
All in all, I slightly prefer 3, could easily be convinced by 2 and am
just not fond of 1. I don't see this as a tremendous problem, so if
people (especially Kent) agree, I'll be glad to write this up, either
as part of COMPILER-DIAGNOSTICS or COMPILER-VERBOSITY, or as (sigh)
yet another proposal.