[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: "cl-cleanup" <firstname.lastname@example.org>
- Subject: compiler-warning-break
- From: "AITG::VANROGGEN" <email@example.com>
- Date: 23 Feb 88 14:06:00 EDT
- Cc: vanroggen
- Reply-to: "AITG::VANROGGEN" <firstname.lastname@example.org>
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
(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.