Re: issue status, 12/12/88 (issue COMPILER-DIAGNOSTICS)

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

    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

    *BREAK-ON-WARNINGS*
    	Obsolete, use *BREAK-ON-SIGNALS*.

    MUFFLE-WARNING
    	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:

                            CONDITION
                                |
          +--------------+------+----------------+---- . . .
          |              |                       |
          |              |                       |
 SIMPLE-CONDITION    SERIOUS-CONDITION        WARNING
                         |                       |
                         |			 |
                         |                 SIMPLE-WARNING
                         |
                         |
                   +-----+--------------------------+--- . . .
                   |                                |
                   |                                |
                 ERROR                       STORAGE-CONDITION
                   |
                   |
      +------------+--+-------------------+--- . . .
      |      	      |		     	  |
      |      	      |		     	  |
 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.