Re: compiler-warning-break

[Masinter.pa@Xerox.COM]

Am I correct in reading your message ("As it stands we must oppose the
proposal"), that you feel the proposal writeup is unclear, and that you would
prefer to have a greater distinction between those errors for which
*break-on-warnings* have effect and those it does not?

(Your example,   (EVAL-WHEN (COMPILE) (PRINT (+ 3 'A)))
, by the way, is not affected by *break-on-warnings*.)

My impression of the original intent is that the proposal writer very much
wanted *break-on-warnings* to cause a break "if the compiler happens to see a
variable that was bound but was unused", or other such anomolies.

However, this proposal was made before there had been more work on the signal
system. It might be more useful to arrive at a way that environment programs can
consistently interact with the compiler using well-defined signals rather than
the cruder *break-on-warnings* mechanism (which may well be obsolete.)

Do you think such a proposal be more suitable?