[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILER-DIAGNOSTICS, version 9
- To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: issue COMPILER-DIAGNOSTICS, version 9
- From: email@example.com (Sandra J Loosemore)
- Date: Tue, 14 Mar 89 16:05:30 MST
- Cc: firstname.lastname@example.org, email@example.com
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 17:35 EST
> Date: Tue, 14 Mar 89 17:35 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> We don't use the term "is an error" any more, do we? In the old
> CLtL terms, I think both "is an error" and "signals an error"
> situations would justify a warning. I think this part should
> be updated to the new error terminology and also should state that
> all error situations justify warnings. Of course explicit calls
> to the function ERROR don't justify warnings; I don't know whether
> the proposal can be phrased in such a way as to make that clear,
> or whether it will have to be left to common sense.
I had similar thoughts as I was looking this over before sending it
out, but I couldn't think of a way to state this that would make
sense. I felt sure that if I just changed "is an error" to "is
undefined or where an error would be signalled", somebody would be
sure to complain about it being wrong for explicit calls to ERROR.
Actually, I was hoping that if I left it alone, somebody else would
propose some alternate wording. :-)
> (3) Require COMPILE and COMPILE-FILE to handle the ABORT restart by
> aborting the smallest feasible part of the compilation.
> I think this is wrong.
This was originally a suggestion from Kent Pitman, who probably knows
better than anybody what the ABORT restart was intended to be used
for. You'll have to take it up with him, because I don't feel
qualified to argue about it one way or the other.