#

## Issue BREAK-ON-WARNINGS-OBSOLETE Writeup

    Status:       Passed, as amended, Mar 89 X3J13
    Issue:        BREAK-ON-WARNINGS-OBSOLETE
    Forum:	      Cleanup
    References:   *BREAK-ON-WARNINGS* (CLtL p432, CL Condition System p40)
    	      *BREAK-ON-SIGNALS* (CL Condition System p25)
    Category:     CLARIFICATION/CHANGE
    Edit history: 07-Mar-89, Version 1 by Pitman
    			 8-Apr-89, Version 2 by Masinter (as amended; update discussion)

    Problem Description:

      With the advent of *BREAK-ON-SIGNALS*, *BREAK-ON-WARNINGS* is
      redundant and unnecessary.

    Proposal (BREAK-ON-WARNINGS-OBSOLETE:REMOVE):

      Remove *BREAK-ON-WARNINGS*.

    Test Case:

      N/A

    Rationale:

      This will lead to simplification of the description of WARN.

      Not only are the two variables overkill, but they have an effect
      in an identifiably but uselessly distinct place.

    Current Practice:

      Most have *BREAK-ON-WARNINGS*.

    Cost to Implementors:

      slight.

    Cost to Users:

      Users will have to write (SETQ *BREAK-ON-SIGNALS* 'WARNING)
      rather than (SETQ *BREAK-ON-WARNINGS* T).

      Since this is mainly done interactively and not in programs,
      the cost is slight.

    Cost of Non-Adoption:

      The definition of WARN will be gratuitously cluttered.

    Benefits:

      Cost of non-adoption is avoided.

    Aesthetics:

      Slight improvement.

    Discussion:

      Pitman thinks this is a good idea, but doesn't think a lot of time
      should be wasted discussing the issue if there is strong opposition.

Copyright 1996-2001, Xanalys Inc. All rights reserved.