CLOS Error Terminology

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

The following is the current section on error terminology in the CLOS
document. I should point out that this section is currently
under debate. The areas of debate are the definitions of ``undefined''
and ``unspecified,'' along with the general philosophy that extensions
are disallowed by default (which is the opposite to Common Lisp):

\beginSection{Error Terminology}

The terminology used in this document to describe erroneous
situations differs from the terminology used in {\it Common Lisp:
The Language}, by Guy L. Steele Jr.  This terminology involves {\bit
situations}; a situation is the evaluation of an expression in some
specific context. For example, a situation might be the invocation of
a function on arguments that fail to satisfy some specified
constraints.

In the specification of the \CLOS, the behavior of programs in all situations
is described, and the options available to the implementor are defined. No
implementation is allowed to extend the syntax or semantics of the \OS\ except
as explicitly defined in the \OS\ specification. In particular, no
implementation is allowed to extend the syntax of the \OS\ in such a way that
ambiguity between the specified syntax of \OS\ and those extensions is
possible.

``When situation $S$ occurs, an error is signaled.''

This terminology has the following meaning:

\beginlist

\item{\bull} If this situation occurs, an error will be signaled in
the interpreter and in code compiled under all compiler safety
optimization levels.

\item{\bull} Valid programs may rely on the fact that an error will be
signaled in the interpreter and in code compiled under all compiler
safety optimization levels.

\item{\bull} Every implementation is required to detect such an error
in the interpreter and in code compiled under all compiler safety
optimization levels.

\endlist

``When situation $S$ occurs, an error should be signaled.''

This terminology has the following meaning:

\beginlist

\item{\bull} If this situation occurs, an error will be signaled at
least in the interpreter and in code compiled under the safest
compiler safety optimization level.

\item{\bull} Valid programs may not rely on the fact that an error will be
signaled.

\item{\bull} Every implementation is required to detect such an error
at least in the interpreter and in code compiled under the safest
compiler safety optimization level.

\item{\bull} When an error is not signaled, the results are undefined (see
below).

\endlist

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

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

This terminology has the following meaning:

\beginlist

\item{\bull} The effects of this situation are not specified in
the \OS, but the effects are harmless.

\item{\bull} Implementations are allowed to specify the effects of
this situation.

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

\endlist

``The \CLOS\ may be extended to cover situation $S$\negthinspace.''

The meaning of this terminology is that an implementation is free to treat
situation $S$ in one of three ways:

\beginlist

\item{\bull} When situation $S$ occurs, an error is signaled at least
in the interpreter and in code compiled under the safest compiler
safety optimization level.

\item{\bull} When situation $S$ occurs, the results are undefined.

\item{\bull} When situation $S$ occurs, the results are defined and
specified.

\endlist

In addition, this terminology has the following meaning:

\beginlist

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

\endlist

``Implementations are free to extend the syntax $S$\negthinspace.''

This terminology has the following meaning:

\beginlist

\item{\bull} Implementations are allowed to define unambiguous extensions
to syntax $S$\negthinspace.

\endlist

The \CLOS\ specification may disallow certain extensions while allowing others.

\endSection%{Error Terminology}