Re: issue COMPILER-DIAGNOSTICS, version 2

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> Date: Thu, 20 Oct 88 15:05 EDT
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> 
> I wonder: is it really true that COMPILE-FILE's return value is not
> well-defined and that it is not covered in Cleanup issue
> ARGUMENTS-UNDERSPECIFIED? That's a small point, of course.

I suspect the issue you're thinking of is RETURN-VALUES-UNSPECIFIED,
and no, it doesn't say anything about COMPILE-FILE.

> I think this goes at things from the wrong angle. I would prefer to see any
> kinds of conditions be permitted to be signalled, but have the compiler required
> to handle unhandled errors by turning them to warnings and aborting some
> part of the compilation.
> 
> I think the restriction about what kinds of errors might be signalled is
> very arbitrary and I doubt anyone will buy into it. As long as COMPILE-FILE
> will trap the errors that the user handler (mentioned below) doesn't, the
> user program is not going to break. 
> 
> But COMPILE-FILE should establish its handlers
> unconditionally in case the user-supplied handler declines. Also, you probably
> want to define that the ABORT restart will be handled and abort the smallest
> feasible part of the compilation.

You make a good argument for this.  I'll give this some more thought
and see if I can come up with a revised proposal along the lines you
suggest.  I'm not sure that we want to -require- the compiler's error
handler to turn errors into warnings, but certainly they should be
-allowed- to do so.  And, I still think it's important for a user
error handler to be able to distinguish between serious compilation
problems and mere kibbitzing.

> I would prefer to see the interfaces to LOAD made more specific about what
> kinds of options each of the keywords are supposed to control, and then as
> symmetric as possible a set of options provided for COMPILE/COMPILE-FILE.

I thought of this earlier, as well.  Would we also want to add a
*COMPILE-VERBOSE* variable?  Is there any reason why this shouldn't be
split off as a separate issue?  (One could argue that what the
compiler prints out during its normal operation has nothing at all to
do with what it does with errors.)

Your other comments are all very useful.  Thank you.

-Sandra
-------