compiler-warning-break

["AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>]

  From: Masinter.pa@Xerox.COM Message-ID: <880304-094104-8049@Xerox>
  
  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?

Yes, not only a greater distinction, but some definition as to when and
how this could be used.  What kinds of conditions must be "warned"?
Are "potential errors" detected by the compiler real "errors"?  Is there
a difference in such behavior between COMPILE and COMPILE-FILE?
  
  (Your example,   (EVAL-WHEN (COMPILE) (PRINT (+ 3 'A)))
  , by the way, is not affected by *break-on-warnings*.)

You're right. (Unless an implementation decided to WARN when an arithmetic
operation got illegal arguments, I suppose.)  However the point of the
example was to distinguish run-time signalled conditions from conditions
detected by the compiler in examining source code.
  
  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?

Yes, I think deciding on an error system and deciding what conditions are
signalled by the compiler should precede decisions on such minor things
as what *BREAK-ON-WARNINGS* means in a few particular situations.

			---Walter
------