issue COMPILER-DIAGNOSTICS, version 7

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

I think this proposal is unduly complicated.

The problem you state could be addressed by the following much simpler
proposal:

 Specify that COMPILE and COMPILE-FILE return a second value, SUCCESS-P.
 Define that compilers are permitted to handle conditions of type ERROR,
 turning them into warnings and continuing to compile as appropriate, 
 but that if an error was turned into a warning so that COMPILE or 
 COMPILE-FILE could complete its operation, NIL must be returned as the
 second value. The normal successful return value would be T.

As I see it, this doesn't preclude doing on a per implementation basis
the things you suggest in the proposal now on the table, but it is 
conceptually simpler, does not constrain implementations nearly as
much, and is far less likely to be accused of being "gratuitous hair".

If you wanted to suggest a third return value, WARNINGS-P, I wouldn't
balk. I personally don't think it's needed. If I needed it, I would 
probably just direct warnings to a string stream and then see if the
stream was non-null at the end. But I suppose if someone claims that the
circumstance comes up a lot and wants the feature more primitively, I
could understand that.

If you were going to suggest new condition types, I would suggest doing
it under separate cover so as to decouple it from this issue, which I
think has the simpler solution described above.

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.