First Try at Terminology

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

At the Symbolics meeting we decided to introduce some terminology
about erroneous situations for use in the final document. Here is
a first attempt at that terminology - Sit is a situation and Syn is
syntax:

The terminology defined in 1 - 4 refers to situations that might occur,
while the terminology defined in 5 refers to syntax.  

A ``situation'' is one of the following:

	1. an expression in which the first form is given or specified and
	   the remaining subexpressions are either given, specified, or
	   evaluate to objects satisfying certain constraints;

	2. a state of affairs within a running CLOS system.

Examples: When the function + is given a non-number as an argument, that
is a situation under definition 1; when a numeric operation causes an
arithmetic overflow, that is a situation under definition 2.

``Syntax'' refers to the nature of the lambda-list of a function,
the nature of the defmacro lambda-list of a macro, and the number and
nature of the subexpressions in a special form.

In the specification of 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 CLOS except
as explicitly defined in the CLOS specification. In particular, no
implementation is allowed to extend the syntax of CLOS in such a way that
ambiguity between the specified syntax of CLOS and those extensions is
possible.

The following are descriptive phrases and their meanings:

1. ``When Sit occurs an error is signaled.''

The meaning of this terminology is:

	a. If this situation occurs, an error will be signaled in code
	   compiled under all compiler safety optimization levels and in
	   the interpreter.

	b. Valid CLOS programs may rely on the fact that an error will be
	   signaled in code compiled under all compiler safety
	   optimization levels and in the interpreter.

	c. Every CLOS implementation is required to detect such an error
	   in code compiled under all compiler safety optimization levels
	   and in the interpreter.

2. ``When Sit occurs an error should be signaled.''

The meaning of this terminology is:

	a. If this situation occurs, an error will be signaled at least in
	   code compiled under one compiler safety optimization level and
	   in the interpreter.

	b. Valid CLOS programs may not rely on the fact that an error will be
	   signaled.

	c. Every CLOS implementation is required to detect such an error
	   at least in code compiled under one compiler safety
	   optimization level and in the interpreter.

	d. When an error is not signaled, the results are undefined (see
	   below).

3. ``When Sit occurs the results are undefined.''

The meaning of this terminology is:

	a. If this situation occurs, the results are unpredictable.  The
	   results may range from harmless to fatal to the running CLOS
	   system.

	b. No valid CLOS programs should cause this situation to happen.

	c. CLOS implementations are allowed to detect this situation and
	   signal an error, but no CLOS implementation is required to
	   detect the situation.

	d. No implementation is allowed to extend the semantics of CLOS to
	   this situation; the effects of the situation may be harmless,
	   but they must remain undefined.

4. ``CLOS may be extended to cover Sit.''

The meaning of this terminology is that an implementation is free to treat
Sit in one of four ways:

	a. When Sit occurs, an error is signaled;

	b. When Sit occurs, an error is signaled at least in code compiled
	   under one compiler safety optimization level and in the
	   interpreter.

	c. When Sit occurs, the results are undefined; or

	d. When Sit occurs, the results are defined and specified.

In addition, this terminology means that:

	e. No portable CLOS program can depend on the effects of this
	   situation, and all portable CLOS programs are required to treat
	   the situation as undefined.

5. ``Implementations are free to extend the syntax Syn.''

The meaning of this terminology is:

	a. Implementations are allowed to define unambiguous extensions to
	   that syntax.

The CLOS specification may disallow certain extensions while allowing others.

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

The following is a discussion of the motivation behind these terms. Of course,
there is no commitment yet to these terms: This is simply the first proposal.

The definition of a situation is designed to cover function invocations,
macro calls, and instances of the use of special forms as well as
conditions that might arise within a running CLOS system. A situation is
not a purely syntactic state of affairs, because the preconditions for an
error usually requires that something about the nature of the arguments
to a function, for example, be known. The wording of these definitions will
need further work.

On syntax, I believe we want the default to be that no extensions are
allowed - that is, any extensions must be explicitly allowed. I
particularly wish to disallow syntactic extensions that extend the number
of arguments to a function or a macro or the number of subexpressions in a
special form.

These terms are a reaction to current CLtL terminology and the various
interpretations of it. The entire gamut of interpretations of CLtL terms
is valid, but there are more interpretations than terms. This proposal is
intended to identify the reasonable interpretations of CLtL terminology
and provide terms for those intepretations, so that, I hope, the terms and
interpretations are one-to-one.

1. ``When Sit occurs an error is signaled.''

This term is borrowed from CLtL. I think we need a more precise definition
that talks about errors being signaled in code compiled under all compiler
optimization levels.  Current practice in Common Lisp includes only
signaling errors in code that was compiled under high compiler safety
optimization levels. Because there is a constant desire to elide such
checks in compiled code on stock hadware, we should separate out cases in
which we want errors signaled in code compiled under all compiler
optimization levels from those in which we allow implementations to
provide a high-speed, unsafe operations - my recollection is that CLtL
``is an error'' was intended to accomplish that separation, but that is
not the current prevailing interpretation.  Hence the term:

2. ``When Sit occurs an error should be signaled.''

Some people who interpret CLtL maintain that, under a strict reading of
CLtL, CLOS ``signals an error'' corresponds to CLtL ``signals an error''
and CLOS ``an error should be signaled'' corresponds to CLtL ``is an
error.'' This does not correspond to current practice, in which CLtL
``signals an error'' generally corresponds to CLOS ``signals an error''
or ``should signal an error,'' while CLtL ``is an error'' generally
corresponds to CLOS ``is undefined'' or ``is extendable.''

3. ``When Sit occurs the results are undefined.''

The intention of this is to allow implementations to not worry about what
happens in Sit, because CLOS does not permit programs to be written that
fall into Sit, and no implementation is allowed to extend the semantics of
CLOS to provide useful behavior in Sit. Some people have claimed that CLtL
``is an error'' corresponds to CLOS ``is undefined.''

I might expect that we would add wording to this to the effect that an
implementation may include documentation about a situation of this sort
that states that the results are harmless, but no implementation is
allowed to state what actually happens.

4. ``CLOS may be extended to cover Sit.''

This term in intended to cover yet another reading of CLtL ``is an
error,'' namely that an implementation is allowed to extend the language
to cover an otherwise erroneous situation.

5. ``Implementations are free to extend the syntax Syn.''

I believe we wish to control where extensions to CLOS are allowed to occur.
The first four terms are designed to control semantic extensions while the 
fifth is designed to control syntactic extensions, which are somewhat
different.

I believe we want to define precise terms such as these and use them
exactly in the CLOS specification so that, rather than the CLOS
specification being a pseudo-user's-guide as CLtL is, it can be a
specification suitable for an implementor.

			-rpg-