Re: Issue COMPILER-DIAGNOSTICS, v7

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

[[Meta-note to cl-cleanup.  One of the proposals for handling compiler
  messages is based on signalling all messages as conditions with the
  standard signalling function "printing" the message iff the
  condition isn't handled.  I think that this approach can, and
  should, be applied to messages in the cleanup domain as well so I'm
  forwarding just this message to cleanup to get a sense of the
  sentiment there.]]

    Part of my objection is that the name NOTICE is too vanilla.
    There are other possible meanings and I can see people being bummed
    if we use it up.
    
    The Lisp Machine has a thing called a notification. I might be
    susceptible to calling the type a NOTIFICATION and making a function
    called NOTIFY. Then, at least, there would be current practice behind
    the idea.
    
I have no objection to these name changes.

    In another message, you suggested things like
     Compiling FOO.
    could be controlled by this, but there's already a competing proposal
    for a :PRINT keyword to COMPILE-FILE which would cause that kind of
    thing to go to STANDARD-OUTPUT (presumably unconditionally). I don't
    want -too- many ways to do the same thing, so we should be careful about
    our motivation.
    
That's true.  I am mildly opposed to the competing proposal because
it's redundant with mine.  I am strongly in favor of one general
condition-based mechanism for all of these messages.

    If we made a notification facility, I think it should be done by Cleanup,
    not compiler. Then perhaps GC messages could be done using it, and 
    the GC-MESSAGES issue (which deals with suppressing such messages) could
    be handled as part of the same thing, too.
    
No object, since it also came up in connection with Moon's comments on
GC-MESSAGES, if forwarding this to cl-cleanup as well.

    I don't have time to pursue this further and I can't say for sure that
    if someone fleshed this out that I would necessarily support it ... but
    I am not unalterably opposed to it if it's done in a way that motivates
    its use (and doesn't just go in randomly with not even an initial purpose),
    doesn't lock down too many short highly generic names, etc.
    
I can try to come up with something, if a condition-based approach to
this whole problem looks acceptable.