Re: issue COMPILER-DIAGNOSTICS, version 7

[David N Gray <Gray@DSG.csc.ti.com>]

> Subject: issue COMPILER-DIAGNOSTICS, version 7

This proposal looks good, but there are a couple of little things worrying
me.  One is the potentially confusing shift in terminology by which
compiler messages that are conventionally referred to as "warnings", are
now called "alerts", programmer errors are reported as "warnings", and
only what is conventionally called "fatal errors" are reported as "errors".
I don't know what can be done about this, though, since we do want some
down-grading in severity so that the compiler issues a message and continues
for a situation that will signal an error if the compiled code is run.
Probably we just need to be careful how this is documented in order to
minimize confusion.

Another thing is that this doesn't provide a way to suppress style
"warnings" [ALERT conditions] on a local basis.  For example, Lisp
Machines have a macro INHIBIT-STYLE-WARNINGS that can be wrapped around a
single form to keep the compiler quiet.  I wonder if we might want a
COMPILER-HANDLER-BIND macro for specifying handlers at compile time?  This
would be analogous to COMPILER-LET, but it could avoid the problems that
have doomed COMPILER-LET by specifying that the evaluator is free to
ignore it.

> Gray ...
> suggests that the :HANDLER keyword argument be renamed :ERROR-HANDLER. 

That was when I thought it would only be for ERROR conditions.  Now that
the example shows doing 
    (handler-bind ((condition handler)) ...
the name :HANDLER is more appropriate, although it might be better to call
it :CONDITION-HANDLER.