Skip to content
Browse files

initial commit of source and compiled mobi ebook

  • Loading branch information...
0 parents commit 56c2ab2feae5736456e2a8d0c12cf123c0557663 Tim Camper committed Jan 9, 2010
Sorry, we could not display the entire diff because it was too big.
6 README
@@ -0,0 +1,6 @@
+Slight reformatting of the pages at http://mitpress.mit.edu/sicp/full-text/book/book.html
+
+wget -r http://mitpress.mit.edu/sicp/full-text/book/book.html
+
+TODO: fix image at Figure 1.1, the tree diagram. (comes out darkened for some reason)
+TODO: read the damn book!
78 content/book-Z-C.css
@@ -0,0 +1,78 @@
+
+
+body {
+ color: black;
+/* background-color: #e5e5e5; */
+/* background-color: beige;*/
+background-color: white;
+ margin-top: 2em;
+ margin-left: 8%;
+ margin-right: 8%;
+}
+
+h1,h2,h3,h4,h5,h6 {
+ margin-top: .5em;
+}
+
+.partheading {
+ font-size: 70%;
+}
+
+.chapterheading {
+ font-size: 90%;
+}
+
+ol {
+ list-style-type: decimal;
+}
+
+ol ol {
+ list-style-type: lower-alpha;
+}
+
+ol ol ol {
+ list-style-type: lower-roman;
+}
+
+ol ol ol ol {
+ list-style-type: upper-alpha;
+}
+
+.footnote {
+ font-size: 75%;
+}
+
+.epigraph {
+/* text-align: right; */
+ font-size: 75%;
+ font-style: italic;
+}
+
+.attrib {
+ font-style: normal;
+}
+.figure {
+ background-color: lavender;
+}
+
+.table {
+background-color: pink;
+}
+
+.smallprint {
+ color: gray;
+ font-size: 75%;
+ text-align: right;
+}
+
+.smallprint hr {
+ text-align: left;
+ width: 40%;
+}
+
+.disable {
+ /* color: #e5e5e5; */
+color: gray;
+}
+
+
BIN content/book-Z-G-D-11.gif
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN content/book-Z-G-D-12.gif
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN content/book-Z-G-D-13.gif
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN content/book-Z-G-D-14.gif
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN content/book-Z-G-D-15.gif
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN content/book-Z-G-D-16.gif
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN content/book-Z-G-D-17.gif
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN content/book-Z-G-D-18.gif
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN content/book-Z-G-D-19.gif
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN content/book-Z-G-D-20.gif
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN content/book-Z-G-D-3.gif
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN content/book-Z-G-D-4.gif
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN content/book-Z-G-D-6.gif
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN content/book-Z-G-D-9.gif
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
69 content/book-Z-H-1.html
@@ -0,0 +1,69 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
+
+<html>
+<!-- Generated from TeX source by tex2page, v 4o,
+ (c) Dorai Sitaram, http://www.cs.rice.edu/~dorai/tex2page -->
+
+<head>
+ <meta name="generator" content="HTML Tidy for Linux (vers 7 December 2008), see www.w3.org" />
+
+ <title>Structure and Interpretation of Computer Programs</title>
+ <link href="book-Z-C.css" title="default" rel="stylesheet" type="text/css" />
+ <meta name="robots" content="noindex,follow" />
+</head>
+
+<body>
+ <mbp:pagebreak />
+
+ <p><a name="titlepage" id="titlepage"></a>
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</p>
+
+ <h1>Structure and Interpretation<br />
+ of Computer Programs</h1>
+
+ <div align="left">
+ second edition&nbsp;
+ </div>
+
+ <p><br /></p>
+
+ <p><br /></p>
+
+ <p><br /></p>
+
+ <p><br /></p>
+
+ <div align="left">
+ Harold Abelson and Gerald Jay Sussman<br />
+ with Julie Sussman&nbsp;
+ </div>
+
+ <div align="left">
+ foreword by Alan J. Perlis&nbsp;
+ </div>
+
+ <p><br /></p>
+
+ <p><br /></p>
+
+ <p><br /></p>
+
+ <p><br /></p>
+
+ <p><br /></p>
+
+ <p><br /></p>
+
+ <div align="left">
+ The MIT Press<br />
+ Cambridge, Massachusetts &nbsp;&nbsp;&nbsp; London, England
+
+ <p>McGraw-Hill Book Company<br />
+ New York &nbsp;&nbsp;&nbsp; St. Louis &nbsp;&nbsp;&nbsp; San
+ Francisco &nbsp;&nbsp;&nbsp; Montreal &nbsp;&nbsp;&nbsp;
+ Toronto&nbsp;</p>
+ </div>
+
+
+</body>
+</html>
1,653 content/book-Z-H-10.html
@@ -0,0 +1,1653 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
+
+<html>
+<!-- Generated from TeX source by tex2page, v 4o,
+ (c) Dorai Sitaram, http://www.cs.rice.edu/~dorai/tex2page -->
+
+<head>
+ <meta name="generator" content="HTML Tidy for Linux (vers 7 December 2008), see www.w3.org" />
+
+ <title>Structure and Interpretation of Computer Programs</title>
+ <link href="book-Z-C.css" title="default" rel="stylesheet" type="text/css" />
+ <meta name="robots" content="noindex,follow" />
+</head>
+
+<body>
+ <mbp:pagebreak />
+
+ <p><a name="%_sec_1.1"></a></p>
+
+ <h2><a href="book-Z-H-4.html#%_toc_%_sec_1.1">1.1&nbsp;&nbsp;The
+ Elements of Programming</a></h2>
+
+ <p><a name="%_idx_118"></a> A powerful programming language is
+ more than just a means for instructing a computer to perform
+ tasks. The language also serves as a framework within which we
+ organize our ideas about processes. Thus, when we describe a
+ language, we should pay particular attention to the means that
+ the language provides for combining simple ideas to form more
+ complex ideas. Every powerful language has three mechanisms for
+ accomplishing this:</p>
+
+ <ul>
+ <li>
+ <strong>primitive expressions</strong>, which represent the
+ simplest entities the language is concerned with,
+
+ <p><a name="%_idx_122"></a><a name="%_idx_124"></a></p>
+ </li>
+
+ <li>
+ <strong>means of combination</strong>, by which compound
+ elements are built from simpler ones, and
+
+ <p><a name="%_idx_126"></a></p>
+ </li>
+
+ <li><strong>means of abstraction</strong>, by which compound
+ elements can be named and manipulated as units.</li>
+ </ul>
+
+ <p>In programming, we deal with two kinds of elements: <a name="%_idx_128"></a>procedures and <a name="%_idx_130"></a>data.
+ (Later we will discover that they are really not so distinct.)
+ Informally, data is ``stuff'' that we want to manipulate, and
+ procedures are descriptions of the rules for manipulating the
+ data. Thus, any powerful programming language should be able to
+ describe primitive data and primitive procedures and should have
+ methods for combining and abstracting procedures and data.</p>
+
+ <p>In this chapter we will deal only with simple <a name="%_idx_132"></a><a name="%_idx_134"></a>numerical data so that we
+ can focus on the rules for building procedures.<a href="#footnote_Temp_10" name="call_footnote_Temp_10" id="call_footnote_Temp_10"><sup><small>4</small></sup></a> In later
+ chapters we will see that these same rules allow us to build
+ procedures to manipulate compound data as well.</p>
+
+ <p><a name="%_sec_1.1.1"></a></p>
+
+ <h3><a href="book-Z-H-4.html#%_toc_%_sec_1.1.1">1.1.1&nbsp;&nbsp;Expressions</a></h3>
+
+ <p>One easy way to get started at programming is to examine some
+ typical interactions with an interpreter for the Scheme dialect
+ of Lisp. Imagine that you are sitting at a computer terminal. You
+ type an <em>expression</em>, and the interpreter responds by
+ displaying the result of its <em>evaluating</em> that
+ expression.</p>
+
+ <p><a name="%_idx_148"></a><a name="%_idx_150"></a>One kind of
+ primitive expression you might type is a number. (More precisely,
+ the expression that you type consists of the numerals that
+ represent the number in base 10.) If you present Lisp with a
+ number</p>
+
+ <p><tt>486<br /></tt></p>
+
+ <p>the interpreter will respond by printing<a href="#footnote_Temp_11" name="call_footnote_Temp_11" id="call_footnote_Temp_11"><sup><small>5</small></sup></a></p>
+
+ <p><tt><i>486</i><br /></tt></p>
+
+ <p><a name="%_idx_154"></a><a name="%_idx_156"></a>Expressions
+ representing numbers may be combined with an <a name="%_idx_158"></a>expression representing a <a name="%_idx_160"></a><a name="%_idx_162"></a><a name="%_idx_164"></a><a name="%_idx_166"></a><a name="%_idx_168"></a>primitive procedure (such as <tt>+</tt> or
+ <tt>*</tt>) to form a compound expression that represents the
+ application of the procedure to those numbers. For example:</p>
+
+ <p><tt>(+&nbsp;137&nbsp;349)<br />
+ <i>486</i><br />
+ <a name="%_idx_170"></a><a name="%_idx_172"></a>(-&nbsp;1000&nbsp;334)<br />
+ <i>666</i><br />
+ (*&nbsp;5&nbsp;99)<br />
+ <i>495</i><br />
+ <a name="%_idx_174"></a><a name="%_idx_176"></a>(/&nbsp;10&nbsp;5)<br />
+ <i>2</i><br />
+ (+&nbsp;2.7&nbsp;10)<br />
+ <i>12.7</i><br /></tt></p>
+
+ <p>Expressions such as these, formed by <a name="%_idx_178"></a>delimiting a list of expressions within
+ parentheses in order to denote <a name="%_idx_180"></a>procedure
+ application, are called <em>combinations</em>. The leftmost
+ element in the list is called the <a name="%_idx_182"></a><em>operator</em>, and the other elements are
+ called <a name="%_idx_184"></a><em>operands</em>. The <a name="%_idx_186"></a>value of a combination is obtained by applying
+ the procedure specified by the operator to the <a name="%_idx_188"></a><em>arguments</em> that are the values of the
+ operands.</p>
+
+ <p>The convention of placing the operator to the left of the
+ operands is known as <a name="%_idx_190"></a><em>prefix
+ notation</em>, and it may be somewhat confusing at first because
+ it departs significantly from the customary mathematical
+ convention. Prefix notation has several advantages, however. One
+ of them is that it can accommodate <a name="%_idx_192"></a><a name="%_idx_194"></a>procedures that may take
+ an arbitrary number of arguments, as in the following
+ examples:</p>
+
+ <p><tt>(+&nbsp;21&nbsp;35&nbsp;12&nbsp;7)<br />
+ <i>75</i><br />
+ <br />
+ (*&nbsp;25&nbsp;4&nbsp;12)<br />
+ <i>1200</i><br /></tt></p>
+
+ <p>No ambiguity can arise, because the operator is always the
+ leftmost element and the entire combination is delimited by the
+ parentheses.</p>
+
+ <p><a name="%_idx_196"></a>A second advantage of prefix notation
+ is that it extends in a straightforward way to allow combinations
+ to be <em>nested</em>, that is, to have combinations whose
+ elements are themselves combinations:</p>
+
+ <p><tt>(+&nbsp;(*&nbsp;3&nbsp;5)&nbsp;(-&nbsp;10&nbsp;6))<br />
+ <i>19</i><br /></tt></p>
+
+ <p>There is no limit (in principle) to the depth of such nesting
+ and to the overall complexity of the expressions that the Lisp
+ interpreter can evaluate. It is we humans who get confused by
+ still relatively simple expressions such as</p>
+
+ <p>
+ <tt>(+&nbsp;(*&nbsp;3&nbsp;(+&nbsp;(*&nbsp;2&nbsp;4)&nbsp;(+&nbsp;3&nbsp;5)))&nbsp;(+&nbsp;(-&nbsp;10&nbsp;7)&nbsp;6))<br />
+ </tt></p>
+
+ <p>which the interpreter would readily evaluate to be 57. We can
+ help ourselves by writing such an expression in the form</p>
+
+ <p><tt>(+&nbsp;(*&nbsp;3<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(+&nbsp;(*&nbsp;2&nbsp;4)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(+&nbsp;3&nbsp;5)))<br />
+
+ &nbsp;&nbsp;&nbsp;(+&nbsp;(-&nbsp;10&nbsp;7)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6))<br /></tt></p>
+
+ <p>following a formatting convention known as <a name="%_idx_198"></a><em>pretty-printing</em>, in which each long
+ combination is written so that the operands are aligned
+ vertically. The resulting indentations display clearly the
+ structure of the expression.<a href="#footnote_Temp_12" name="call_footnote_Temp_12" id="call_footnote_Temp_12"><sup><small>6</small></sup></a></p>
+
+ <p>Even with complex expressions, the interpreter always operates
+ in the same basic cycle: It reads an expression from the
+ terminal, evaluates the expression, and prints the result. This
+ mode of operation is often expressed by saying that the
+ interpreter runs in a <a name="%_idx_204"></a><a name="%_idx_206"></a><em>read-eval-print loop</em>. Observe in
+ particular that it is not necessary to explicitly instruct the
+ interpreter to print the value of the expression.<a href="#footnote_Temp_13" name="call_footnote_Temp_13" id="call_footnote_Temp_13"><sup><small>7</small></sup></a></p>
+
+ <p><a name="%_sec_1.1.2"></a></p>
+
+ <h3><a href="book-Z-H-4.html#%_toc_%_sec_1.1.2">1.1.2&nbsp;&nbsp;Naming and
+ the Environment</a></h3>
+
+ <p>A critical aspect of a programming language is the means it
+ provides for using <a name="%_idx_216"></a>names to refer to
+ computational objects. We say that the <a name="%_idx_218"></a>name identifies a <a name="%_idx_220"></a><em>variable</em> whose <a name="%_idx_222"></a><em>value</em> is the object.</p>
+
+ <p>In the Scheme dialect of Lisp, we name things with <a name="%_idx_224"></a><a name="%_idx_226"></a><tt>define</tt>.
+ Typing</p>
+
+ <p><tt>(define&nbsp;size&nbsp;2)<br /></tt></p>
+
+ <p>causes the interpreter to associate the value 2 with the name
+ <tt>size</tt>.<a href="#footnote_Temp_14" name="call_footnote_Temp_14" id="call_footnote_Temp_14"><sup><small>8</small></sup></a> Once the
+ name <tt>size</tt> has been associated with the number 2, we can
+ refer to the value 2 by name:</p>
+
+ <p><tt>size<br />
+ <i>2</i><br />
+ (*&nbsp;5&nbsp;size)<br />
+ <i>10</i><br /></tt></p>
+
+ <p>Here are further examples of the use of <tt>define</tt>:</p>
+
+ <p><tt>(define&nbsp;pi&nbsp;3.14159)<br />
+ (define&nbsp;radius&nbsp;10)<br />
+ (*&nbsp;pi&nbsp;(*&nbsp;radius&nbsp;radius))<br />
+ <i>314.159</i><br />
+ (define&nbsp;circumference&nbsp;(*&nbsp;2&nbsp;pi&nbsp;radius))<br />
+
+ circumference<br />
+ <i>62.8318</i><br /></tt></p>
+
+ <p><a name="%_idx_232"></a><tt>Define</tt> is our language's
+ simplest means of abstraction, for it allows us to use simple
+ names to refer to the results of compound operations, such as the
+ <tt>circumference</tt> computed above. In general, computational
+ objects may have very complex structures, and it would be
+ extremely inconvenient to have to remember and repeat their
+ details each time we want to use them. Indeed, complex programs
+ are constructed by building, step by step, computational objects
+ of increasing complexity. The interpreter makes this step-by-step
+ program construction particularly convenient because name-object
+ associations can be created incrementally in successive
+ interactions. This feature encourages the <a name="%_idx_234"></a><a name="%_idx_236"></a>incremental development
+ and testing of programs and is largely responsible for the fact
+ that <a name="%_idx_238"></a>a Lisp program usually consists of a
+ large number of relatively simple procedures.</p>
+
+ <p>It should be clear that the possibility of associating values
+ with symbols and later retrieving them means that the interpreter
+ must maintain some sort of memory that keeps track of the
+ name-object pairs. This memory is called the <a name="%_idx_240"></a><em>environment</em> (more precisely the <a name="%_idx_242"></a><em>global environment</em>, since we will see
+ later that a computation may involve a number of different
+ environments).<a href="#footnote_Temp_15" name="call_footnote_Temp_15" id="call_footnote_Temp_15"><sup><small>9</small></sup></a></p>
+
+ <p><a name="%_sec_1.1.3"></a></p>
+
+ <h3><a href="book-Z-H-4.html#%_toc_%_sec_1.1.3">1.1.3&nbsp;&nbsp;Evaluating
+ Combinations</a></h3>
+
+ <p><a name="%_idx_244"></a><a name="%_idx_246"></a> One of our
+ goals in this chapter is to isolate issues about thinking
+ procedurally. As a case in point, let us consider that, in
+ evaluating combinations, the interpreter is itself following a
+ procedure.</p>
+
+ <ul>
+ <li>To evaluate a combination, do the following:</li>
+ </ul>
+
+ <blockquote>
+ <p>1.&nbsp;&nbsp;Evaluate the subexpressions of the
+ combination.</p>
+
+ <p>2.&nbsp;&nbsp;Apply the procedure that is the value of the
+ leftmost subexpression (the operator) to the arguments that are
+ the values of the other subexpressions (the operands).</p>
+ </blockquote>
+
+ <p>Even this simple rule illustrates some important points about
+ processes in general. First, observe that the first step dictates
+ that in order to accomplish the evaluation process for a
+ combination we must first perform the evaluation process on each
+ element of the combination. Thus, the evaluation rule is <a name="%_idx_248"></a><em>recursive</em> in nature; that is, it
+ includes, as one of its steps, the need to invoke the rule
+ itself.<a href="#footnote_Temp_16" name="call_footnote_Temp_16" id="call_footnote_Temp_16"><sup><small>10</small></sup></a></p>
+
+ <p><a name="%_idx_250"></a>Notice how succinctly the idea of
+ recursion can be used to express what, in the case of a deeply
+ nested combination, would otherwise be viewed as a rather
+ complicated process. For example, evaluating</p>
+
+ <p><tt>(*&nbsp;(+&nbsp;2&nbsp;(*&nbsp;4&nbsp;6))<br />
+ &nbsp;&nbsp;&nbsp;(+&nbsp;3&nbsp;5&nbsp;7))<br /></tt></p>
+
+ <p>requires that the evaluation rule be applied to four different
+ combinations. We can obtain a picture of this process by <a name="%_idx_252"></a>representing the combination in the form of a
+ <a name="%_idx_254"></a>tree, as shown in figure&nbsp;<a href="#%_fig_1.1">1.1</a>. Each combination is represented by a
+ <a name="%_idx_256"></a>node with <a name="%_idx_258"></a>branches corresponding to the operator and the
+ operands of the combination stemming from it. The <a name="%_idx_260"></a>terminal nodes (that is, nodes with no branches
+ stemming from them) represent either operators or numbers.
+ Viewing evaluation in terms of the tree, we can imagine that the
+ values of the operands percolate upward, starting from the
+ terminal nodes and then combining at higher and higher levels. In
+ general, we shall see that recursion is a very powerful technique
+ for dealing with hierarchical, treelike objects. In fact, the
+ ``percolate values upward'' form of the evaluation rule is an
+ example of a general kind of process known as <a name="%_idx_262"></a><em>tree accumulation</em>.</p>
+
+ <p><a name="%_fig_1.1"></a></p>
+
+ <div align="left">
+ <div align="left">
+ <b>Figure 1.1:</b>&nbsp;&nbsp;Tree representation, showing
+ the value of each subcombination.
+ </div>
+
+ <table width="100%">
+ <tr>
+ <td><img src="ch1-Z-G-1.gif" border="0" /></td>
+ </tr>
+
+ <tr>
+ <td></td>
+ </tr>
+ </table>
+ </div>
+
+ <p>Next, observe that the repeated application of the first step
+ brings us to the point where we need to evaluate, not
+ combinations, but primitive expressions such as numerals,
+ built-in operators, or other names. We take care of the primitive
+ cases by stipulating that</p>
+
+ <p><a name="%_idx_264"></a><a name="%_idx_266"></a></p>
+
+ <ul>
+ <li>the values of numerals are the numbers that they name,</li>
+
+ <li>the values of built-in operators are the machine
+ instruction sequences that carry out the corresponding
+ operations, and</li>
+
+ <li>the values of other names are the objects associated with
+ those names in the environment.</li>
+ </ul>
+
+ <p>We may regard the second rule as a special case of the third
+ one by stipulating that symbols such as <tt>+</tt> and <tt>*</tt>
+ are also included in the global environment, and are associated
+ with the sequences of machine instructions that are their
+ ``values.'' The key point to notice is the role of the <a name="%_idx_268"></a>environment in determining the meaning of the
+ symbols in expressions. In an interactive language such as Lisp,
+ it is meaningless to speak of the value of an expression such as
+ <tt>(+ x 1)</tt> without specifying any information about the
+ environment that would provide a meaning for the
+ symbol&nbsp;<tt>x</tt> (or even for the symbol <tt>+</tt>). As we
+ shall see in chapter&nbsp;3, the general notion of the
+ environment as providing a context in which evaluation takes
+ place will play an important role in our understanding of program
+ execution.</p>
+
+ <p><a name="%_idx_270"></a>Notice that the evaluation rule given
+ above does not handle definitions. For instance, evaluating
+ <tt>(define x 3)</tt> does not apply <tt>define</tt> to two
+ arguments, one of which is the value of the symbol <tt>x</tt> and
+ the other of which is 3, since the purpose of the <tt>define</tt>
+ is precisely to associate <tt>x</tt> with a value. (That is,
+ <tt>(define x 3)</tt> is not a combination.)</p>
+
+ <p><a name="%_idx_272"></a>Such exceptions to the general
+ evaluation rule are called <em>special forms</em>.
+ <tt>Define</tt> is the only example of a special form that we
+ have seen so far, but we will meet others shortly. <a name="%_idx_274"></a>Each special form has its own evaluation rule.
+ The various kinds of expressions (each with its associated
+ evaluation rule) constitute the <a name="%_idx_276"></a>syntax of
+ the programming language. In comparison with most other
+ programming languages, Lisp has a very simple syntax; that is,
+ the evaluation rule for expressions can be described by a simple
+ general rule together with specialized rules for a small number
+ of special forms.<a href="#footnote_Temp_17" name="call_footnote_Temp_17" id="call_footnote_Temp_17"><sup><small>11</small></sup></a></p>
+
+ <p><a name="%_sec_1.1.4"></a></p>
+
+ <h3><a href="book-Z-H-4.html#%_toc_%_sec_1.1.4">1.1.4&nbsp;&nbsp;Compound
+ Procedures</a></h3>
+
+ <p>We have identified in Lisp some of the elements that must
+ appear in any powerful programming language:</p>
+
+ <ul>
+ <li>Numbers and arithmetic operations are primitive data and
+ procedures.</li>
+
+ <li>Nesting of combinations provides a means of combining
+ operations.</li>
+
+ <li>Definitions that associate names with values provide a
+ limited means of abstraction.</li>
+ </ul>
+
+ <p>Now we will learn about <a name="%_idx_292"></a><em>procedure
+ definitions</em>, a much more powerful abstraction technique by
+ which a compound operation can be given a name and then referred
+ to as a unit.</p>
+
+ <p>We begin by examining how to express the idea of ``squaring.''
+ We might say, ``To square something, multiply it by itself.''
+ This is expressed in our language as</p>
+
+ <p><tt><a name="%_idx_294"></a>(define&nbsp;(square&nbsp;x)&nbsp;(*&nbsp;x&nbsp;x))<br />
+ </tt></p>
+
+ <p>We can understand this in the following way:</p>
+
+ <p>
+ <tt>(define&nbsp;(square&nbsp;&nbsp;x)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x))<br />
+
+ &nbsp;&nbsp;&nbsp;<img src="book-Z-G-D-16.gif" border="0" />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<img src="book-Z-G-D-16.gif" border="0" />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<img src="book-Z-G-D-16.gif" border="0" />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<img src="book-Z-G-D-16.gif" border="0" />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<img src="book-Z-G-D-16.gif" border="0" />&nbsp;&nbsp;&nbsp;&nbsp;<img src="book-Z-G-D-16.gif" border="0" /><br />
+ &nbsp;To&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;square&nbsp;something,&nbsp;multiply&nbsp;&nbsp;&nbsp;it&nbsp;by&nbsp;itself.<br />
+ </tt></p>
+
+ <p><a name="%_idx_296"></a><a name="%_idx_298"></a>We have here a
+ <em>compound procedure</em>, which has been given the name
+ <tt>square</tt>. The procedure represents the operation of
+ multiplying something by itself. The thing to be multiplied is
+ given a local name, <tt>x</tt>, which plays the same role that a
+ pronoun plays in natural language. <a name="%_idx_300"></a><a name="%_idx_302"></a><a name="%_idx_304"></a>Evaluating the definition creates this compound
+ procedure and associates it with the name
+ <tt>square</tt>.<a href="#footnote_Temp_18" name="call_footnote_Temp_18" id="call_footnote_Temp_18"><sup><small>12</small></sup></a></p>
+
+ <p><a name="%_idx_306"></a><a name="%_idx_308"></a>The general
+ form of a procedure definition is</p>
+
+ <p>
+ <tt>(define&nbsp;(&lt;<em>name</em>&gt;&nbsp;&lt;<em>formal&nbsp;parameters</em>&gt;)&nbsp;&lt;<em>body</em>&gt;)<br />
+ </tt></p>
+
+ <p><a name="%_idx_310"></a><a name="%_idx_312"></a>The
+ &lt;<em>name</em>&gt; is a symbol to be associated with the
+ procedure definition in the environment.<a href="#footnote_Temp_19" name="call_footnote_Temp_19" id="call_footnote_Temp_19"><sup><small>13</small></sup></a> The
+ <a name="%_idx_318"></a><a name="%_idx_320"></a>&lt;<em>formal
+ parameters</em>&gt; are the names used within the body of the
+ procedure to refer to the corresponding arguments of the
+ procedure. The <a name="%_idx_322"></a><a name="%_idx_324"></a>&lt;<em>body</em>&gt; is an expression that will
+ yield the value of the procedure application when the formal
+ parameters are replaced by the actual arguments to which the
+ procedure is applied.<a href="#footnote_Temp_20" name="call_footnote_Temp_20" id="call_footnote_Temp_20"><sup><small>14</small></sup></a> The
+ &lt;<em>name</em>&gt; and the &lt;<em>formal parameters</em>&gt;
+ are grouped within <a name="%_idx_328"></a>parentheses, just as
+ they would be in an actual call to the procedure being
+ defined.</p>
+
+ <p>Having defined <tt>square</tt>, we can now use it:</p>
+
+ <p><tt>(square&nbsp;21)<br />
+ <i>441</i><br />
+ <br />
+ (square&nbsp;(+&nbsp;2&nbsp;5))<br />
+ <i>49</i><br />
+ <br />
+ (square&nbsp;(square&nbsp;3))<br />
+ <i>81</i><br /></tt></p>
+
+ <p>We can also use <tt>square</tt> as a building block in
+ defining other procedures. For example, <em>x</em><sup>2</sup> +
+ <em>y</em><sup>2</sup> can be expressed as</p>
+
+ <p><tt>(+&nbsp;(square&nbsp;x)&nbsp;(square&nbsp;y))<br /></tt></p>
+
+ <p>We can easily define a procedure <tt>sum-of-squares</tt> that,
+ given any two numbers as arguments, produces the sum of their
+ squares:</p>
+
+ <p><tt><a name="%_idx_330"></a>(define&nbsp;(sum-of-squares&nbsp;x&nbsp;y)<br />
+ &nbsp;&nbsp;(+&nbsp;(square&nbsp;x)&nbsp;(square&nbsp;y)))<br />
+ <br />
+ (sum-of-squares&nbsp;3&nbsp;4)<br />
+ <i>25</i><br /></tt></p>
+
+ <p>Now we can use <tt>sum-of-squares</tt> as a building block in
+ constructing further procedures:</p>
+
+ <p><tt>(define&nbsp;(f&nbsp;a)<br />
+ &nbsp;&nbsp;(sum-of-squares&nbsp;(+&nbsp;a&nbsp;1)&nbsp;(*&nbsp;a&nbsp;2)))<br />
+
+ <br />
+ (f&nbsp;5)<br />
+ <i>136</i><br /></tt></p>
+
+ <p><a name="%_idx_332"></a>Compound procedures are used in
+ exactly the same way as primitive procedures. Indeed, one could
+ not tell by looking at the definition of <tt>sum-of-squares</tt>
+ given above whether <tt>square</tt> was built into the
+ interpreter, like <tt>+</tt> and <tt>*</tt>, or defined as a
+ compound procedure.</p>
+
+ <p><a name="%_sec_1.1.5"></a></p>
+
+ <h3><a href="book-Z-H-4.html#%_toc_%_sec_1.1.5">1.1.5&nbsp;&nbsp;The
+ Substitution Model for Procedure Application</a></h3>
+
+ <p><a name="%_idx_334"></a> To evaluate a combination whose
+ operator names a compound procedure, the interpreter follows much
+ the same process as for combinations whose operators name
+ primitive procedures, which we described in section&nbsp;<a href="#%_sec_1.1.3">1.1.3</a>. That is, the interpreter evaluates the
+ elements of the combination and applies the procedure (which is
+ the value of the operator of the combination) to the arguments
+ (which are the values of the operands of the combination).</p>
+
+ <p>We can assume that the mechanism for applying primitive
+ procedures to arguments is built into the interpreter. For
+ compound procedures, the application process is as follows:</p>
+
+ <ul>
+ <li>To apply a compound procedure to arguments, evaluate the
+ body of the procedure with each formal parameter replaced by
+ the corresponding argument.</li>
+ </ul>
+
+ <p>To illustrate this process, let's evaluate the combination</p>
+
+ <p><tt>(f&nbsp;5)<br /></tt></p>
+
+ <p>where <tt>f</tt> is the procedure defined in
+ section&nbsp;<a href="#%_sec_1.1.4">1.1.4</a>. We begin by
+ retrieving the body of <tt>f</tt>:</p>
+
+ <p>
+ <tt>(sum-of-squares&nbsp;(+&nbsp;a&nbsp;1)&nbsp;(*&nbsp;a&nbsp;2))<br />
+ </tt></p>
+
+ <p>Then we replace the formal parameter <tt>a</tt> by the
+ argument 5:</p>
+
+ <p>
+ <tt>(sum-of-squares&nbsp;(+&nbsp;5&nbsp;1)&nbsp;(*&nbsp;5&nbsp;2))<br />
+ </tt></p>
+
+ <p>Thus the problem reduces to the evaluation of a combination
+ with two operands and an operator <tt>sum-of-squares</tt>.
+ Evaluating this combination involves three subproblems. We must
+ evaluate the operator to get the procedure to be applied, and we
+ must evaluate the operands to get the arguments. Now <tt>(+ 5
+ 1)</tt> produces 6 and <tt>(* 5 2)</tt> produces 10, so we must
+ apply the <tt>sum-of-squares</tt> procedure to 6 and 10. These
+ values are substituted for the formal parameters <tt>x</tt> and
+ <tt>y</tt> in the body of <tt>sum-of-squares</tt>, reducing the
+ expression to</p>
+
+ <p>
+ <tt>(+&nbsp;(square&nbsp;6)&nbsp;(square&nbsp;10))<br /></tt></p>
+
+ <p>If we use the definition of <tt>square</tt>, this reduces
+ to</p>
+
+ <p>
+ <tt>(+&nbsp;(*&nbsp;6&nbsp;6)&nbsp;(*&nbsp;10&nbsp;10))<br /></tt></p>
+
+ <p>which reduces by multiplication to</p>
+
+ <p><tt>(+&nbsp;36&nbsp;100)<br /></tt></p>
+
+ <p>and finally to</p>
+
+ <p><tt>136<br /></tt></p>
+
+ <p>The process we have just described is called the
+ <em>substitution model</em> for procedure application. It can be
+ taken as a model that determines the ``meaning'' of procedure
+ application, insofar as the procedures in this chapter are
+ concerned. However, there are two points that should be
+ stressed:</p>
+
+ <ul>
+ <li>The purpose of the substitution is to help us think about
+ procedure application, not to provide a description of how the
+ interpreter really works. Typical interpreters do not evaluate
+ procedure applications by manipulating the text of a procedure
+ to substitute values for the formal parameters. In practice,
+ the ``substitution'' is accomplished by using a local
+ environment for the formal parameters. We will discuss this
+ more fully in chapters 3 and 4 when we examine the
+ implementation of an interpreter in detail.</li>
+
+ <li>Over the course of this book, we will present a sequence of
+ increasingly elaborate models of how interpreters work,
+ culminating with a complete implementation of an interpreter
+ and compiler in chapter&nbsp;5. The substitution model is only
+ the first of these models -- a way to get started thinking
+ formally about the evaluation process. In general, when
+ <a name="%_idx_336"></a>modeling phenomena in science and
+ engineering, we begin with simplified, incomplete models. As we
+ examine things in greater detail, these simple models become
+ inadequate and must be replaced by more refined models. The
+ substitution model is no exception. In particular, when we
+ address in chapter&nbsp;3 the use of procedures with ``mutable
+ data,'' we will see that the substitution model breaks down and
+ must be replaced by a more complicated model of procedure
+ application.<a href="#footnote_Temp_21" name="call_footnote_Temp_21" id="call_footnote_Temp_21"><sup><small>15</small></sup></a></li>
+ </ul>
+
+ <p><a name="%_sec_Temp_22"></a></p>
+
+ <h4><a href="book-Z-H-4.html#%_toc_%_sec_Temp_22">Applicative
+ order versus normal order</a></h4>
+
+ <p>According to the description of evaluation given in
+ section&nbsp;<a href="#%_sec_1.1.3">1.1.3</a>, the interpreter
+ first evaluates the operator and operands and then applies the
+ resulting procedure to the resulting arguments. This is not the
+ only way to perform evaluation. An alternative evaluation model
+ would not evaluate the operands until their values were needed.
+ Instead it would first substitute operand expressions for
+ parameters until it obtained an expression involving only
+ primitive operators, and would then perform the evaluation. If we
+ used this method, the evaluation of</p>
+
+ <p><tt>(f&nbsp;5)<br /></tt></p>
+
+ <p>would proceed according to the sequence of expansions</p>
+
+ <p>
+ <tt>(sum-of-squares&nbsp;(+&nbsp;5&nbsp;1)&nbsp;(*&nbsp;5&nbsp;2))<br />
+
+ <br />
+ (+&nbsp;&nbsp;&nbsp;&nbsp;(square&nbsp;(+&nbsp;5&nbsp;1))&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(square&nbsp;(*&nbsp;5&nbsp;2))&nbsp;&nbsp;)<br />
+
+ <br />
+ (+&nbsp;&nbsp;&nbsp;&nbsp;(*&nbsp;(+&nbsp;5&nbsp;1)&nbsp;(+&nbsp;5&nbsp;1))&nbsp;&nbsp;&nbsp;(*&nbsp;(*&nbsp;5&nbsp;2)&nbsp;(*&nbsp;5&nbsp;2)))<br />
+ </tt></p>
+
+ <p>followed by the reductions</p>
+
+ <p>
+ <tt>(+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(*&nbsp;6&nbsp;6)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(*&nbsp;10&nbsp;10))<br />
+
+ <br />
+ (+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;36&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;100)<br />
+
+ <br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;136<br />
+ </tt></p>
+
+ <p>This gives the same answer as our previous evaluation model,
+ but the process is different. In particular, the evaluations of
+ <tt>(+ 5 1)</tt> and <tt>(*&nbsp;5&nbsp;2)</tt> are each
+ performed twice here, corresponding to the reduction of the
+ expression</p>
+
+ <p><tt>(*&nbsp;x&nbsp;x)<br /></tt></p>
+
+ <p>with <tt>x</tt> replaced respectively by <tt>(+ 5 1)</tt> and
+ <tt>(* 5 2)</tt>.</p>
+
+ <p>This alternative ``fully expand and then reduce'' evaluation
+ method is known as <a name="%_idx_340"></a><em>normal-order
+ evaluation</em>, in contrast to the ``evaluate the arguments and
+ then apply'' method that the interpreter actually uses, which is
+ called <a name="%_idx_342"></a><em>applicative-order
+ evaluation</em>. It can be shown that, for procedure applications
+ that can be modeled using substitution (including all the
+ procedures in the first two chapters of this book) and that yield
+ legitimate values, normal-order and applicative-order evaluation
+ produce the same value. (See exercise&nbsp;<a href="#%_thm_1.5">1.5</a> for an instance of an ``illegitimate'' value
+ where normal-order and applicative-order evaluation do not give
+ the same result.)</p>
+
+ <p><a name="%_idx_344"></a><a name="%_idx_346"></a>Lisp uses
+ applicative-order evaluation, partly because of the additional
+ efficiency obtained from avoiding multiple evaluations of
+ expressions such as those illustrated with <tt>(+ 5 1)</tt> and
+ <tt>(* 5 2)</tt> above and, more significantly, because
+ normal-order evaluation becomes much more complicated to deal
+ with when we leave the realm of procedures that can be modeled by
+ substitution. On the other hand, normal-order evaluation can be
+ an extremely valuable tool, and we will investigate some of its
+ implications in chapters 3 and 4.<a href="#footnote_Temp_23" name="call_footnote_Temp_23" id="call_footnote_Temp_23"><sup><small>16</small></sup></a></p>
+
+ <p><a name="%_sec_1.1.6"></a></p>
+
+ <h3><a href="book-Z-H-4.html#%_toc_%_sec_1.1.6">1.1.6&nbsp;&nbsp;Conditional
+ Expressions and Predicates</a></h3>
+
+ <p>The expressive power of the class of procedures that we can
+ define at this point is very limited, because we have no way to
+ make tests and to perform different operations depending on the
+ result of a test. For instance, we cannot define a procedure that
+ computes the <a name="%_idx_348"></a>absolute value of a number
+ by testing whether the number is positive, negative, or zero and
+ taking different actions in the different cases according to the
+ rule</p>
+
+ <div align="left"><img src="ch1-Z-G-2.gif" border="0" /></div>
+
+ <p><a name="%_idx_350"></a>This construct is called a <em>case
+ analysis</em>, and there is a special form in Lisp for notating
+ such a case analysis. It is called <a name="%_idx_352"></a><a name="%_idx_354"></a><a name="%_idx_356"></a><tt>cond</tt> (which stands for ``conditional''),
+ and it is used as follows:</p>
+
+ <p><tt><a name="%_idx_358"></a>(define&nbsp;(abs&nbsp;x)<br />
+ &nbsp;&nbsp;(cond&nbsp;((&gt;&nbsp;x&nbsp;0)&nbsp;x)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;((=&nbsp;x&nbsp;0)&nbsp;0)<br />
+
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;((&lt;&nbsp;x&nbsp;0)&nbsp;(-&nbsp;x))))<br />
+ </tt></p>
+
+ <p>The general form of a conditional expression is</p>
+
+ <p>
+ <tt>(cond&nbsp;(&lt;<em>p<sub>1</sub></em>&gt;&nbsp;&lt;<em>e<sub>1</sub></em>&gt;)<br />
+
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&lt;<em>p<sub>2</sub></em>&gt;&nbsp;&lt;<em>e<sub>2</sub></em>&gt;)<br />
+
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<img src="book-Z-G-D-18.gif" border="0" /><br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&lt;<em>p<sub><em>n</em></sub></em>&gt;&nbsp;&lt;<em>e<sub><em>n</em></sub></em>&gt;))<br />
+ </tt></p>
+
+ <p>consisting of the symbol <tt>cond</tt> followed by <a name="%_idx_360"></a>parenthesized pairs of expressions
+ <tt>(&lt;<em>p</em>&gt;&nbsp;&lt;<em>e</em>&gt;)</tt> called
+ <a name="%_idx_362"></a><a name="%_idx_364"></a><em>clauses</em>.
+ The first expression in each pair is a <a name="%_idx_366"></a><em>predicate</em> -- that is, an expression
+ whose value is interpreted as either true or false.<a href="#footnote_Temp_24" name="call_footnote_Temp_24" id="call_footnote_Temp_24"><sup><small>17</small></sup></a></p>
+
+ <p><a name="%_idx_384"></a><a name="%_idx_386"></a>Conditional
+ expressions are evaluated as follows. The predicate
+ &lt;<em>p<sub>1</sub></em>&gt; is evaluated first. If its value
+ is false, then &lt;<em>p<sub>2</sub></em>&gt; is evaluated. If
+ &lt;<em>p<sub>2</sub></em>&gt;'s value is also false, then
+ &lt;<em>p<sub>3</sub></em>&gt; is evaluated. This process
+ continues until a predicate is found whose value is true, in
+ which case the interpreter returns the value of the corresponding
+ <a name="%_idx_388"></a><em>consequent expression</em>
+ &lt;<em>e</em>&gt; of the clause as the value of the conditional
+ expression. If none of the &lt;<em>p</em>&gt;'s is found to be
+ true, the value of the <tt>cond</tt> is undefined.</p>
+
+ <p><a name="%_idx_390"></a>The word <em>predicate</em> is used
+ for procedures that return true or false, as well as for
+ expressions that evaluate to true or false. The absolute-value
+ procedure <tt>abs</tt> makes use of the <a name="%_idx_392"></a><a name="%_idx_394"></a><a name="%_idx_396"></a><a name="%_idx_398"></a><a name="%_idx_400"></a><a name="%_idx_402"></a><a name="%_idx_404"></a><a name="%_idx_406"></a><a name="%_idx_408"></a>primitive predicates <tt>&gt;</tt>,
+ <tt>&lt;</tt>, and <tt>=</tt>.<a href="#footnote_Temp_25" name="call_footnote_Temp_25" id="call_footnote_Temp_25"><sup><small>18</small></sup></a> These
+ take two numbers as arguments and test whether the first number
+ is, respectively, greater than, less than, or equal to the second
+ number, returning true or false accordingly.</p>
+
+ <p>Another way to write the absolute-value procedure is</p>
+
+ <p><tt><a name="%_idx_414"></a>(define&nbsp;(abs&nbsp;x)<br />
+ &nbsp;&nbsp;(cond&nbsp;((&lt;&nbsp;x&nbsp;0)&nbsp;(-&nbsp;x))<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(else&nbsp;x)))<br />
+ </tt></p>
+
+ <p>which could be expressed in English as ``If <em>x</em> is less
+ than zero return - <em>x</em>; otherwise return <em>x</em>.''
+ <a name="%_idx_416"></a><tt>Else</tt> is a special symbol that
+ can be used in place of the &lt;<em>p</em>&gt; in the final
+ clause of a <tt>cond</tt>. This causes the <tt>cond</tt> to
+ return as its value the value of the corresponding
+ &lt;<em>e</em>&gt; whenever all previous clauses have been
+ bypassed. In fact, any expression that always evaluates to a true
+ value could be used as the &lt;<em>p</em>&gt; here.</p>
+
+ <p>Here is yet another way to write the absolute-value
+ procedure:</p>
+
+ <p><tt><a name="%_idx_418"></a>(define&nbsp;(abs&nbsp;x)<br />
+ &nbsp;&nbsp;(if&nbsp;(&lt;&nbsp;x&nbsp;0)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(-&nbsp;x)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x))<br /></tt></p>
+
+ <p><a name="%_idx_420"></a><a name="%_idx_422"></a><a name="%_idx_424"></a>This uses the special form <tt>if</tt>, a
+ restricted type of conditional that can be used when there are
+ precisely <a name="%_idx_426"></a>two cases in the case analysis.
+ The general form of an <tt>if</tt> expression is</p>
+
+ <p>
+ <tt>(if&nbsp;&lt;<em>predicate</em>&gt;&nbsp;&lt;<em>consequent</em>&gt;&nbsp;&lt;<em>alternative</em>&gt;)<br />
+ </tt></p>
+
+ <p><a name="%_idx_428"></a><a name="%_idx_430"></a><a name="%_idx_432"></a>To evaluate an <tt>if</tt> expression, the
+ interpreter starts by evaluating the <a name="%_idx_434"></a>&lt;<em>predicate</em>&gt; part of the
+ expression. If the &lt;<em>predicate</em>&gt; evaluates to a true
+ value, the interpreter then evaluates the <a name="%_idx_436"></a>&lt;<em>consequent</em>&gt; and returns its
+ value. Otherwise it evaluates the <a name="%_idx_438"></a>&lt;<em>alternative</em>&gt; and returns its
+ value.<a href="#footnote_Temp_26" name="call_footnote_Temp_26" id="call_footnote_Temp_26"><sup><small>19</small></sup></a></p>
+
+ <p>In addition to primitive predicates such as <tt>&lt;</tt>,
+ <tt>=</tt>, and <tt>&gt;</tt>, there are logical composition
+ operations, which enable us to construct compound predicates. The
+ three most frequently used are these:</p>
+
+ <ul>
+ <li style="list-style: none"><a name="%_idx_446"></a><a name="%_idx_448"></a><a name="%_idx_450"></a><a name="%_idx_452"></a></li>
+
+ <li>
+ <tt>(and &lt;<em>e<sub>1</sub></em>&gt; <tt>...</tt>
+ &lt;<em>e<sub><em>n</em></sub></em>&gt;)</tt>
+
+ <p>The interpreter evaluates the expressions
+ &lt;<em>e</em>&gt; one at a time, in left-to-right order. If
+ any &lt;<em>e</em>&gt; evaluates to false, the value of the
+ <tt>and</tt> expression is false, and the rest of the
+ &lt;<em>e</em>&gt;'s are not evaluated. If all
+ &lt;<em>e</em>&gt;'s evaluate to true values, the value of
+ the <tt>and</tt> expression is the value of the last one.</p>
+
+ <p><a name="%_idx_454"></a><a name="%_idx_456"></a><a name="%_idx_458"></a><a name="%_idx_460"></a></p>
+ </li>
+
+ <li>
+ <tt>(or &lt;<em>e<sub>1</sub></em>&gt; <tt>...</tt>
+ &lt;<em>e<sub><em>n</em></sub></em>&gt;)</tt>
+
+ <p>The interpreter evaluates the expressions
+ &lt;<em>e</em>&gt; one at a time, in left-to-right order. If
+ any &lt;<em>e</em>&gt; evaluates to a true value, that value
+ is returned as the value of the <tt>or</tt> expression, and
+ the rest of the &lt;<em>e</em>&gt;'s are not evaluated. If
+ all &lt;<em>e</em>&gt;'s evaluate to false, the value of the
+ <tt>or</tt> expression is false.</p>
+
+ <p><a name="%_idx_462"></a><a name="%_idx_464"></a></p>
+ </li>
+
+ <li>
+ <tt>(not &lt;<em>e</em>&gt;)</tt>
+
+ <p>The value of a <tt>not</tt> expression is true when the
+ expression &lt;<em>e</em>&gt; evaluates to false, and false
+ otherwise.</p>
+ </li>
+ </ul>
+
+ <p><a name="%_idx_466"></a><a name="%_idx_468"></a>Notice that
+ <tt>and</tt> and <tt>or</tt> are special forms, not procedures,
+ because the subexpressions are not necessarily all evaluated.
+ <tt>Not</tt> is an ordinary procedure.</p>
+
+ <p>As an example of how these are used, the condition that a
+ number <em>x</em> be in the range 5 &lt; <em>x</em> &lt; 10 may
+ be expressed as</p>
+
+ <p>
+ <tt>(and&nbsp;(&gt;&nbsp;x&nbsp;5)&nbsp;(&lt;&nbsp;x&nbsp;10))<br />
+ </tt></p>
+
+ <p>As another example, we can define a predicate to test whether
+ one number is greater than or equal to another as</p>
+
+ <p><tt><a name="%_idx_470"></a>(define&nbsp;(&gt;=&nbsp;x&nbsp;y)<br />
+ &nbsp;&nbsp;(or&nbsp;(&gt;&nbsp;x&nbsp;y)&nbsp;(=&nbsp;x&nbsp;y)))<br />
+ </tt></p>
+
+ <p>or alternatively as</p>
+
+ <p><tt><a name="%_idx_472"></a>(define&nbsp;(&gt;=&nbsp;x&nbsp;y)<br />
+ &nbsp;&nbsp;(not&nbsp;(&lt;&nbsp;x&nbsp;y)))<br /></tt></p>
+
+ <p><a name="%_thm_1.1"></a> <b>Exercise 1.1.</b>&nbsp;&nbsp;Below
+ is a sequence of expressions. What is the result printed by the
+ interpreter in response to each expression? Assume that the
+ sequence is to be evaluated in the order in which it is
+ presented.</p>
+
+ <p><tt>10<br />
+ (+&nbsp;5&nbsp;3&nbsp;4)<br />
+ (-&nbsp;9&nbsp;1)<br />
+ (/&nbsp;6&nbsp;2)<br />
+ (+&nbsp;(*&nbsp;2&nbsp;4)&nbsp;(-&nbsp;4&nbsp;6))<br />
+ (define&nbsp;a&nbsp;3)<br />
+ (define&nbsp;b&nbsp;(+&nbsp;a&nbsp;1))<br />
+ (+&nbsp;a&nbsp;b&nbsp;(*&nbsp;a&nbsp;b))<br />
+ (=&nbsp;a&nbsp;b)<br />
+ (if&nbsp;(and&nbsp;(&gt;&nbsp;b&nbsp;a)&nbsp;(&lt;&nbsp;b&nbsp;(*&nbsp;a&nbsp;b)))<br />
+
+ &nbsp;&nbsp;&nbsp;&nbsp;b<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;a)<br />
+ (cond&nbsp;((=&nbsp;a&nbsp;4)&nbsp;6)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;((=&nbsp;b&nbsp;4)&nbsp;(+&nbsp;6&nbsp;7&nbsp;a))<br />
+
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(else&nbsp;25))<br />
+ (+&nbsp;2&nbsp;(if&nbsp;(&gt;&nbsp;b&nbsp;a)&nbsp;b&nbsp;a))<br />
+ (*&nbsp;(cond&nbsp;((&gt;&nbsp;a&nbsp;b)&nbsp;a)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;((&lt;&nbsp;a&nbsp;b)&nbsp;b)<br />
+
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(else&nbsp;-1))<br />
+
+ &nbsp;&nbsp;&nbsp;(+&nbsp;a&nbsp;1))<br /></tt></p>
+
+ <p><a name="%_thm_1.2"></a> <b>Exercise
+ 1.2.</b>&nbsp;&nbsp;Translate the following expression into
+ prefix form</p>
+
+ <div align="left"><img src="ch1-Z-G-3.gif" border="0" /></div>
+
+ <p><a name="%_thm_1.3"></a> <b>Exercise
+ 1.3.</b>&nbsp;&nbsp;Define a procedure that takes three numbers
+ as arguments and returns the sum of the squares of the two larger
+ numbers.</p>
+
+ <p><a name="%_thm_1.4"></a> <b>Exercise
+ 1.4.</b>&nbsp;&nbsp;<a name="%_idx_474"></a><a name="%_idx_476"></a><a name="%_idx_478"></a>Observe that our model of
+ evaluation allows for combinations whose operators are compound
+ expressions. Use this observation to describe the behavior of the
+ following procedure:</p>
+
+ <p><tt>(define&nbsp;(a-plus-abs-b&nbsp;a&nbsp;b)<br />
+ &nbsp;&nbsp;((if&nbsp;(&gt;&nbsp;b&nbsp;0)&nbsp;+&nbsp;-)&nbsp;a&nbsp;b))<br />
+ </tt></p>
+
+ <p><a name="%_thm_1.5"></a> <b>Exercise
+ 1.5.</b>&nbsp;&nbsp;<a name="%_idx_480"></a><a name="%_idx_482"></a>Ben Bitdiddle has invented a test to determine
+ whether the interpreter he is faced with is using
+ applicative-order evaluation or normal-order evaluation. He
+ defines the following two procedures:</p>
+
+ <p><tt>(define&nbsp;(p)&nbsp;(p))<br />
+ <br />
+ (define&nbsp;(test&nbsp;x&nbsp;y)<br />
+ &nbsp;&nbsp;(if&nbsp;(=&nbsp;x&nbsp;0)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;y))<br /></tt></p>
+
+ <p>Then he evaluates the expression</p>
+
+ <p><tt>(test&nbsp;0&nbsp;(p))<br /></tt></p>
+
+ <p>What behavior will Ben observe with an interpreter that uses
+ applicative-order evaluation? What behavior will he observe with
+ an interpreter that uses normal-order evaluation? Explain your
+ answer. <a name="%_idx_484"></a><a name="%_idx_486"></a>(Assume
+ that the evaluation rule for the special form <tt>if</tt> is the
+ same whether the interpreter is using normal or applicative
+ order: The predicate expression is evaluated first, and the
+ result determines whether to evaluate the consequent or the
+ alternative expression.)</p>
+
+ <p><a name="%_sec_1.1.7"></a></p>
+
+ <h3><a href="book-Z-H-4.html#%_toc_%_sec_1.1.7">1.1.7&nbsp;&nbsp;Example:
+ Square Roots by Newton's Method</a></h3>
+
+ <p><a name="%_idx_488"></a><a name="%_idx_490"></a>Procedures, as
+ introduced above, are much like ordinary mathematical functions.
+ They specify a value that is determined by one or more
+ parameters. But there is an important difference between
+ mathematical functions and computer procedures. Procedures must
+ be effective.</p>
+
+ <p>As a case in point, consider the problem of computing square
+ roots. We can define the square-root function as</p>
+
+ <div align="left"><img src="ch1-Z-G-4.gif" border="0" /></div>
+
+ <p>This describes a perfectly legitimate mathematical function.
+ We could use it to recognize whether one number is the square
+ root of another, or to derive facts about square roots in
+ general. On the other hand, the definition does not describe a
+ procedure. Indeed, it tells us almost nothing about how to
+ actually find the square root of a given number. It will not help
+ matters to rephrase this definition in pseudo-Lisp:</p>
+
+ <p><tt>(define&nbsp;(sqrt&nbsp;x)<br />
+ &nbsp;&nbsp;(the&nbsp;y&nbsp;(and&nbsp;(&gt;=&nbsp;y&nbsp;0)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(=&nbsp;(square&nbsp;y)&nbsp;x))))<br />
+ </tt></p>
+
+ <p>This only begs the question.</p>
+
+ <p>The contrast between function and procedure is a reflection of
+ the general distinction between describing properties of things
+ and describing how to do things, or, as it is sometimes referred
+ to, the distinction between <a name="%_idx_492"></a><a name="%_idx_494"></a>declarative knowledge and imperative knowledge.
+ In <a name="%_idx_496"></a><a name="%_idx_498"></a>mathematics we
+ are usually concerned with declarative (what is) descriptions,
+ whereas in computer science we are usually concerned with
+ imperative (how to) descriptions.<a href="#footnote_Temp_32" name="call_footnote_Temp_32" id="call_footnote_Temp_32"><sup><small>20</small></sup></a></p>
+
+ <p><a name="%_idx_508"></a><a name="%_idx_510"></a>How does one
+ compute square roots? The most common way is to use Newton's
+ method of successive approximations, which says that whenever we
+ have a guess <em>y</em> for the value of the square root of a
+ number <em>x</em>, we can perform a simple manipulation to get a
+ better guess (one closer to the actual square root) by averaging
+ <em>y</em> with <em>x</em>/<em>y</em>.<a href="#footnote_Temp_33" name="call_footnote_Temp_33" id="call_footnote_Temp_33"><sup><small>21</small></sup></a> For
+ example, we can compute the square root of 2 as follows. Suppose
+ our initial guess is&nbsp;1:</p>
+
+ <table border="0">
+ <tr>
+ <td valign="top">Guess</td>
+
+ <td valign="top">Quotient</td>
+
+ <td valign="top">Average</td>
+ </tr>
+
+ <tr>
+ <td valign="top">&nbsp;&nbsp;</td>
+ </tr>
+
+ <tr>
+ <td valign="top">1</td>
+
+ <td valign="top">(2/1) = 2</td>
+
+ <td valign="top">((2 + 1)/2) = 1.5</td>
+ </tr>
+
+ <tr>
+ <td valign="top">&nbsp;&nbsp;</td>
+ </tr>
+
+ <tr>
+ <td valign="top">1.5</td>
+
+ <td valign="top">(2/1.5) = 1.3333</td>
+
+ <td valign="top">((1.3333 + 1.5)/2) = 1.4167</td>
+ </tr>
+
+ <tr>
+ <td valign="top">&nbsp;&nbsp;</td>
+ </tr>
+
+ <tr>
+ <td valign="top">1.4167</td>
+
+ <td valign="top">(2/1.4167) = 1.4118</td>
+
+ <td valign="top">((1.4167 + 1.4118)/2) = 1.4142</td>
+ </tr>
+
+ <tr>
+ <td valign="top">&nbsp;&nbsp;</td>
+ </tr>
+
+ <tr>
+ <td valign="top">1.4142</td>
+
+ <td valign="top"><tt>...</tt></td>
+
+ <td valign="top"><tt>...</tt></td>
+ </tr>
+
+ <tr>
+ <td valign="top"></td>
+ </tr>
+ </table>
+
+ <p>Continuing this process, we obtain better and better
+ approximations to the square root.</p>
+
+ <p>Now let's formalize the process in terms of procedures. We
+ start with a value for the <a name="%_idx_514"></a>radicand (the
+ number whose square root we are trying to compute) and a value
+ for the guess. If the guess is good enough for our purposes, we
+ are done; if not, we must repeat the process with an improved
+ guess. We write this basic strategy as a procedure:</p>
+
+ <p><tt>(define&nbsp;(sqrt-iter&nbsp;guess&nbsp;x)<br />
+ &nbsp;&nbsp;(if&nbsp;(good-enough?&nbsp;guess&nbsp;x)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;guess<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(sqrt-iter&nbsp;(improve&nbsp;guess&nbsp;x)<br />
+
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x)))<br />
+ </tt></p>
+
+ <p>A guess is improved by averaging it with the quotient of the
+ radicand and the old guess:</p>
+
+ <p><tt>(define&nbsp;(improve&nbsp;guess&nbsp;x)<br />
+ &nbsp;&nbsp;(average&nbsp;guess&nbsp;(/&nbsp;x&nbsp;guess)))<br /></tt></p>
+
+ <p>where</p>
+
+ <p><tt><a name="%_idx_516"></a>(define&nbsp;(average&nbsp;x&nbsp;y)<br />
+ &nbsp;&nbsp;(/&nbsp;(+&nbsp;x&nbsp;y)&nbsp;2))<br /></tt></p>
+
+ <p>We also have to say what we mean by ``good enough.'' The
+ following will do for illustration, but it is not really a very
+ good test. (See exercise&nbsp;<a href="#%_thm_1.7">1.7</a>.) The
+ idea is to improve the answer until it is close enough so that
+ its square differs from the radicand by less than a predetermined
+ tolerance (here 0.001):<a href="#footnote_Temp_34" name="call_footnote_Temp_34" id="call_footnote_Temp_34"><sup><small>22</small></sup></a></p>
+
+ <p><tt>(define&nbsp;(good-enough?&nbsp;guess&nbsp;x)<br />
+ &nbsp;&nbsp;(&lt;&nbsp;(abs&nbsp;(-&nbsp;(square&nbsp;guess)&nbsp;x))&nbsp;0.001))<br />
+ </tt></p>
+
+ <p>Finally, we need a way to get started. For instance, we can
+ always guess that the square root of any number is 1:<a href="#footnote_Temp_35" name="call_footnote_Temp_35" id="call_footnote_Temp_35"><sup><small>23</small></sup></a></p>
+
+ <p><tt><a name="%_idx_550"></a>(define&nbsp;(sqrt&nbsp;x)<br />
+ &nbsp;&nbsp;(sqrt-iter&nbsp;1.0&nbsp;x))<br /></tt></p>
+
+ <p>If we type these definitions to the interpreter, we can use
+ <tt>sqrt</tt> just as we can use any procedure:</p>
+
+ <p><tt>(sqrt&nbsp;9)<br />
+ <i>3.00009155413138</i><br />
+ (sqrt&nbsp;(+&nbsp;100&nbsp;37))<br />
+ <i>11.704699917758145</i><br />
+ (sqrt&nbsp;(+&nbsp;(sqrt&nbsp;2)&nbsp;(sqrt&nbsp;3)))<br />
+ <i>1.7739279023207892</i><br />
+ (square&nbsp;(sqrt&nbsp;1000))<br />
+ <i>1000.000369924366</i><br /></tt></p>
+
+ <p><a name="%_idx_552"></a>The <tt>sqrt</tt> program also
+ illustrates that the simple procedural language we have
+ introduced so far is sufficient for writing any purely numerical
+ program that one could write in, say, C or Pascal. This might
+ seem surprising, since we have not included in our language any
+ iterative <a name="%_idx_554"></a>(looping) constructs that
+ direct the computer to do something over and over again.
+ <tt>Sqrt-iter</tt>, on the other hand, demonstrates how iteration
+ can be accomplished using no special construct other than the
+ ordinary ability to call a procedure.<a href="#footnote_Temp_36" name="call_footnote_Temp_36" id="call_footnote_Temp_36"><sup><small>24</small></sup></a></p>
+
+ <p><a name="%_thm_1.6"></a> <b>Exercise
+ 1.6.</b>&nbsp;&nbsp;<a name="%_idx_556"></a><a name="%_idx_558"></a>Alyssa P. Hacker doesn't see why <tt>if</tt>
+ needs to be provided as a special form. ``Why can't I just define
+ it as an ordinary procedure in terms of <tt>cond</tt>?'' she
+ asks. Alyssa's friend Eva Lu Ator claims this can indeed be done,
+ and she defines a new version of <tt>if</tt>:</p>
+
+ <p>
+ <tt>(define&nbsp;(new-if&nbsp;predicate&nbsp;then-clause&nbsp;else-clause)<br />
+
+ &nbsp;&nbsp;(cond&nbsp;(predicate&nbsp;then-clause)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(else&nbsp;else-clause)))<br />
+ </tt></p>
+
+ <p>Eva demonstrates the program for Alyssa:</p>
+
+ <p><tt>(new-if&nbsp;(=&nbsp;2&nbsp;3)&nbsp;0&nbsp;5)<br />
+ <i>5</i><br />
+ <br />
+ (new-if&nbsp;(=&nbsp;1&nbsp;1)&nbsp;0&nbsp;5)<br />
+ <i>0</i><br /></tt></p>
+
+ <p>Delighted, Alyssa uses <tt>new-if</tt> to rewrite the
+ square-root program:</p>
+
+ <p><tt>(define&nbsp;(sqrt-iter&nbsp;guess&nbsp;x)<br />
+ &nbsp;&nbsp;(new-if&nbsp;(good-enough?&nbsp;guess&nbsp;x)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;guess<br />
+
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(sqrt-iter&nbsp;(improve&nbsp;guess&nbsp;x)<br />
+
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x)))<br />
+ </tt></p>
+
+ <p>What happens when Alyssa attempts to use this to compute
+ square roots? Explain.</p>
+
+ <p><a name="%_thm_1.7"></a> <b>Exercise 1.7.</b>&nbsp;&nbsp;The
+ <tt>good-enough?</tt> test used in computing square roots will
+ not be very effective for finding the square roots of very small
+ numbers. Also, in real computers, arithmetic operations are
+ almost always performed with limited precision. This makes our
+ test inadequate for very large numbers. Explain these statements,
+ with examples showing how the test fails for small and large
+ numbers. An alternative strategy for implementing
+ <tt>good-enough?</tt> is to watch how <tt>guess</tt> changes from
+ one iteration to the next and to stop when the change is a very
+ small fraction of the guess. Design a square-root procedure that
+ uses this kind of end test. Does this work better for small and
+ large numbers?</p>
+
+ <p><a name="%_thm_1.8"></a> <b>Exercise
+ 1.8.</b>&nbsp;&nbsp;<a name="%_idx_560"></a><a name="%_idx_562"></a>Newton's method for cube roots is based on the
+ fact that if <em>y</em> is an approximation to the cube root of
+ <em>x</em>, then a better approximation is given by the value</p>
+
+ <div align="left"><img src="ch1-Z-G-5.gif" border="0" /></div>
+
+ <p>Use this formula to implement a cube-root procedure analogous
+ to the square-root procedure. (In section&nbsp;<a href="book-Z-H-12.html#%_sec_1.3.4">1.3.4</a> we will see how to
+ implement Newton's method in general as an abstraction of these
+ square-root and cube-root procedures.)</p>
+
+ <p><a name="%_sec_1.1.8"></a></p>
+
+ <h3><a href="book-Z-H-4.html#%_toc_%_sec_1.1.8">1.1.8&nbsp;&nbsp;Procedures
+ as Black-Box Abstractions</a></h3>
+
+ <p><tt>Sqrt</tt> is our first example of a process defined by a
+ set of mutually defined procedures. Notice that the definition of
+ <tt>sqrt-iter</tt> is <a name="%_idx_564"></a><em>recursive</em>;
+ that is, the procedure is defined in terms of itself. The idea of
+ being able to define a procedure in terms of itself may be
+ disturbing; it may seem unclear how such a ``circular''
+ definition could make sense at all, much less specify a
+ well-defined process to be carried out by a computer. This will
+ be addressed more carefully in section&nbsp;<a href="book-Z-H-11.html#%_sec_1.2">1.2</a>. But first let's consider
+ some other important points illustrated by the <tt>sqrt</tt>
+ example.</p>
+
+ <p><a name="%_idx_566"></a>Observe that the problem of computing
+ square roots breaks up naturally into a number of subproblems:
+ how to tell whether a guess is good enough, how to improve a
+ guess, and so on. Each of these tasks is accomplished by a
+ separate procedure. The entire <tt>sqrt</tt> program can be
+ viewed as a cluster of procedures (shown in figure&nbsp;<a href="#%_fig_1.2">1.2</a>) that mirrors the decomposition of the
+ problem into subproblems.</p>
+
+ <p><a name="%_fig_1.2"></a></p>
+
+ <div align="left">
+ <div align="left">
+ <b>Figure 1.2:</b>&nbsp;&nbsp;Procedural decomposition of the
+ <tt>sqrt</tt> program.
+ </div>
+
+ <table width="100%">
+ <tr>
+ <td><img src="ch1-Z-G-6.gif" border="0" /></td>
+ </tr>
+
+ <tr>
+ <td></td>
+ </tr>
+ </table>
+ </div>
+
+ <p><a name="%_idx_568"></a>The importance of this decomposition
+ strategy is not simply that one is dividing the program into
+ parts. After all, we could take any large program and divide it
+ into parts -- the first ten lines, the next ten lines, the next
+ ten lines, and so on. Rather, it is crucial that each procedure
+ accomplishes an identifiable task that can be used as a module in
+ defining other procedures. <a name="%_idx_570"></a>For example,
+ when we define the <tt>good-enough?</tt> procedure in terms of
+ <tt>square</tt>, we are able to regard the <tt>square</tt>
+ procedure as a <a name="%_idx_572"></a>``black box.'' We are not
+ at that moment concerned with <em>how</em> the procedure computes
+ its result, only with the fact that it computes the square. The
+ details of how the square is computed can be suppressed, to be
+ considered at a later time. Indeed, as far as the
+ <tt>good-enough?</tt> procedure is concerned, <tt>square</tt> is
+ not quite a procedure but rather an abstraction of a procedure, a
+ so-called <a name="%_idx_574"></a><a name="%_idx_576"></a><em>procedural abstraction</em>. At this level of
+ abstraction, any procedure that computes the square is equally
+ good.</p>
+
+ <p>Thus, considering only the values they return, the following
+ two procedures for squaring a number should be indistinguishable.
+ Each takes a numerical argument and produces the square of that
+ number as the value.<a href="#footnote_Temp_40" name="call_footnote_Temp_40" id="call_footnote_Temp_40"><sup><small>25</small></sup></a></p>
+
+ <p><tt>(define&nbsp;(square&nbsp;x)&nbsp;(*&nbsp;x&nbsp;x))<br />
+ <br />
+ (define&nbsp;(square&nbsp;x)&nbsp;<br />
+ &nbsp;&nbsp;(exp&nbsp;(double&nbsp;(log&nbsp;x))))<br />
+ <br />
+ (define&nbsp;(double&nbsp;x)&nbsp;(+&nbsp;x&nbsp;x))<br /></tt></p>
+
+ <p>So a procedure definition should be able to suppress detail.
+ The users of the procedure may not have written the procedure
+ themselves, but may have obtained it from another programmer as a
+ black box. A user should not need to know how the procedure is
+ implemented in order to use it.</p>
+
+ <p><a name="%_sec_Temp_41"></a></p>
+
+ <h4><a href="book-Z-H-4.html#%_toc_%_sec_Temp_41">Local
+ names</a></h4>
+
+ <p><a name="%_idx_578"></a> One detail of a procedure's
+ implementation that should not matter to the user of the
+ procedure is the implementer's choice of names for the
+ procedure's formal parameters. Thus, the following procedures
+ should not be distinguishable:</p>
+
+ <p><tt>(define&nbsp;(square&nbsp;x)&nbsp;(*&nbsp;x&nbsp;x))<br />
+ <br />
+ (define&nbsp;(square&nbsp;y)&nbsp;(*&nbsp;y&nbsp;y))<br /></tt></p>
+
+ <p>This principle -- that the meaning of a procedure should be
+ independent of the parameter names used by its author -- seems on
+ the surface to be self-evident, but its consequences are
+ profound. The simplest consequence is that the parameter names of
+ a procedure must be local to the body of the procedure. For
+ example, we used <tt>square</tt> in the definition of
+ <tt>good-enough?</tt> in our square-root procedure:</p>
+
+ <p><tt>(define&nbsp;(good-enough?&nbsp;guess&nbsp;x)<br />
+ &nbsp;&nbsp;(&lt;&nbsp;(abs&nbsp;(-&nbsp;(square&nbsp;guess)&nbsp;x))&nbsp;0.001))<br />
+ </tt></p>
+
+ <p>The intention of the author of <tt>good-enough?</tt> is to
+ determine if the square of the first argument is within a given
+ tolerance of the second argument. We see that the author of
+ <tt>good-enough?</tt> used the name <tt>guess</tt> to refer to
+ the first argument and <tt>x</tt> to refer to the second
+ argument. The argument of <tt>square</tt> is <tt>guess</tt>. If
+ the author of <tt>square</tt> used <tt>x</tt> (as above) to refer
+ to that argument, we see that the <tt>x</tt> in
+ <tt>good-enough?</tt> must be a different <tt>x</tt> than the one
+ in <tt>square</tt>. Running the procedure <tt>square</tt> must
+ not affect the value of <tt>x</tt> that is used by
+ <tt>good-enough?</tt>, because that value of <tt>x</tt> may be
+ needed by <tt>good-enough?</tt> after <tt>square</tt> is done
+ computing.</p>
+
+ <p>If the parameters were not local to the bodies of their
+ respective procedures, then the parameter <tt>x</tt> in
+ <tt>square</tt> could be confused with the parameter <tt>x</tt>
+ in <tt>good-enough?</tt>, and the behavior of
+ <tt>good-enough?</tt> would depend upon which version of
+ <tt>square</tt> we used. Thus, <tt>square</tt> would not be the
+ black box we desired.</p>
+
+ <p><a name="%_idx_580"></a><a name="%_idx_582"></a>A formal
+ parameter of a procedure has a very special role in the procedure
+ definition, in that it doesn't matter what name the formal
+ parameter has. Such a name is called a <a name="%_idx_584"></a><a name="%_idx_586"></a><em>bound variable</em>,
+ and we say that the procedure definition <a name="%_idx_588"></a><em>binds</em> its formal parameters. The meaning
+ of a procedure definition is unchanged if a bound variable is
+ consistently renamed throughout the definition.<a href="#footnote_Temp_42" name="call_footnote_Temp_42" id="call_footnote_Temp_42"><sup><small>26</small></sup></a> If a
+ variable is not bound, we say that it is <a name="%_idx_590"></a><a name="%_idx_592"></a><em>free</em>. The set of
+ expressions for which a binding defines a name is called the
+ <a name="%_idx_594"></a><a name="%_idx_596"></a><em>scope</em> of
+ that name. In a procedure definition, the bound variables
+ declared as the <a name="%_idx_598"></a><a name="%_idx_600"></a><a name="%_idx_602"></a>formal parameters of the
+ procedure have the body of the procedure as their scope.</p>
+
+ <p>In the definition of <tt>good-enough?</tt> above,
+ <tt>guess</tt> and <tt>x</tt> are bound variables but
+ <tt>&lt;</tt>, <tt>-</tt>, <tt>abs</tt>, and <tt>square</tt> are
+ free. The meaning of <tt>good-enough?</tt> should be independent
+ of the names we choose for <tt>guess</tt> and <tt>x</tt> so long
+ as they are distinct and different from <tt>&lt;</tt>,
+ <tt>-</tt>, <tt>abs</tt>, and <tt>square</tt>. (If we renamed
+ <tt>guess</tt> to <tt>abs</tt> we would have introduced a bug by
+ <a name="%_idx_604"></a><a name="%_idx_606"></a><a name="%_idx_608"></a><em>capturing</em> the variable <tt>abs</tt>. It
+ would have changed from free to bound.) The meaning of
+ <tt>good-enough?</tt> is not independent of the names of its free
+ variables, however. It surely depends upon the fact (external to
+ this definition) that the symbol <tt>abs</tt> names a procedure
+ for computing the absolute value of a number.
+ <tt>Good-enough?</tt> will compute a different function if we
+ substitute <tt>cos</tt> for <tt>abs</tt> in its definition.</p>
+
+ <p><a name="%_sec_Temp_43"></a></p>
+
+ <h4><a href="book-Z-H-4.html#%_toc_%_sec_Temp_43">Internal
+ definitions and block structure</a></h4>
+
+ <p>We have one kind of name isolation available to us so far: The
+ formal parameters of a procedure are local to the body of the
+ procedure. The square-root program illustrates another way in
+ which we would like to control the use of names. <a name="%_idx_610"></a>The existing program consists of separate
+ procedures:</p>
+
+ <p><tt>(define&nbsp;(sqrt&nbsp;x)<br />
+ &nbsp;&nbsp;(sqrt-iter&nbsp;1.0&nbsp;x))<br />
+ (define&nbsp;(sqrt-iter&nbsp;guess&nbsp;x)<br />
+ &nbsp;&nbsp;(if&nbsp;(good-enough?&nbsp;guess&nbsp;x)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;guess<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(sqrt-iter&nbsp;(improve&nbsp;guess&nbsp;x)&nbsp;x)))<br />
+
+ (define&nbsp;(good-enough?&nbsp;guess&nbsp;x)<br />
+ &nbsp;&nbsp;(&lt;&nbsp;(abs&nbsp;(-&nbsp;(square&nbsp;guess)&nbsp;x))&nbsp;0.001))<br />
+
+ (define&nbsp;(improve&nbsp;guess&nbsp;x)<br />
+ &nbsp;&nbsp;(average&nbsp;guess&nbsp;(/&nbsp;x&nbsp;guess)))<br /></tt></p>
+
+ <p>The problem with this program is that the only procedure that
+ is important to users of <tt>sqrt</tt> is <tt>sqrt</tt>. The
+ other procedures (<tt>sqrt-iter</tt>, <tt>good-enough?</tt>, and
+ <tt>improve</tt>) only clutter up their minds. They may not
+ define any other procedure called <tt>good-enough?</tt> as part
+ of another program to work together with the square-root program,
+ because <tt>sqrt</tt> needs it. The problem is especially severe
+ in the construction of large systems by many separate
+ programmers. For example, in the construction of a large library
+ of numerical procedures, many numerical functions are computed as
+ successive approximations and thus might have procedures named
+ <tt>good-enough?</tt> and <tt>improve</tt> as auxiliary
+ procedures. We would like to localize the subprocedures, hiding
+ them inside <tt>sqrt</tt> so that <tt>sqrt</tt> could coexist
+ with other successive approximations, each having its own private
+ <tt>good-enough?</tt> procedure. To make this possible, we allow
+ a procedure to have <a name="%_idx_612"></a><a name="%_idx_614"></a>internal definitions that are local to that
+ procedure. For example, in the square-root problem we can
+ write</p>
+
+ <p><tt>(define&nbsp;(sqrt&nbsp;x)<br />
+ &nbsp;&nbsp;(define&nbsp;(good-enough?&nbsp;guess&nbsp;x)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;(&lt;&nbsp;(abs&nbsp;(-&nbsp;(square&nbsp;guess)&nbsp;x))&nbsp;0.001))<br />
+
+ &nbsp;&nbsp;(define&nbsp;(improve&nbsp;guess&nbsp;x)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;(average&nbsp;guess&nbsp;(/&nbsp;x&nbsp;guess)))<br />
+
+ &nbsp;&nbsp;(define&nbsp;(sqrt-iter&nbsp;guess&nbsp;x)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;(if&nbsp;(good-enough?&nbsp;guess&nbsp;x)<br />
+
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;guess<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(sqrt-iter&nbsp;(improve&nbsp;guess&nbsp;x)&nbsp;x)))<br />
+
+ &nbsp;&nbsp;(sqrt-iter&nbsp;1.0&nbsp;x))<br /></tt></p>
+
+ <p>Such nesting of definitions, called <em>block structure</em>,
+ is basically the right solution to the simplest name-packaging
+ problem. But there is a better idea lurking here. In addition to
+ internalizing the definitions of the auxiliary procedures, we can
+ simplify them. Since <tt>x</tt> is bound in the definition of
+ <tt>sqrt</tt>, the procedures <tt>good-enough?</tt>,
+ <tt>improve</tt>, and <tt>sqrt-iter</tt>, which are defined
+ internally to <tt>sqrt</tt>, are in the scope of <tt>x</tt>.
+ Thus, it is not necessary to pass <tt>x</tt> explicitly to each
+ of these procedures. Instead, we allow <tt>x</tt> to be a
+ <a name="%_idx_616"></a><a name="%_idx_618"></a>free variable in
+ the internal definitions, as shown below. Then <tt>x</tt> gets
+ its value from the argument with which the enclosing procedure
+ <tt>sqrt</tt> is called. This discipline is called <a name="%_idx_620"></a><em>lexical scoping</em>.<a href="#footnote_Temp_44" name="call_footnote_Temp_44" id="call_footnote_Temp_44"><sup><small>27</small></sup></a></p>
+
+ <p><tt><a name="%_idx_624"></a>(define&nbsp;(sqrt&nbsp;x)<br />
+ &nbsp;&nbsp;(define&nbsp;(good-enough?&nbsp;guess)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;(&lt;&nbsp;(abs&nbsp;(-&nbsp;(square&nbsp;guess)&nbsp;x))&nbsp;0.001))<br />
+
+ &nbsp;&nbsp;(define&nbsp;(improve&nbsp;guess)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;(average&nbsp;guess&nbsp;(/&nbsp;x&nbsp;guess)))<br />
+
+ &nbsp;&nbsp;(define&nbsp;(sqrt-iter&nbsp;guess)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;(if&nbsp;(good-enough?&nbsp;guess)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;guess<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(sqrt-iter&nbsp;(improve&nbsp;guess))))<br />
+
+ &nbsp;&nbsp;(sqrt-iter&nbsp;1.0))<br /></tt></p>
+
+ <p>We will use block structure extensively to help us break up
+ large programs into tractable pieces.<a href="#footnote_Temp_45" name="call_footnote_Temp_45" id="call_footnote_Temp_45"><sup><small>28</small></sup></a> The idea
+ of block structure originated with the programming language
+ <a name="%_idx_628"></a>Algol 60. It appears in most advanced
+ programming languages and is an important tool for helping to
+ organize the construction of large programs.</p>
+
+ <div class="smallprint">
+ <hr />
+ </div>
+
+ <div class="footnote">
+ <p><a href="#call_footnote_Temp_10" name="footnote_Temp_10" id="footnote_Temp_10"><sup><small>4</small></sup></a> The
+ characterization of numbers as ``simple data'' is a barefaced
+ bluff. In fact, the treatment of numbers is one of the
+ trickiest and most confusing aspects of any programming
+ language. Some typical issues involved are these: <a name="%_idx_136"></a><a name="%_idx_138"></a><a name="%_idx_140"></a>Some computer systems distinguish
+ <em>integers</em>, such as 2, from <em>real numbers</em>, such
+ as 2.71. Is the real number 2.00 different from the integer 2?
+ Are the arithmetic operations used for integers the same as the
+ operations used for real numbers? Does 6 divided by 2 produce
+ 3, or 3.0? How large a number can we represent? How many
+ decimal places of accuracy can we represent? Is the range of
+ integers the same as the range of real numbers? <a name="%_idx_142"></a><a name="%_idx_144"></a><a name="%_idx_146"></a>Above and beyond these questions, of course,
+ lies a collection of issues concerning roundoff and truncation
+ errors -- the entire science of numerical analysis. Since our
+ focus in this book is on large-scale program design rather than
+ on numerical techniques, we are going to ignore these problems.
+ The numerical examples in this chapter will exhibit the usual
+ roundoff behavior that one observes when using arithmetic
+ operations that preserve a limited number of decimal places of
+ accuracy in noninteger operations.</p>
+
+ <p><a href="#call_footnote_Temp_11" name="footnote_Temp_11" id="footnote_Temp_11"><sup><small>5</small></sup></a> Throughout
+ this book, <a name="%_idx_152"></a>when we wish to emphasize
+ the distinction between the input typed by the user and the
+ response printed by the interpreter, we will show the latter in
+ slanted characters.</p>
+
+ <p><a href="#call_footnote_Temp_12" name="footnote_Temp_12" id="footnote_Temp_12"><sup><small>6</small></sup></a> <a name="%_idx_200"></a><a name="%_idx_202"></a>Lisp systems typically
+ provide features to aid the user in formatting expressions. Two
+ especially useful features are one that automatically indents
+ to the proper pretty-print position whenever a new line is
+ started and one that highlights the matching left parenthesis
+ whenever a right parenthesis is typed.</p>
+
+ <p><a href="#call_footnote_Temp_13" name="footnote_Temp_13" id="footnote_Temp_13"><sup><small>7</small></sup></a> <a name="%_idx_208"></a><a name="%_idx_210"></a><a name="%_idx_212"></a><a name="%_idx_214"></a>Lisp obeys the
+ convention that every expression has a value. This convention,
+ together with the old reputation of Lisp as an inefficient
+ language, is the source of the quip by Alan Perlis
+ (paraphrasing Oscar Wilde) that ``Lisp programmers know the
+ value of everything but the cost of nothing.''</p>
+
+ <p><a href="#call_footnote_Temp_14" name="footnote_Temp_14" id="footnote_Temp_14"><sup><small>8</small></sup></a> <a name="%_idx_228"></a><a name="%_idx_230"></a>In this book, we do not
+ show the interpreter's response to evaluating definitions,
+ since this is highly implementation-dependent.</p>
+
+ <p><a href="#call_footnote_Temp_15" name="footnote_Temp_15" id="footnote_Temp_15"><sup><small>9</small></sup></a>
+ Chapter&nbsp;3 will show that this notion of environment is
+ crucial, both for understanding how the interpreter works and
+ for implementing interpreters.</p>
+
+ <p><a href="#call_footnote_Temp_16" name="footnote_Temp_16" id="footnote_Temp_16"><sup><small>10</small></sup></a> It may seem
+ strange that the evaluation rule says, as part of the first
+ step, that we should evaluate the leftmost element of a
+ combination, since at this point that can only be an operator
+ such as <tt>+</tt> or <tt>*</tt> representing a built-in
+ primitive procedure such as addition or multiplication. We will
+ see later that it is useful to be able to work with
+ combinations whose operators are themselves compound
+ expressions.</p>
+
+ <p><a href="#call_footnote_Temp_17" name="footnote_Temp_17" id="footnote_Temp_17"><sup><small>11</small></sup></a> <a name="%_idx_278"></a><a name="%_idx_280"></a><a name="%_idx_282"></a><a name="%_idx_284"></a><a name="%_idx_286"></a><a name="%_idx_288"></a><a name="%_idx_290"></a>Special syntactic forms that are simply
+ convenient alternative surface structures for things that can
+ be written in more uniform ways are sometimes called
+ <em>syntactic sugar</em>, to use a phrase coined by Peter
+ Landin. In comparison with users of other languages, Lisp
+ programmers, as a rule, are less concerned with matters of
+ syntax. (By contrast, examine any Pascal manual and notice how
+ much of it is devoted to descriptions of syntax.) This disdain
+ for syntax is due partly to the flexibility of Lisp, which
+ makes it easy to change surface syntax, and partly to the
+ observation that many ``convenient'' syntactic constructs,
+ which make the language less uniform, end up causing more
+ trouble than they are worth when programs become large and
+ complex. In the words of Alan Perlis, ``Syntactic sugar causes
+ cancer of the semicolon.''</p>
+
+ <p><a href="#call_footnote_Temp_18" name="footnote_Temp_18" id="footnote_Temp_18"><sup><small>12</small></sup></a> Observe
+ that there are two different operations being combined here: we
+ are creating the procedure, and we are giving it the name
+ <tt>square</tt>. It is possible, indeed important, to be able
+ to separate these two notions -- to create procedures without
+ naming them, and to give names to procedures that have already
+ been created. We will see how to do this in
+ section&nbsp;<a href="book-Z-H-12.html#%_sec_1.3.2">1.3.2</a>.</p>
+
+ <p><a href="#call_footnote_Temp_19" name="footnote_Temp_19" id="footnote_Temp_19"><sup><small>13</small></sup></a> Throughout
+ this book, we will <a name="%_idx_314"></a><a name="%_idx_316"></a>describe the general syntax of expressions by
+ using italic symbols delimited by angle brackets -- e.g.,
+ &lt;<em>name</em>&gt; -- to denote the ``slots'' in the
+ expression to be filled in when such an expression is actually
+ used.</p>
+
+ <p><a href="#call_footnote_Temp_20" name="footnote_Temp_20" id="footnote_Temp_20"><sup><small>14</small></sup></a> More
+ <a name="%_idx_326"></a>generally, the body of the procedure
+ can be a sequence of expressions. In this case, the interpreter
+ evaluates each expression in the sequence in turn and returns
+ the value of the final expression as the value of the procedure
+ application.</p>
+
+ <p><a href="#call_footnote_Temp_21" name="footnote_Temp_21" id="footnote_Temp_21"><sup><small>15</small></sup></a> Despite the
+ simplicity of the substitution idea, it turns out to be
+ surprisingly complicated to give a rigorous mathematical
+ definition of the substitution process. The problem arises from
+ the possibility of confusion between the names used for the
+ formal parameters of a procedure and the (possibly identical)
+ names used in the expressions to which the procedure may be
+ applied. Indeed, there is a long history of erroneous
+ definitions of <em>substitution</em> in the literature of logic
+ and programming semantics. <a name="%_idx_338"></a>See Stoy
+ 1977 for a careful discussion of substitution.</p>
+
+ <p><a href="#call_footnote_Temp_23" name="footnote_Temp_23" id="footnote_Temp_23"><sup><small>16</small></sup></a> In
+ chapter&nbsp;3 we will introduce <em>stream processing</em>,
+ which is a way of handling apparently ``infinite'' data
+ structures by incorporating a limited form of normal-order
+ evaluation. In section&nbsp;<a href="book-Z-H-27.html#%_sec_4.2">4.2</a> we will modify the Scheme
+ interpreter to produce a normal-order variant of Scheme.</p>
+
+ <p><a href="#call_footnote_Temp_24" name="footnote_Temp_24" id="footnote_Temp_24"><sup><small>17</small></sup></a> <a name="%_idx_368"></a><a name="%_idx_370"></a><a name="%_idx_372"></a><a name="%_idx_374"></a><a name="%_idx_376"></a><a name="%_idx_378"></a><a name="%_idx_380"></a><a name="%_idx_382"></a>``Interpreted as either
+ true or false'' means this: In Scheme, there are two
+ distinguished values that are denoted by the constants
+ <tt>#t</tt> and <tt>#f</tt>. When the interpreter checks a
+ predicate's value, it interprets <tt>#f</tt> as false. Any
+ other value is treated as true. (Thus, providing <tt>#t</tt> is
+ logically unnecessary, but it is convenient.) In this book we
+ will use names <tt>true</tt> and <tt>false</tt>, which are
+ associated with the values <tt>#t</tt> and <tt>#f</tt>
+ respectively.</p>
+
+ <p><a href="#call_footnote_Temp_25" name="footnote_Temp_25" id="footnote_Temp_25"><sup><small>18</small></sup></a>
+ <tt>Abs</tt> also uses <a name="%_idx_410"></a><a name="%_idx_412"></a>the ``minus'' operator <tt>-</tt>, which, when
+ used with a single operand, as in <tt>(-&nbsp;x)</tt>,
+ indicates negation.</p>
+
+ <p><a href="#call_footnote_Temp_26" name="footnote_Temp_26" id="footnote_Temp_26"><sup><small>19</small></sup></a> A minor
+ difference <a name="%_idx_440"></a><a name="%_idx_442"></a><a name="%_idx_444"></a>between <tt>if</tt> and
+ <tt>cond</tt> is that the &lt;<em>e</em>&gt; part of each
+ <tt>cond</tt> clause may be a sequence of expressions. If the
+ corresponding &lt;<em>p</em>&gt; is found to be true, the
+ expressions &lt;<em>e</em>&gt; are evaluated in sequence and
+ the value of the final expression in the sequence is returned
+ as the value of the <tt>cond</tt>. In an <tt>if</tt>
+ expression, however, the &lt;<em>consequent</em>&gt; and
+ &lt;<em>alternative</em>&gt; must be single expressions.</p>
+
+ <p><a href="#call_footnote_Temp_32" name="footnote_Temp_32" id="footnote_Temp_32"><sup><small>20</small></sup></a> Declarative
+ and imperative descriptions are intimately related, as indeed
+ are mathematics and computer science. For instance, to say that
+ the answer produced by a program is <a name="%_idx_500"></a>``correct'' is to make a declarative statement
+ about the program. There is a large amount of research aimed at
+ establishing techniques for <a name="%_idx_502"></a>proving
+ that programs are correct, and much of the technical difficulty
+ of this subject has to do with negotiating the transition
+ between imperative statements (from which programs are
+ constructed) and declarative statements (which can be used to
+ deduce things). In a related vein, an important current area in
+ programming-language design is the exploration of so-called
+ <a name="%_idx_504"></a><a name="%_idx_506"></a>very high-level
+ languages, in which one actually programs in terms of
+ declarative statements. The idea is to make interpreters
+ sophisticated enough so that, given ``what is'' knowledge
+ specified by the programmer, they can generate ``how to''
+ knowledge automatically. This cannot be done in general, but
+ there are important areas where progress has been made. We
+ shall revisit this idea in chapter&nbsp;4.</p>
+
+ <p><a href="#call_footnote_Temp_33" name="footnote_Temp_33" id="footnote_Temp_33"><sup><small>21</small></sup></a> This
+ square-root algorithm is actually a special case of Newton's
+ method, which is a general technique for finding roots of
+ equations. The square-root algorithm itself was developed by
+ Heron of <a name="%_idx_512"></a>Alexandria in the first
+ century <font size="-2">A</font>.<font size="-2">D</font>. We
+ will see how to express the general Newton's method as a Lisp
+ procedure in section&nbsp;<a href="book-Z-H-12.html#%_sec_1.3.4">1.3.4</a>.</p>
+
+ <p><a href="#call_footnote_Temp_34" name="footnote_Temp_34" id="footnote_Temp_34"><sup><small>22</small></sup></a> We will
+ usually give <a name="%_idx_518"></a><a name="%_idx_520"></a><a name="%_idx_522"></a><a name="%_idx_524"></a>predicates names ending with question marks, to
+ help us remember that they are predicates. This is just a
+ stylistic convention. As far as the interpreter is concerned,
+ the question mark is just an ordinary character.</p>
+
+ <p><a href="#call_footnote_Temp_35" name="footnote_Temp_35" id="footnote_Temp_35"><sup><small>23</small></sup></a> Observe
+ that we express our initial guess as 1.0 rather than 1. This
+ would not make any difference in many Lisp implementations.
+ <a name="%_idx_526"></a><a name="%_idx_528"></a><a name="%_idx_530"></a><a name="%_idx_532"></a><a name="%_idx_534"></a><a name="%_idx_536"></a><a name="%_idx_538"></a><a name="%_idx_540"></a><a name="%_idx_542"></a><a name="%_idx_544"></a><a name="%_idx_546"></a><a name="%_idx_548"></a>MIT Scheme, however,
+ distinguishes between exact integers and decimal values, and
+ dividing two integers produces a rational number rather than a
+ decimal. For example, dividing 10 by 6 yields 5/3, while
+ dividing 10.0 by 6.0 yields 1.6666666666666667. (We will learn
+ how to implement arithmetic on rational numbers in
+ section&nbsp;<a href="book-Z-H-14.html#%_sec_2.1.1">2.1.1</a>.)
+ If we start with an initial guess of 1 in our square-root
+ program, and <em>x</em> is an exact integer, all subsequent
+ values produced in the square-root computation will be rational
+ numbers rather than decimals. Mixed operations on rational
+ numbers and decimals always yield decimals, so starting with an
+ initial guess of 1.0 forces all subsequent values to be
+ decimals.</p>
+
+ <p><a href="#call_footnote_Temp_36" name="footnote_Temp_36" id="footnote_Temp_36"><sup><small>24</small></sup></a> Readers who
+ are worried about the efficiency issues involved in using
+ procedure calls to implement iteration should note the remarks
+ on ``tail recursion'' in section&nbsp;<a href="book-Z-H-11.html#%_sec_1.2.1">1.2.1</a>.</p>
+
+ <p><a href="#call_footnote_Temp_40" name="footnote_Temp_40" id="footnote_Temp_40"><sup><small>25</small></sup></a> It is not
+ even clear which of these procedures is a more efficient
+ implementation. This depends upon the hardware available. There
+ are machines for which the ``obvious'' implementation is the
+ less efficient one. Consider a machine that has extensive
+ tables of logarithms and antilogarithms stored in a very
+ efficient manner.</p>
+
+ <p><a href="#call_footnote_Temp_42" name="footnote_Temp_42" id="footnote_Temp_42"><sup><small>26</small></sup></a> The concept
+ of consistent renaming is actually subtle and difficult to
+ define formally. Famous logicians have made embarrassing errors
+ here.</p>
+
+ <p><a href="#call_footnote_Temp_44" name="footnote_Temp_44" id="footnote_Temp_44"><sup><small>27</small></sup></a> Lexical
+ scoping dictates that free variables in a procedure are taken
+ to refer to bindings made by enclosing procedure definitions;
+ that is, they are looked up in <a name="%_idx_622"></a>the
+ environment in which the procedure was defined. We will see how
+ this works in detail in chapter&nbsp;3 when we study
+ environments and the detailed behavior of the interpreter.</p>
+
+ <p><a href="#call_footnote_Temp_45" name="footnote_Temp_45" id="footnote_Temp_45"><sup><small>28</small></sup></a> Embedded
+ definitions <a name="%_idx_626"></a>must come first in a
+ procedure body. The management is not responsible for the
+ consequences of running programs that intertwine definition and
+ use.</p>
+ </div>
+
+
+</body>
+</html>
1,618 content/book-Z-H-11.html
@@ -0,0 +1,1618 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
+
+<html>
+<!-- Generated from TeX source by tex2page, v 4o,
+ (c) Dorai Sitaram, http://www.cs.rice.edu/~dorai/tex2page -->
+
+<head>
+ <meta name="generator" content="HTML Tidy for Linux (vers 7 December 2008), see www.w3.org" />
+
+ <title>Structure and Interpretation of Computer Programs</title>
+ <link href="book-Z-C.css" title="default" rel="stylesheet" type="text/css" />
+ <meta name="robots" content="noindex,follow" />
+</head>
+
+<body>
+ <mbp:pagebreak />
+
+ <p><a name="%_sec_1.2"></a></p>
+
+ <h2><a href="book-Z-H-4.html#%_toc_%_sec_1.2">1.2&nbsp;&nbsp;Procedures and
+ the Processes They Generate</a></h2>
+
+ <p>We have now considered the elements of programming: We have
+ used primitive arithmetic operations, we have combined these
+ operations, and we have abstracted these composite operations by
+ defining them as compound procedures. But that is not enough to
+ enable us to say that we know how to program. Our situation is
+ analogous to that of someone who has learned the rules for how
+ the pieces move in chess but knows nothing of typical openings,
+ tactics, or strategy. Like the novice chess player, we don't yet
+ know the common patterns of usage in the domain. We lack the
+ knowledge of which moves are worth making (which procedures are
+ worth defining). We lack the experience to predict the
+ consequences of making a move (executing a procedure).</p>
+
+ <p>The ability to visualize the consequences of the actions under
+ consideration is crucial to becoming an expert programmer, just
+ as it is in any synthetic, creative activity. In becoming an
+ expert photographer, for example, one must learn how to look at a
+ scene and know how dark each region will appear on a print for
+ each possible choice of exposure and development conditions. Only
+ then can one reason backward, planning framing, lighting,
+ exposure, and development to obtain the desired effects. So it is
+ with programming, where we are planning the course of action to
+ be taken by a process and where we control the process by means
+ of a program. To become experts, we must learn to visualize the
+ processes generated by various types of procedures. Only after we
+ have developed such a skill can we learn to reliably construct
+ programs that exhibit the desired behavior.</p>
+
+ <p><a name="%_idx_630"></a><a name="%_idx_632"></a><a name="%_idx_634"></a>A procedure is a pattern for the <em>local
+ evolution</em> of a computational process. It specifies how each
+ stage of the process is built upon the previous stage. We would
+ like to be able to make statements about the overall, or
+ <em>global</em>, behavior of a process whose local evolution has
+ been specified by a procedure. This is very difficult to do in
+ general, but we can at least try to describe some typical
+ patterns of process evolution.</p>
+
+ <p>In this section we will examine some common ``shapes'' for
+ processes generated by simple procedures. We will also
+ investigate the rates at which these processes consume the
+ important computational resources of time and space. The
+ procedures we will consider are very simple. Their role is like
+ that played by test patterns in photography: as oversimplified
+ prototypical patterns, rather than practical examples in their
+ own right.</p>
+
+ <p><a name="%_sec_1.2.1"></a></p>
+
+ <h3><a href="book-Z-H-4.html#%_toc_%_sec_1.2.1">1.2.1&nbsp;&nbsp;Linear
+ Recursion and Iteration</a></h3>
+
+ <p><a name="%_idx_636"></a><a name="%_idx_638"></a> <a name="%_fig_1.3"></a></p>
+
+ <div align="left">
+ <div align="left">
+ <b>Figure 1.3:</b>&nbsp;&nbsp;A linear recursive process for
+ computing 6!.
+ </div>
+
+ <table width="100%">
+ <tr>
+ <td><img src="ch1-Z-G-7.gif" border="0" /></td>
+ </tr>
+
+ <tr>
+ <td></td>
+ </tr>
+ </table>
+ </div>
+
+ <p><a name="%_idx_640"></a>We begin by considering the factorial
+ function, defined by</p>
+
+ <div align="left"><img src="ch1-Z-G-8.gif" border="0" /></div>
+
+ <p>There are many ways to compute factorials. One way is to make
+ use of the observation that <em>n</em>! is equal to <em>n</em>
+ times (<em>n</em> - 1)! for any positive
+ integer&nbsp;<em>n</em>:</p>
+
+ <div align="left"><img src="ch1-Z-G-9.gif" border="0" /></div>
+
+ <p>Thus, we can compute <em>n</em>! by computing (<em>n</em> -
+ 1)! and multiplying the result by <em>n</em>. If we add the
+ stipulation that 1! is equal to 1, this observation translates
+ directly into a procedure:</p>
+
+ <p><tt><a name="%_idx_642"></a>(define&nbsp;(factorial&nbsp;n)<br />
+ &nbsp;&nbsp;(if&nbsp;(=&nbsp;n&nbsp;1)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(*&nbsp;n&nbsp;(factorial&nbsp;(-&nbsp;n&nbsp;1)))))<br />
+ </tt></p>
+
+ <p><a name="%_idx_644"></a>We can use the substitution model of
+ section&nbsp;<a href="book-Z-H-10.html#%_sec_1.1.5">1.1.5</a> to
+ watch this procedure in action computing 6!, as shown in
+ figure&nbsp;<a href="#%_fig_1.3">1.3</a>.</p>
+
+ <p>Now let's take a different perspective on computing
+ factorials. We could describe a rule for computing <em>n</em>! by
+ specifying that we first multiply 1 by 2, then multiply the
+ result by 3, then by 4, and so on until we reach <em>n</em>. More
+ formally, we maintain a running product, together with a counter
+ that counts from 1 up to <em>n</em>. We can describe the
+ computation by saying that the counter and the product
+ simultaneously change from one step to the next according to the
+ rule</p>
+
+ <p>product <img src="book-Z-G-D-14.gif" border="0" /> counter
+ &middot; product</p>
+
+ <p>counter <img src="book-Z-G-D-14.gif" border="0" /> counter +
+ 1</p>
+
+ <p>and stipulating that <em>n</em>! is the value of the product
+ when the counter exceeds <em>n</em>.</p>
+
+ <p><a name="%_fig_1.4"></a></p>
+
+ <div align="left">
+ <div align="left">
+ <b>Figure 1.4:</b>&nbsp;&nbsp;A linear iterative process for
+ computing 6!.
+ </div>
+
+ <table width="100%">
+ <tr>
+ <td><img src="ch1-Z-G-10.gif" border="0" /></td>
+ </tr>
+
+ <tr>
+ <td></td>
+ </tr>
+ </table>
+ </div>
+
+ <p>Once again, we can recast our description as a procedure for
+ computing factorials:<a href="#footnote_Temp_46" name="call_footnote_Temp_46" id="call_footnote_Temp_46"><sup><small>29</small></sup></a></p>
+
+ <p><tt><a name="%_idx_646"></a>(define&nbsp;(factorial&nbsp;n)<br />
+ &nbsp;&nbsp;(fact-iter&nbsp;1&nbsp;1&nbsp;n))<br />
+ <br />
+ (define&nbsp;(fact-iter&nbsp;product&nbsp;counter&nbsp;max-count)<br />
+
+ &nbsp;&nbsp;(if&nbsp;(&gt;&nbsp;counter&nbsp;max-count)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;product<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(fact-iter&nbsp;(*&nbsp;counter&nbsp;product)<br />
+
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(+&nbsp;counter&nbsp;1)<br />
+
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;max-count)))<br />
+ </tt></p>
+
+ <p>As before, we can use the substitution model to visualize the
+ process of computing 6!, as shown in figure&nbsp;<a href="#%_fig_1.4">1.4</a>.</p>
+
+ <p>Compare the two processes. From one point of view, they seem
+ hardly different at all. Both compute the same mathematical
+ function on the same domain, and each requires a number of steps
+ proportional to <em>n</em> to compute <em>n</em>!. Indeed, both
+ processes even carry out the same sequence of multiplications,
+ obtaining the same sequence of partial products. On the other
+ hand, when we consider the <a name="%_idx_648"></a><a name="%_idx_650"></a>``shapes'' of the two processes, we find that
+ they evolve quite differently.</p>
+