109 lines
6.1 KiB
HTML
109 lines
6.1 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3O//DTD W3 HTML 2.0//EN">
|
||
|
|
<!Converted with LaTeX2HTML 0.6.5 (Tue Nov 15 1994) by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds >
|
||
|
|
<HEAD>
|
||
|
|
<TITLE>29.2. Changes in Terminology</TITLE>
|
||
|
|
</HEAD>
|
||
|
|
<BODY>
|
||
|
|
<meta name="description" value=" Changes in Terminology">
|
||
|
|
<meta name="keywords" value="clm">
|
||
|
|
<meta name="resource-type" value="document">
|
||
|
|
<meta name="distribution" value="global">
|
||
|
|
<P>
|
||
|
|
<b>Common Lisp the Language, 2nd Edition</b>
|
||
|
|
<BR> <HR><A NAME=tex2html5605 HREF="node315.html"><IMG ALIGN=BOTTOM ALT="next" SRC="icons/next_motif.gif"></A> <A NAME=tex2html5603 HREF="node312.html"><IMG ALIGN=BOTTOM ALT="up" SRC="icons/up_motif.gif"></A> <A NAME=tex2html5597 HREF="node313.html"><IMG ALIGN=BOTTOM ALT="previous" SRC="icons/previous_motif.gif"></A> <A NAME=tex2html5607 HREF="node1.html"><IMG ALIGN=BOTTOM ALT="contents" SRC="icons/contents_motif.gif"></A> <A NAME=tex2html5608 HREF="index.html"><IMG ALIGN=BOTTOM ALT="index" SRC="icons/index_motif.gif"></A> <BR>
|
||
|
|
<B> Next:</B> <A NAME=tex2html5606 HREF="node315.html"> Survey of Concepts</A>
|
||
|
|
<B>Up:</B> <A NAME=tex2html5604 HREF="node312.html"> Conditions</A>
|
||
|
|
<B> Previous:</B> <A NAME=tex2html5598 HREF="node313.html"> Introduction</A>
|
||
|
|
<HR> <P>
|
||
|
|
<H1><A NAME=SECTION003320000000000000000>29.2. Changes in Terminology</A></H1>
|
||
|
|
<P>
|
||
|
|
<img align=bottom alt="change_begin" src="gif/change_begin.gif"><br>
|
||
|
|
In this section, we introduce changes to the terminology
|
||
|
|
defined in section <A HREF="node11.html#INTROERRORS">1.2.4</A>.
|
||
|
|
<P>
|
||
|
|
A <i>condition</i> 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.
|
||
|
|
<P>
|
||
|
|
An <i>error</i> 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).
|
||
|
|
<P>
|
||
|
|
The process by which a condition is formally announced by a program is called
|
||
|
|
<i>signaling</i>. The function <tt>signal</tt> is the primitive mechanism by which such
|
||
|
|
announcement is done. Other abstractions, such as <tt>error</tt> and <tt>cerror</tt>, are built
|
||
|
|
using <tt>signal</tt>.
|
||
|
|
<P>
|
||
|
|
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:
|
||
|
|
<UL><LI> Detecting the error might be prohibitively expensive.
|
||
|
|
<P>
|
||
|
|
For example, <tt>(+ nil 3)</tt> 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.
|
||
|
|
<P>
|
||
|
|
<LI> Some implementations might implement the behavior as an extension.
|
||
|
|
<P>
|
||
|
|
For example, <tt>(loop for x from 1 to 3 do (print x))</tt> is an error because <tt>loop</tt>
|
||
|
|
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.
|
||
|
|
<P>
|
||
|
|
[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 <A HREF="node235.html#LOOP">26</A>).-GLS]
|
||
|
|
</UL>
|
||
|
|
<P>
|
||
|
|
In this chapter, we use the following terminology.
|
||
|
|
[Compare this to the terminology presented
|
||
|
|
in section <A HREF="node262.html#ErrorTerminologySECTION">28.1.1</A>.-GLS]
|
||
|
|
<UL><LI>
|
||
|
|
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.
|
||
|
|
<P>
|
||
|
|
<LI>
|
||
|
|
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.
|
||
|
|
<P>
|
||
|
|
<LI>
|
||
|
|
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.
|
||
|
|
<P>
|
||
|
|
<LI>
|
||
|
|
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
|
||
|
|
<tt>foo</tt> has no side effects and undefined value, the expression
|
||
|
|
<tt>(length (list (foo)))</tt> is completely well defined even for portable code.
|
||
|
|
However, the effect of <tt>(print (list (foo)))</tt> is not well defined.
|
||
|
|
</UL>
|
||
|
|
<br><img align=bottom alt="change_end" src="gif/change_end.gif">
|
||
|
|
<P>
|
||
|
|
<BR> <HR><A NAME=tex2html5605 HREF="node315.html"><IMG ALIGN=BOTTOM ALT="next" SRC="icons/next_motif.gif"></A> <A NAME=tex2html5603 HREF="node312.html"><IMG ALIGN=BOTTOM ALT="up" SRC="icons/up_motif.gif"></A> <A NAME=tex2html5597 HREF="node313.html"><IMG ALIGN=BOTTOM ALT="previous" SRC="icons/previous_motif.gif"></A> <A NAME=tex2html5607 HREF="node1.html"><IMG ALIGN=BOTTOM ALT="contents" SRC="icons/contents_motif.gif"></A> <A NAME=tex2html5608 HREF="index.html"><IMG ALIGN=BOTTOM ALT="index" SRC="icons/index_motif.gif"></A> <BR>
|
||
|
|
<B> Next:</B> <A NAME=tex2html5606 HREF="node315.html"> Survey of Concepts</A>
|
||
|
|
<B>Up:</B> <A NAME=tex2html5604 HREF="node312.html"> Conditions</A>
|
||
|
|
<B> Previous:</B> <A NAME=tex2html5598 HREF="node313.html"> Introduction</A>
|
||
|
|
<HR> <P>
|
||
|
|
<HR>
|
||
|
|
<P><ADDRESS>
|
||
|
|
AI.Repository@cs.cmu.edu
|
||
|
|
</ADDRESS>
|
||
|
|
</BODY>
|