Issue: BREAK-ON-WARNINGS-OBSOLETE

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

This issue came up in my review of the errors chapter for Kathy.
 -kmp

-----
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
Status:	      For Internal Discussion

Problem Description:

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

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

  Deprecate *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:

  Since deprecation is not removal, presumably everyone who conforms
  is compatible.

Cost to Implementors:

  Since the feature is deprecated rather than flushed: none.

Cost to Users:

  Since the feature is deprecated rather than flushed: none.

  Users should get used to writing (SETQ *BREAK-ON-SIGNALS* 'WARNING)
  rather than (SETQ *BREAK-ON-WARNINGS* T).

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.