Issue COMPILER-DIAGNOSTICS, v7

[Kim A. Barrett <IIM@ECLA.USC.EDU>]

> Date: Fri, 23 Dec 88 17:50 EST
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> Subject: issue COMPILER-DIAGNOSTICS, version 7

> I would not use terms like NOTICE, ALERT, etc. because I think people
> will not like our locking down so many highly generic words. Furthermore,
> I think you'd have a hard time making a serious case that there was a
> need for that particular number of gradations without some experience to
> back it up. In my opinion, it would be better at this point to gain
> some experience in real implementations and then to suggest things like
> this on the next standardization cycle.
> 
> Even so, I would expect that the most likely to be adopted types would
> be subtypes of WARNING, not disjoint types. eg, STYLE-WARNING. Making
> them subtypes of WARNING means you can use WARN without introducing a
> new primitive. It means you can use MUFFLE-WARNING without introducing
> other MUFFLE-xxx things. Simpler. Little or no lost functionality.

For the most part I agree with Kent.  However, I think there is a difference
between things like style warnings and progress type messages of the form

   Compiling function FRED.

It seems reasonable to give the user a mechanism for controling that kind of
output too, but I don't really think of such messages as warnings.  NOTICE
seems like a nice, simple thing to use to say that something is happening but
you can ignore it if you like, but maybe the name implies more priority than is
intended.  Maybe some other name?

kab
-------