Error Terminology

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

    Date: 22 Mar 88  0811 PST
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    ``When situation $S$ occurs, the results are undefined.''

    \item{\bull} No valid program may depend on the effects of this
    situation, and all valid programs are required to treat the effects 
    of this situation as unpredictable.

Agreed.

I'm not concerned about enforceability here, since this is a statement
about programs rather than about implementations, and although it has been
proposed to validate implementations, no one has proposed to validate all
the programs in existence.

    Is D'4 empty? No.  Here is an example:

    ``This implies that a programmer must not use {\bf change-class} inside a
    method if any methods for that generic function access any slots, or the
    results are undefined.''

    We don't want to make implementations detect uses of change-class within a
    method that accesses slots that might change as a result of the
    change-class.  It's ok if an implementation detects it, though. But it's
    not ok for any implementor to try to extend CLOS to mean something in this
    case. An implementor might specify that when this situation happens the
    system has a conniption, but no reasonable programmer would depend on that.

Is this really a good example of an element of D'4?  I fail to
understand why we want to forbid implementors from making this work.
After all, the only problem with implementing this is that some
optimizations of slot-value, which some people have in mind to use,
can't handle it.