# Error Terminology

• To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
• Subject: Error Terminology
• From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Date: Wed, 23 Mar 88 15:04 EST
• Cc: common-lisp-object-system@SAIL.STANFORD.EDU
• In-reply-to: The message of 22 Mar 88 11:11 EST from Dick Gabriel <RPG@SAIL.Stanford.EDU>

    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
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.