[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILER-DIAGNOSTICS, version 7
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: issue COMPILER-DIAGNOSTICS, version 7
- From: firstname.lastname@example.org (Sandra J Loosemore)
- Date: Fri, 30 Dec 88 12:30:13 MST
- Cc: email@example.com, firstname.lastname@example.org
- In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 23 Dec 88 17:50 EST
> Date: Fri, 23 Dec 88 17:50 EST
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> I think this proposal is unduly complicated.
Actually, I'm inclined to agree with you on this.
> The problem you state could be addressed by the following much simpler
> 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.
This would be an improvement over the current situation, but I'm
concerned that besides possibly not being enough to satisfy the needs
of people who are trying to write portable system-building utilities,
it won't do anything to solve the stated problem, namely how to
suppress useless style warning messages.
> Even so, I would expect that the most likely to be adopted types would
> be subtypes of WARNING, not disjoint types. eg, STYLE-WARNING.
I've been leaning in this direction too.
I think that what we need to do on this issue is come up with one or two
alternative proposals to include in the next version of the writeup, and
distribute that to X3J13 for further discussion. I'll put it on my list of
things to do next week.