Issue COMPILER-WARNING-BREAK (Version 4)

[Masinter.pa@Xerox.COM]

Version 3 had an incomplete sentence under "cost of not adopting this
change". I removed it, and put the negation in the Benefits section.


!
Issue:        COMPILER-WARNING-BREAK
References:   COMPILE (p438), COMPILE-FILE (p439)
Category:     CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/27/87
              Version 2 by cleanup committee 15-Mar-87 14:25:03
              Version 3 by Masinter  5-Jun-87
              Version 4 by Masinter 23-Nov-87

Problem Description:

The description of the COMPILE 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.

Proposal (COMPILER-WARNING-BREAK:YES):

The definitions of 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.

Rationale:

*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.

Current Practice:

Some compilers respect *BREAK-ON-WARNINGS* and others probably do not.

Adoption Cost:

Those compilers which do not use WARN directly but some other mechanism
might have to be edited, but it would not be a major change.

Conversion Cost:

Probably little or no user code would be affected by this change.

Benefits:

This would make the language definition more consistent by making it
less subject to special cases. Portable programs can be assured of
consistent behavior when dealing with the compiler.

Aesthetics:

Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.

Discussion:

*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.