COMPILER-WARNING-BREAKCOMPILE and COMPILE-FILE functions does not say whether *BREAK-ON-WARNINGS* affects warnings output by the compiler. If this is to be allowed, it should be an explicitly expressed part of the contract.COMPILE and COMPILE-FILE should state that these functions are required to break on warnings if *BREAK-ON-WARNINGS* is true (just as if it calls WARN).
Note: User interface commands provided by particular vendor implementations which implicitly call COMPILE or COMPILE-FILE could bind *BREAK-ON-WARNINGS* back to NIL if they felt it important to not break for some reason relating to cultural compatibility. This would not interfere with the proposed new semantics for the functions COMPILE and COMPILE-FILE.
*BREAK-ON-WARNINGS* is defined to cause the debugger to be entered when warnings occur. If the compiler is permitted to warn (separate ballot item), the effect of this variable on compiler warnings should be nailed down.*BREAK-ON-WARNINGS* and others probably do not.WARN directly but some other mechanism might have to be edited, but it would not be a major change.WARN and the kind of warning that comes from compilation to be conceptually grouped.*BREAK-ON-WARNINGS* and the compiler are part of the environment rather than the language.
We considered but rejected the notion of a separate *COMPILER-BREAK-ON-WARNINGS*. It is possible that with the adoption of a signal/error system that the *BREAK-ON-WARNINGS* mechanism could be replaced in its entirity by a more structured signal/handler structure, making this proposal moot. TITAN TITAN ê$ºã'ßID ¾Ó
Æzº*start* 02303 00024 USa Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU> Redistributed: xerox-cl-cleanup^.pa Received: from SAIL.Stanford.EDU by Xerox.COM ; 23 FEB 88 11:36:40 PST Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 23 Feb 88 11:15:33 PST Date: 23 Feb 88 14:06:00 EDT From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> Subject: compiler-warning-break To: "cl-cleanup" <cl-cleanup@sail.stanford.edu> cc: vanroggen@hudson.dec.com Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
The proposal COMPILER-WARNING-BREAK:YES leaves a lot of issues unresolved. As it stands we must oppose the proposal.
The principal problem is that it isn't clear what warnings are. Currently VAX LISP distinguishes between two different kinds of ``error conditions'': ones signalled during compilation with ERROR, CERROR, WARN, and the like, and ones detected by the compiler from examination of the source code being compiled.
The former arise in cases like (EVAL-WHEN (COMPILE) (PRINT (+ 3 'A))) or when READ encounters an error while reading a form from the file. However, when this happens during a COMPILE-FILE, we try to continue with the compilation, so as to maximize the usefulness and information generated by the compiler. During COMPILE, the normal error signalling and handling is in effect, so *BREAK-ON-WARNINGS* would indeed control ``breaking'' upon WARN.
The latter arise when the compiler is compiling a form like (SEARCH X) or (LET 3 (F)) Then we also distinguish these cases by how serious they are. In particular there are ``errors'' and ``warnings''. However, detecting these anomalies is expected of the compiler, and thus they are not treated as ``errors'' or ``warnings'' in the sense of the lisp functions ERROR or WARN. It doesn't make sense to ``break'' and go into the debugger if the compiler happens to see a variable that was bound but was unused (with no IGNORE declaration).
So it isn't clear from the proposal which of these cases are being addressed. If it's really more to control what happens when one does a COMPILE, then the proposal should be changed to say that COMPILE-FILE is not specified as proposed, and what conditions should be reported as being ``warnings'' should be specified.
---Walter ------