29.2 Changes in Terminology

In this section, we introduce changes to the terminology defined in section 1.2.4.

A condition is an interesting situation in a program that has been detected and announced. Later we allow this term also to refer to objects that programs use to represent such situations.

An error is a condition in which normal program execution may not continue without some form of intervention (either interactively by the user or under some sort of program control, as described below).

The process by which a condition is formally announced by a program is called signaling. The function signal is the primitive mechanism by which such announcement is done. Other abstractions, such as error and cerror, are built using signal.

The first edition is ambiguous about the reason why a particular program action “is an error.” There are two principal reasons why an action may be an error without being required to signal an error:

• Detecting the error might be prohibitively expensive.

  For example, (+ nil 3) is an error. It is likely that the designers of Common Lisp believed this would be an error in all implementations but felt it might be excessively expensive to detect the problem in compiled code on stock hardware, so they did not require that it signal an error.

• Some implementations might implement the behavior as an extension.

  For example, (loop for x from 1 to 3 do (print x)) is an error because loop is not defined to take atoms in its body. In fact, however, some implementations offer an extension that makes this well-defined. In order to leave room for such extensions, the first edition used the “is an error” terminology to keep implementors from being forced to signal an error in the extended implementations.

  [This example was written well before the vote by X3J13 in January 1989 to add exactly this extension to the forthcoming draft standard (see chapter 26).—GLS]

In this chapter, we use the following terminology. [Compare this to the terminology presented in section 28.1.1.—GLS]

• If the signaling of a condition or error is part of a function’s contract in all situations, we say that it “signals” or “must signal” that condition or error.
• If the signaling of a condition or error is optional for some important reason (such as performance), we say that the program “might signal” that condition or error. In this case, we are defining the operation to be illegal in all implementations, but allowing some implementations to fail to detect the error.
• If an action is left undefined for the sake of implementation-dependent extension, we say that it “is undefined” or “has undefined effect.” This means that it is not possible to depend portably upon the effects of that action. A program that has undefined effect may enter the debugger, transfer control, or modify data in unpredictable ways.
• In the special case where only the return value of an operation is not well defined but any side effect and transfer-of-control behavior is well defined, we say that it has “undefined value.” In this case, the number and nature of the return values is not defined, but the function can reasonably be expected to return. It is worth noting that under this description, there are some (though not many) legitimate ways in which such return value(s) can be used. For example, if the function foo has no side effects and undefined value, the expression (length (list (foo))) is completely well defined even for portable code. However, the effect of (print (list (foo))) is not well defined.