Issue: OPTIMIZE-SAFETY (Version 1)

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

Sorry this is last-minute, but I believe it to be important.
 -kmp

-----
Issue:        OPTIMIZE-SAFETY
Forum:	      Cleanup
References:   OPTIMIZE declaration (p160),
	      Issue ERROR-TERMINOLOGY
Category:     CLARIFICATION/CHANGE
Edit history: 6-Mar-89, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  CLtL permits implementations to ignore OPTIMIZE declarations,
  yet the new error terminology has a term ``should signal''
  which guarantees that certain errors will be signalled in highest
  safety.

  This situation is at odds with the desire on the part of some vendors
  to provide highly delivery configurations for Common Lisp, which
  are streamlined to be small and fast at the expense of error checking.

  If an implementation is permitted to start out in low safety mode,
  and is also permitted to ignore OPTIMIZE SAFETY declarations, then
  the meaning of ``should signal'' is called into question.

Proposal (OPTIMIZE-SAFETY:START-SAFE-OR-HEED-OPTIMIZE):

  1. Define the initial safety setting of an implementation's
     OPTIMIZE declarations to be implementation dependent. Conforming
     implementations must document the initial setting.

  2. Require every implementation to do at least one (and possibly
     both) of the following:

	a. Start in highest safety mode.
	b. Not ignore the OPTIMIZE declaration.

     Put another way, an implementation implementation which starts
     out in ``unsafe'' mode is prohibited from ignoring OPTIMIZE
     declarations that would allow the programmer to declare code
     to require ``safe'' treatment.

Rationale:

  1. This allows a particular implementation (or a particular core-image
     that is part of an implementation family) to be naturally biased
     for delivery.

  2. This makes sure that situations like
	(LOCALLY (DECLARE (OPTIMIZE (SPEED 0) (SAFETY 3)))
	         ...)
     will reliably select "safe code" even in implementations that are
     initially biased for speed over safety.

Current Practice:

  Symbolics Genera and Symbolics Cloe conform to the stated proposal.

Cost to Implementors:

  Considerable error checking would have to be added to upgrade any
  non-conforming implementations, if in fact there are any.

  Another alternative would be for a non-conforming implementation to
  identify itself as a special "subset" of Common Lisp that does not
  support those options. That would require no work, but would require
  careful documentation in order for users to understand the consequences.
  However, such a subset could easily notice when the programmer was
  trying to enter a high safety mode explicitly, and could warn that he
  was probably going to lose.

Cost to Users:

  None. Most users will regard this as a bug fix.

Cost of Non-Adoption:

  Any useful interpretation of ``should signal'' will be in severe
  jeopardy.

Benefits:

  More truth in packaging.

Aesthetics:

  Adding this kind of reliability presumably improves aesthetics.

Discussion:

  Pitman supports this proposal.