Issue: OPTIMIZE-SAFETY (Version 1)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 6 Mar 89 17:42 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

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

Me too.  But maybe it's already taken care of in the editorial
committee; see below.  Also see an important question posed in
the last three paragraphs.

    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.

Item 1 is pretty non-controversial and is probably the status quo
of the current draft specification.

Item 2 appears to be a rewording of what the ERROR-TERMINOLOGY editorial
issue already says, unless I am missing something, in its definition of
the terms "safe code" and "unsafe code."

By the way, I'm pleased to note that the earlier idea that the
interpreter is always safe has been dropped, and there is now no
explicit distinction between the interpreter and the compiler.  I assume
this means that an implementation must either treat all interpreted code
as safe, or respect OPTIMIZE declarations in the interpreter, or not
have an interpreter and compile everything.

    Current Practice:

      Symbolics Genera and Symbolics Cloe conform to the stated proposal.

I think this is true only in the trivial sense that the language those
two implementations implement, CLtL Common Lisp, does not have any
situations that are specified to signal an error in safe code.  I
haven't reviewed the draft standard yet, but presumably when we are
finished there will be hundreds of situations specified to signal an
error in safe code, and only some fairly arbitrary subset of those
situations will signalled in the two Symbolics implementations, until
they are converted from implementing CLtL Common Lisp to implementing
the new Common Lisp.  Currently Genera always runs in safe mode, but
that safe mode does not check the same conditions that the future Common
Lisp standard will presumably require to be checked.

I do have a question about the intended meaning of safe code.  Is safe
code a development environment feature, in which case it makes sense for
there to be non-development-oriented implementations that do not provide
the feature.  Is safe code something you turn on while developing new
programs that you don't trust, but only the programmer depends on, and
the functioning of a correct program never depends on an error being
signalled because the error occurs in safe code?

Or on the other hand is safe code a language feature that is going to be
used routinely in portions of delivered applications where the
programmer has deliberately chosen safe mode as a way of implementing
control structure of the program?

Kent's proposal here, and the ERROR-TERMINOLOGY editorial proposal, seem
to incline towards the language feature, but it's certainly an odd
way to implement control structure.