[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILER-DIAGNOSTICS, version 7
- To: firstname.lastname@example.org (Sandra J Loosemore)
- Subject: Re: issue COMPILER-DIAGNOSTICS, version 7
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Mon, 19 Dec 88 11:44:51 CST
- Cc: email@example.com
- In-reply-to: Msg of Fri, 16 Dec 88 13:57:11 MST from firstname.lastname@example.org (Sandra J Loosemore)
- Sender: GRAY@Kelvin.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
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
> 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