[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue status, 12/12/88 (issue COMPILER-DIAGNOSTICS)
- To: Dan L. Pierson <pierson@mist.encore.com>
- Subject: Re: issue status, 12/12/88 (issue COMPILER-DIAGNOSTICS)
- From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Date: Mon, 12 Dec 88 17:58:55 MST
- Cc: cl-compiler@sail.stanford.edu
- In-reply-to: Dan L. Pierson <pierson@mist.encore.com>, Mon, 12 Dec 88 17:52:29 EST
> Date: Mon, 12 Dec 88 17:52:29 EST
> From: Dan L. Pierson <pierson@mist.encore.com>
>
> COMPILER-DIAGNOSTICS
> The NOTICE condition type hasn't happened yet. I was going to change
> references to the NOTICE condition to the STYLE-WARNING condition,
> which is a subtype of warning (allowing user condition handlers to use
> the MUFFLE-WARNING restart on it to suppress the messages). Any
> objections?
>
> The NOTICE condition type is created by this proposal. There is no
> need for any other action. I object to its removal on the grounds
> that a separate issue to create it hasn't been passed in some other
> place (are you thinking of Cleanup?).
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.
-Sandra
-------