Issue COMPILER-WARNING-BREAK (Version 3)

[Masinter.pa@Xerox.COM]

In reviewing (and preparing hardcopies) of open issues, I discovered a
version 3 of this proposal that was never mailed. The notes say that
this issue is awaiting the error proposal, but frankly, I'm no longer
sure what interaction we might expect with the error proposal.




!
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

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.

Cost of not adopting this change:

Applications which want to programmatically deal with compiler
interactions would have 

Benefits:

This would make the language definition more consistent by making it
less subject to special cases.

Conversion Cost:

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

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.