Error Terminology

[Dick Gabriel <RPG@SAIL.Stanford.EDU>]

Here is the concept behind the terminology. Let D be the domain of
expressions and A a domain of answers. Let E be a function 
E: D x Env1 x ... x Envn => A. The meaning is that E takes some
expressions in D plus some number of environments and produces an answer.
E is the meaning of expressions.  Let's restrict D to expressions
described in CLOS.  We consider projections of the domain of E to D.  E is
normally a partial function, being defined for only a subset of D, called
D'.  The error terminology has to do with describing the various elements
in D-D'.

There are 4 subsets of D' of interest; call them D'1, D'2, D'3, and D'4.
D'1 is the subset such that attempting to apply E to its elements
results in an error being signaled in all cases and implementations. D'2
is the subset such that attempting to apply E to its elements results in
an error being signaled in the interpreter and under the safest compiler
safety setting in all implementations.  D'3 is the subset on which
implementations are free to define new meanings - that is, an
implementation is free to extend the domain of well-definedness to subsets
of D'3.  Note that D'1 and D'2 are pairwise disjoint with D'3.  Let D'4 be

D'4 = (D-D')-(D'1+D'2+D'3)

We are talking about D'1 when we say ``When situation $S$ occurs, an error
is signaled.''

We are talking about D'2 when we say ``When situation $S$ occurs, an error
should be signaled.''

We are talking about D'3 when we say ``The \CLOS\ may be extended to cover
situation $S$.''

And we are talking about D'4 when we say ``When situation $S$ occurs, the
results are undefined.''

Notice that D'4 has an odd definition: It's not part of the required
well-defined portion of D, we don't want to specify that all
implementations try to detect elements of D'4 even in simple cases, and
the authors of CLOS don't want anyone to extend CLOS to mean anything on
those elements (sometimes because there is no reasonable meaning).

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.

Since we don't seem to want to tell implementors to keep their paws off
of D'4, and since I assume we don't want some mathematical treatment like
this message, how about telling users to keep their hands off of D'4, thus
rendering the attempts of implementors fruitless? Note that we talk about
valid programs, not portable ones.  Thus someone living in one implementation
has to think twice about venturing into D'4 land.

**************************************************************************

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

This terminology has the following meaning:

\beginlist

\item{\bull} If this situation occurs, the results are unpredictable.  The
results may range from harmless to fatal.

\item{\bull} Implementations are allowed to detect this situation and
signal an error, but no implementation is required to detect the
situation.

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

\endlist

****************************************************************************

			-rpg-