Structure andInterpretationof Computer ProgramsHarold Abelson andGerald Jay Sussmanwith Julie Sussman foreword by Alan J. PerlisUnofﬁcial Texinfo Format 2.andresraba5.6second edition©1996 by e Massachuses Institute of Technology
Structure and Interpretation of Computer Programs,
second edition
Harold Abelson and Gerald Jay Sussman
with Julie Sussman, foreword by Alan J. Perlis
is work is licensed under a Creative Commons
AributionShareAlike 4.0 International License
( .). Based on a work at mitpress.mit.edu.
e Press
Cambridge, Massachuses
London, England
McGrawHill Book Company
New York, St. Louis, San Francisco,
Montreal, Toronto
Unoﬃcial Texinfo Format 2.andresraba5.6 (February 2, 2016),
based on 2.neilvandyke4 (January 10, 2007).
Contents
Unoﬃcial Texinfo Format
Dedication
Foreword
Preface to the Second Edition
Preface to the First Edition
Anowledgments
ix
xii
xiii
xix
xxi
xxv
.
.
.
.
.
.
.
.
Expressions .
1 Building Abstractions with Procedures
.
.
1.1 e Elements of Programming .
.
1
6
.
7
1.1.1
.
10
1.1.2 Naming and the Environment .
12
.
1.1.3
1.1.4
15
.
1.1.5 e Substitution Model for Procedure Application 18
22
1.1.6
1.1.7
28
Conditional Expressions and Predicates
.
Example: Square Roots by Newton’s Method .
Evaluating Combinations
Compound Procedures .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iii
1.2
1.3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Exponentiation .
Linear Recursion and Iteration .
.
Tree Recursion .
.
.
.
Example: Testing for Primality .
1.1.8
Procedures as BlackBox Abstractions
Procedures and the Processes ey Generate .
1.2.1
.
.
.
1.2.2
.
.
.
1.2.3 Orders of Growth .
.
1.2.4
.
.
.
1.2.5 Greatest Common Divisors
1.2.6
.
Formulating Abstractions
.
with HigherOrder Procedures .
Procedures as Arguments
1.3.1
.
Constructing Procedures Using lambda .
1.3.2
.
Procedures as General Methods .
1.3.3
1.3.4
Procedures as Returned Values
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Building Abstractions with Data
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2.1
.
.
.
.
.
Introduction to Data Abstraction .
2.1.1
.
Example: Arithmetic Operations
.
for Rational Numbers .
.
.
.
.
2.1.2 Abstraction Barriers
.
2.1.3 What Is Meant by Data? .
2.1.4
.
.
.
Extended Exercise: Interval Arithmetic .
.
.
.
.
.
.
.
2.2 Hierarchical Data and the Closure Property .
.
.
Sequences as Conventional Interfaces
.
Example: A Picture Language .
.
.
.
.
2.2.1
2.2.2 Hierarchical Structures .
2.2.3
2.2.4
Symbolic Data .
.
2.3.1 otation .
Representing Sequences .
.
2.3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
40
41
47
54
57
62
65
74
76
83
89
97
107
112
113
118
122
126
132
134
147
154
172
192
192
iv
.
.
.
.
.
.
.
2.3.2
2.3.3
2.3.4
Example: Symbolic Diﬀerentiation .
Example: Representing Sets .
.
Example: Huﬀman Encoding Trees .
2.4 Multiple Representations for Abstract Data .
.
.
.
.
Representations for Complex Numbers .
Tagged data .
.
.
.
.
.
.
2.4.1
.
2.4.2
2.4.3 DataDirected Programming and Additivity .
.
Systems with Generic Operations .
.
.
2.5.1 Generic Arithmetic Operations .
2.5.2
.
.
2.5.3
.
.
Combining Data of Diﬀerent Types .
.
Example: Symbolic Algebra .
.
.
.
.
.
.
.
.
.
.
.
.
2.5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Modularity, Objects, and State
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.1 Assignment and Local State
3.2 e Environment Model of Evaluation .
.
.
.
Local State Variables .
3.2.1 e Rules for Evaluation .
.
3.2.2 Applying Simple Procedures .
3.2.3
3.2.4
.
3.1.1
.
3.1.2 e Beneﬁts of Introducing Assignment
3.1.3 e Costs of Introducing Assignment .
.
.
.
Frames as the Repository of Local State
.
Internal Deﬁnitions .
.
.
.
.
.
.
.
.
.
.
.
.
3.3.1 Mutable List Structure .
.
.
3.3.2
3.3.3
.
.
3.3.4 A Simulator for Digital Circuits .
3.3.5
.
.
Representing eues .
Representing Tables
.
.
3.4 Concurrency: Time Is of the Essence .
.
3.3 Modeling with Mutable Data .
Propagation of Constraints
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
197
205
218
229
232
237
242
254
255
262
274
294
296
297
305
311
320
322
327
330
337
341
342
353
360
369
386
401
3.5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.4.1 e Nature of Time in Concurrent Systems
3.4.2 Mechanisms for Controlling Concurrency .
.
.
.
Streams .
.
.
.
Streams Are Delayed Lists .
.
3.5.1
.
Inﬁnite Streams .
.
.
.
3.5.2
.
Exploiting the Stream Paradigm .
3.5.3
.
3.5.4
.
Streams and Delayed Evaluation .
3.5.5 Modularity of Functional Programs
.
and Modularity of Objects .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
403
410
428
430
441
453
470
479
4 Metalinguistic Abstraction
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.1 e Metacircular Evaluator .
.
.
.
4.1.1 e Core of the Evaluator .
.
4.1.2
Representing Expressions .
Evaluator Data Structures .
4.1.3
.
Running the Evaluator as a Program .
4.1.4
4.1.5 Data as Programs .
.
4.1.6
.
4.1.7
.
.
.
.
.
.
.
Internal Deﬁnitions .
.
Separating Syntactic Analysis from Execution .
.
.
.
.
487
492
495
501
512
518
522
526
534
541
542
544
555
4.3 Variations on a Scheme — Nondeterministic Computing 559
561
567
578
594
599
4.3.1 Amb and Search .
.
4.3.2
Examples of Nondeterministic Programs .
.
4.3.3
Implementing the amb Evaluator
Logic Programming .
.
.
.
4.4.1 Deductive Information Retrieval
.
4.2.1 Normal Order and Applicative Order .
4.2.2 An Interpreter with Lazy Evaluation .
4.2.3
.
4.2 Variations on a Scheme — Lazy Evaluation .
Streams as Lazy Lists .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vi
.
.
.
.
.
4.4.2 How the ery System Works
4.4.3
4.4.4
.
Is Logic Programming Mathematical Logic? .
Implementing the ery System .
.
4.4.4.1 e Driver Loop and Instantiation .
4.4.4.2 e Evaluator .
.
4.4.4.3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Finding Assertions
by Paern Matching .
Rules and Uniﬁcation .
.
4.4.4.4
.
4.4.4.5 Maintaining the Data Base .
.
4.4.4.6
.
.
4.4.4.7 ery Syntax Procedures .
4.4.4.8
.
.
Frames and Bindings .
Stream Operations
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Computing with Register Maines
5.1 Designing Register Machines .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.2 A RegisterMachine Simulator .
.
.
.
5.1.1 A Language for Describing Register Machines .
5.1.2 Abstraction in Machine Design .
.
.
5.1.3
.
.
5.1.4
.
5.1.5
.
.
.
.
Subroutines .
.
Using a Stack to Implement Recursion .
.
Instruction Summary .
.
.
.
.
.
.
5.2.1 e Machine Model .
5.2.2 e Assembler
.
.
5.2.3 Generating Execution Procedures
.
.
.
5.2.4 Monitoring Machine Performance
.
.
Storage Allocation and Garbage Collection .
.
5.3.1 Memory as Vectors .
.
.
5.3.2 Maintaining the Illusion of Inﬁnite Memory .
for Instructions .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vii
615
627
635
636
638
642
645
651
654
656
659
666
668
672
678
681
686
695
696
698
704
708
718
723
724
731
.
.
.
.
.
.
.
.
.
.
.
.
.
741
743
751
756
759
767
772
779
788
797
802
817
823
834
844
846
848
855
5.5 Compilation .
5.4 e ExplicitControl Evaluator .
.
.
.
.
.
.
.
.
.
.
.
.
.
5.4.1 e Core of the ExplicitControl Evaluator .
5.4.2
.
5.4.3
5.4.4
.
.
.
Sequence Evaluation and Tail Recursion .
Conditionals, Assignments, and Deﬁnitions .
.
.
Running the Evaluator .
.
.
.
.
.
Structure of the Compiler
.
.
Compiling Expressions .
.
Compiling Combinations
.
Combining Instruction Sequences .
.
.
.
Lexical Addressing .
.
.
Interfacing Compiled Code to the Evaluator .
5.5.1
5.5.2
5.5.3
5.5.4
5.5.5 An Example of Compiled Code .
5.5.6
.
5.5.7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
References
List of Exercises
List of Figures
Index
Colophon
viii
Unoﬀicial Texinfo Format
is is the second edition book, from Unoﬃcial Texinfo Format.
You are probably reading it in an Info hypertext browser, such as the
Info mode of Emacs. You might alternatively be reading it TEXformaed
on your screen or printer, though that would be silly. And, if printed,
expensive.
e freelydistributed oﬃcial and format was ﬁrst con
verted personally to Unoﬃcial Texinfo Format () version 1 by Lytha
Ayth during a long Emacs lovefest weekend in April, 2001.
e is easier to search than the format. It is also much
more accessible to people running on modest computers, such as do
nated ’386based PCs. A 386 can, in theory, run Linux, Emacs, and a
Scheme interpreter simultaneously, but most 386s probably can’t also
run both Netscape and the necessary X Window System without prema
turely introducing budding young underfunded hackers to the concept
of thrashing. can also ﬁt uncompressed on a 1.44 ﬂoppy diskee,
which may come in handy for installing on PCs that do not have
Internet or access.
e Texinfo conversion has been a straight transliteration, to the
extent possible. Like the TEXto conversion, this was not without
some introduction of breakage. In the case of Unoﬃcial Texinfo Format,
ix
ﬁgures have suﬀered an amateurish resurrection of the lost art of .
Also, it’s quite possible that some errors of ambiguity were introduced
during the conversion of some of the copious superscripts (‘ˆ’) and sub
scripts (‘_’). Divining which has been le as an exercise to the reader.
But at least we don’t put our brave astronauts at risk by encoding the
greaterthanorequal symbol as >.
If you modify sicp.texi to correct errors or improve the art,
then update the @set utfversion 2.andresraba5.6 line to reﬂect your
delta. For example, if you started with Lytha’s version 1, and your name
is Bob, then you could name your successive versions 1.bob1, 1.bob2,
: : : 1.bobn. Also update utfversiondate. If you want to distribute your
version on the Web, then embedding the string “sicp.texi” somewhere
in the ﬁle or Web page will make it easier for people to ﬁnd with Web
search engines.
It is believed that the Unoﬃcial Texinfo Format is in keeping with
the spirit of the graciously freelydistributed version. But you
never know when someone’s armada of lawyers might need something
to do, and get their shorts all in a knot over some benign lile thing,
so think twice before you use your full name or distribute Info, ,
PostScript, or formats that might embed your account or machine
name.
Peath, Lytha Ayth
Addendum: See also the video lectures by Abelson and Sussman:
at or .
Second Addendum: Above is the original introduction to the from
2001. Ten years later, has been transformed: mathematical symbols
and formulas are properly typeset, and ﬁgures drawn in vector graph
ics. e original text formulas and art ﬁgures are still there in
x
the Texinfo source, but will display only when compiled to Info output.
At the dawn of ebook readers and tablets, reading a on screen is
oﬃcially not silly anymore. Enjoy!
A.R, May, 2011
xi
Dedication
T , in respect and admiration, to the spirit that
lives in the computer.
“I think that it’s extraordinarily important that we in com
puter science keep fun in computing. When it started out,
it was an awful lot of fun. Of course, the paying customers
got shaed every now and then, and aer a while we began
to take their complaints seriously. We began to feel as if we
really were responsible for the successful, errorfree perfect
use of these machines. I don’t think we are. I think we’re
responsible for stretching them, seing them oﬀ in new di
rections, and keeping fun in the house. I hope the ﬁeld of
computer science never loses its sense of fun. Above all, I
hope we don’t become missionaries. Don’t feel as if you’re
Bible salesmen. e world has too many of those already.
What you know about computing other people will learn.
Don’t feel as if the key to successful computing is only in
your hands. What’s in your hands, I think and hope, is in
telligence: the ability to see the machine as more than when
you were ﬁrst led up to it, that you can make it more.”
—Alan J. Perlis (April 1, 1922 – February 7, 1990)
xii
Foreword
E, , , psychologists, and parents pro
gram. Armies, students, and some societies are programmed. An
assault on large problems employs a succession of programs, most of
which spring into existence en route. ese programs are rife with is
sues that appear to be particular to the problem at hand. To appreciate
programming as an intellectual activity in its own right you must turn to
computer programming; you must read and write computer programs—
many of them. It doesn’t maer much what the programs are about or
what applications they serve. What does maer is how well they per
form and how smoothly they ﬁt with other programs in the creation
of still greater programs. e programmer must seek both perfection
of part and adequacy of collection. In this book the use of “program” is
focused on the creation, execution, and study of programs wrien in a
dialect of Lisp for execution on a digital computer. Using Lisp we re
strict or limit not what we may program, but only the notation for our
program descriptions.
Our traﬃc with the subject maer of this book involves us with
three foci of phenomena: the human mind, collections of computer pro
grams, and the computer. Every computer program is a model, hatched
in the mind, of a real or mental process. ese processes, arising from
xiii
human experience and thought, are huge in number, intricate in de
tail, and at any time only partially understood. ey are modeled to our
permanent satisfaction rarely by our computer programs. us even
though our programs are carefully handcraed discrete collections of
symbols, mosaics of interlocking functions, they continually evolve: we
change them as our perception of the model deepens, enlarges, gen
eralizes until the model ultimately aains a metastable place within
still another model with which we struggle. e source of the exhilara
tion associated with computer programming is the continual unfolding
within the mind and on the computer of mechanisms expressed as pro
grams and the explosion of perception they generate. If art interprets
our dreams, the computer executes them in the guise of programs!
For all its power, the computer is a harsh taskmaster. Its programs
must be correct, and what we wish to say must be said accurately in ev
ery detail. As in every other symbolic activity, we become convinced of
program truth through argument. Lisp itself can be assigned a seman
tics (another model, by the way), and if a program’s function can be
speciﬁed, say, in the predicate calculus, the proof methods of logic can
be used to make an acceptable correctness argument. Unfortunately, as
programs get large and complicated, as they almost always do, the ade
quacy, consistency, and correctness of the speciﬁcations themselves be
come open to doubt, so that complete formal arguments of correctness
seldom accompany large programs. Since large programs grow from
small ones, it is crucial that we develop an arsenal of standard program
structures of whose correctness we have become sure—we call them
idioms—and learn to combine them into larger structures using orga
nizational techniques of proven value. ese techniques are treated at
length in this book, and understanding them is essential to participation
in the Promethean enterprise called programming. More than anything
xiv
else, the uncovering and mastery of powerful organizational techniques
accelerates our ability to create large, signiﬁcant programs. Conversely,
since writing large programs is very taxing, we are stimulated to invent
new methods of reducing the mass of function and detail to be ﬁed
into large programs.
Unlike programs, computers must obey the laws of physics. If they
wish to perform rapidly—a few nanoseconds per state change—they
must transmit electrons only small distances (at most 1 1
2 feet). e heat
generated by the huge number of devices so concentrated in space has to
be removed. An exquisite engineering art has been developed balancing
between multiplicity of function and density of devices. In any event,
hardware always operates at a level more primitive than that at which
we care to program. e processes that transform our Lisp programs
to “machine” programs are themselves abstract models which we pro
gram. eir study and creation give a great deal of insight into the or
ganizational programs associated with programming arbitrary models.
Of course the computer itself can be so modeled. ink of it: the behav
ior of the smallest physical switching element is modeled by quantum
mechanics described by diﬀerential equations whose detailed behavior
is captured by numerical approximations represented in computer pro
grams executing on computers composed of : : :!
It is not merely a maer of tactical convenience to separately iden
tify the three foci. Even though, as they say, it’s all in the head, this
logical separation induces an acceleration of symbolic traﬃc between
these foci whose richness, vitality, and potential is exceeded in human
experience only by the evolution of life itself. At best, relationships be
tween the foci are metastable. e computers are never large enough or
fast enough. Each breakthrough in hardware technology leads to more
massive programming enterprises, new organizational principles, and
xv
an enrichment of abstract models. Every reader should ask himself pe
riodically “Toward what end, toward what end?”—but do not ask it too
oen lest you pass up the fun of programming for the constipation of
biersweet philosophy.
Among the programs we write, some (but never enough) perform a
precise mathematical function such as sorting or ﬁnding the maximum
of a sequence of numbers, determining primality, or ﬁnding the square
root. We call such programs algorithms, and a great deal is known of
their optimal behavior, particularly with respect to the two important
parameters of execution time and data storage requirements. A pro
grammer should acquire good algorithms and idioms. Even though some
programs resist precise speciﬁcations, it is the responsibility of the pro
grammer to estimate, and always to aempt to improve, their perfor
mance.
Lisp is a survivor, having been in use for about a quarter of a cen
tury. Among the active programming languages only Fortran has had
a longer life. Both languages have supported the programming needs
of important areas of application, Fortran for scientiﬁc and engineering
computation and Lisp for artiﬁcial intelligence. ese two areas con
tinue to be important, and their programmers are so devoted to these
two languages that Lisp and Fortran may well continue in active use for
at least another quartercentury.
Lisp changes. e Scheme dialect used in this text has evolved from
the original Lisp and diﬀers from the laer in several important ways,
including static scoping for variable binding and permiing functions to
yield functions as values. In its semantic structure Scheme is as closely
akin to Algol 60 as to early Lisps. Algol 60, never to be an active language
again, lives on in the genes of Scheme and Pascal. It would be diﬃcult
to ﬁnd two languages that are the communicating coin of two more dif
xvi
ferent cultures than those gathered around these two languages. Pas
cal is for building pyramids—imposing, breathtaking, static structures
built by armies pushing heavy blocks into place. Lisp is for building
organisms—imposing, breathtaking, dynamic structures built by squads
ﬁing ﬂuctuating myriads of simpler organisms into place. e organiz
ing principles used are the same in both cases, except for one extraordi
narily important diﬀerence: e discretionary exportable functionality
entrusted to the individual Lisp programmer is more than an order of
magnitude greater than that to be found within Pascal enterprises. Lisp
programs inﬂate libraries with functions whose utility transcends the
application that produced them. e list, Lisp’s native data structure, is
largely responsible for such growth of utility. e simple structure and
natural applicability of lists are reﬂected in functions that are amazingly
nonidiosyncratic. In Pascal the plethora of declarable data structures in
duces a specialization within functions that inhibits and penalizes ca
sual cooperation. It is beer to have 100 functions operate on one data
structure than to have 10 functions operate on 10 data structures. As a
result the pyramid must stand unchanged for a millennium; the organ
ism must evolve or perish.
To illustrate this diﬀerence, compare the treatment of material and
exercises within this book with that in any ﬁrstcourse text using Pascal.
Do not labor under the illusion that this is a text digestible at only,
peculiar to the breed found there. It is precisely what a serious book on
programming Lisp must be, no maer who the student is or where it is
used.
Note that this is a text about programming, unlike most Lisp books,
which are used as a preparation for work in artiﬁcial intelligence. Aer
all, the critical programming concerns of soware engineering and ar
tiﬁcial intelligence tend to coalesce as the systems under investigation
xvii
become larger. is explains why there is such growing interest in Lisp
outside of artiﬁcial intelligence.
As one would expect from its goals, artiﬁcial intelligence research
generates many signiﬁcant programming problems. In other program
ming cultures this spate of problems spawns new languages. Indeed, in
any very large programming task a useful organizing principle is to con
trol and isolate traﬃc within the task modules via the invention of lan
guage. ese languages tend to become less primitive as one approaches
the boundaries of the system where we humans interact most oen. As
a result, such systems contain complex languageprocessing functions
replicated many times. Lisp has such a simple syntax and semantics that
parsing can be treated as an elementary task. us parsing technology
plays almost no role in Lisp programs, and the construction of language
processors is rarely an impediment to the rate of growth and change of
large Lisp systems. Finally, it is this very simplicity of syntax and se
mantics that is responsible for the burden and freedom borne by all
Lisp programmers. No Lisp program of any size beyond a few lines can
be wrien without being saturated with discretionary functions. Invent
and ﬁt; have ﬁts and reinvent! We toast the Lisp programmer who pens
his thoughts within nests of parentheses.
Alan J. Perlis
New Haven, Connecticut
xviii
Preface to the Second Edition
Is it possible that soware is not like anything else, that it
is meant to be discarded: that the whole point is to always
see it as a soap bubble?
—Alan J. Perlis
T has been the basis of ’s entrylevel
computer science subject since 1980. We had been teaching this ma
terial for four years when the ﬁrst edition was published, and twelve
more years have elapsed until the appearance of this second edition.
We are pleased that our work has been widely adopted and incorpo
rated into other texts. We have seen our students take the ideas and
programs in this book and build them in as the core of new computer
systems and languages. In literal realization of an ancient Talmudic pun,
our students have become our builders. We are lucky to have such ca
pable students and such accomplished builders.
In preparing this edition, we have incorporated hundreds of clariﬁ
cations suggested by our own teaching experience and the comments of
colleagues at and elsewhere. We have redesigned most of the ma
jor programming systems in the book, including the genericarithmetic
system, the interpreters, the registermachine simulator, and the com
piler; and we have rewrien all the program examples to ensure that
xix
any Scheme implementation conforming to the Scheme standard
(IEEE 1990) will be able to run the code.
is edition emphasizes several new themes. e most important of
these is the central role played by diﬀerent approaches to dealing with
time in computational models: objects with state, concurrent program
ming, functional programming, lazy evaluation, and nondeterministic
programming. We have included new sections on concurrency and non
determinism, and we have tried to integrate this theme throughout the
book.
e ﬁrst edition of the book closely followed the syllabus of our
onesemester subject. With all the new material in the second edi
tion, it will not be possible to cover everything in a single semester,
so the instructor will have to pick and choose. In our own teaching, we
sometimes skip the section on logic programming (Section 4.4), we have
students use the registermachine simulator but we do not cover its im
plementation (Section 5.2), and we give only a cursory overview of the
compiler (Section 5.5). Even so, this is still an intense course. Some in
structors may wish to cover only the ﬁrst three or four chapters, leaving
the other material for subsequent courses.
e WorldWideWeb site hp://mitpress.mit.edu/sicp provides sup
port for users of this book. is includes programs from the book, sam
ple programming assignments, supplementary materials, and download
able implementations of the Scheme dialect of Lisp.
xx
Preface to the First Edition
A computer is like a violin. You can imagine a novice try
ing ﬁrst a phonograph and then a violin. e laer, he says,
sounds terrible. at is the argument we have heard from
our humanists and most of our computer scientists. Com
puter programs are good, they say, for particular purposes,
but they aren’t ﬂexible. Neither is a violin, or a typewriter,
until you learn how to use it.
—Marvin Minsky, “Why Programming Is a Good Medium
for Expressing PoorlyUnderstood and SloppilyFormulated
Ideas”
“T S I C P”
is the entrylevel subject in computer science at the Massachuses
Institute of Technology. It is required of all students at who major
in electrical engineering or in computer science, as onefourth of the
“common core curriculum,” which also includes two subjects on circuits
and linear systems and a subject on the design of digital systems. We
have been involved in the development of this subject since 1978, and
we have taught this material in its present form since the fall of 1980 to
between 600 and 700 students each year. Most of these students have
xxi
had lile or no prior formal training in computation, although many
have played with computers a bit and a few have had extensive pro
gramming or hardwaredesign experience.
Our design of this introductory computerscience subject reﬂects
two major concerns. First, we want to establish the idea that a com
puter language is not just a way of geing a computer to perform oper
ations but rather that it is a novel formal medium for expressing ideas
about methodology. us, programs must be wrien for people to read,
and only incidentally for machines to execute. Second, we believe that
the essential material to be addressed by a subject at this level is not
the syntax of particular programminglanguage constructs, nor clever
algorithms for computing particular functions eﬃciently, nor even the
mathematical analysis of algorithms and the foundations of computing,
but rather the techniques used to control the intellectual complexity of
large soware systems.
Our goal is that students who complete this subject should have a
good feel for the elements of style and the aesthetics of programming.
ey should have command of the major techniques for controlling
complexity in a large system. ey should be capable of reading a 50
pagelong program, if it is wrien in an exemplary style. ey should
know what not to read, and what they need not understand at any mo
ment. ey should feel secure about modifying a program, retaining the
spirit and style of the original author.
ese skills are by no means unique to computer programming. e
techniques we teach and draw upon are common to all of engineering
design. We control complexity by building abstractions that hide details
when appropriate. We control complexity by establishing conventional
interfaces that enable us to construct systems by combining standard,
wellunderstood pieces in a “mix and match” way. We control complex
xxii
ity by establishing new languages for describing a design, each of which
emphasizes particular aspects of the design and deemphasizes others.
Underlying our approach to this subject is our conviction that “com
puter science” is not a science and that its signiﬁcance has lile to do
with computers. e computer revolution is a revolution in the way we
think and in the way we express what we think. e essence of this
change is the emergence of what might best be called procedural epis
temology—the study of the structure of knowledge from an imperative
point of view, as opposed to the more declarative point of view taken
by classical mathematical subjects. Mathematics provides a framework
for dealing precisely with notions of “what is.” Computation provides a
framework for dealing precisely with notions of “how to.”
In teaching our material we use a dialect of the programming lan
guage Lisp. We never formally teach the language, because we don’t
have to. We just use it, and students pick it up in a few days. is is
one great advantage of Lisplike languages: ey have very few ways
of forming compound expressions, and almost no syntactic structure.
All of the formal properties can be covered in an hour, like the rules
of chess. Aer a short time we forget about syntactic details of the lan
guage (because there are none) and get on with the real issues—ﬁguring
out what we want to compute, how we will decompose problems into
manageable parts, and how we will work on the parts. Another advan
tage of Lisp is that it supports (but does not enforce) more of the large
scale strategies for modular decomposition of programs than any other
language we know. We can make procedural and data abstractions, we
can use higherorder functions to capture common paerns of usage,
we can model local state using assignment and data mutation, we can
link parts of a program with streams and delayed evaluation, and we can
easily implement embedded languages. All of this is embedded in an in
xxiii
teractive environment with excellent support for incremental program
design, construction, testing, and debugging. We thank all the genera
tions of Lisp wizards, starting with John McCarthy, who have fashioned
a ﬁne tool of unprecedented power and elegance.
Scheme, the dialect of Lisp that we use, is an aempt to bring to
gether the power and elegance of Lisp and Algol. From Lisp we take the
metalinguistic power that derives from the simple syntax, the uniform
representation of programs as data objects, and the garbagecollected
heapallocated data. From Algol we take lexical scoping and block struc
ture, which are gis from the pioneers of programminglanguage de
sign who were on the Algol commiee. We wish to cite John Reynolds
and Peter Landin for their insights into the relationship of Church’s λ
calculus to the structure of programming languages. We also recognize
our debt to the mathematicians who scouted out this territory decades
before computers appeared on the scene. ese pioneers include Alonzo
Church, Barkley Rosser, Stephen Kleene, and Haskell Curry.
xxiv
Acknowledgments
W the many people who have helped us
develop this book and this curriculum.
Our subject is a clear intellectual descendant of “6.231,” a wonderful
subject on programming linguistics and the λcalculus taught at in
the late 1960s by Jack Wozencra and Arthur Evans, Jr.
We owe a great debt to Robert Fano, who reorganized ’s intro
ductory curriculum in electrical engineering and computer science to
emphasize the principles of engineering design. He led us in starting
out on this enterprise and wrote the ﬁrst set of subject notes from which
this book evolved.
Much of the style and aesthetics of programming that we try to
teach were developed in conjunction with Guy Lewis Steele Jr., who
collaborated with Gerald Jay Sussman in the initial development of the
Scheme language. In addition, David Turner, Peter Henderson, Dan Fried
man, David Wise, and Will Clinger have taught us many of the tech
niques of the functional programming community that appear in this
book.
Joel Moses taught us about structuring large systems. His experi
ence with the Macsyma system for symbolic computation provided the
insight that one should avoid complexities of control and concentrate
xxv
on organizing the data to reﬂect the real structure of the world being
modeled.
Marvin Minsky and Seymour Papert formed many of our aitudes
about programming and its place in our intellectual lives. To them we
owe the understanding that computation provides a means of expres
sion for exploring ideas that would otherwise be too complex to deal
with precisely. ey emphasize that a student’s ability to write and
modify programs provides a powerful medium in which exploring be
comes a natural activity.
We also strongly agree with Alan Perlis that programming is lots of
fun and we had beer be careful to support the joy of programming. Part
of this joy derives from observing great masters at work. We are fortu
nate to have been apprentice programmers at the feet of Bill Gosper and
Richard Greenbla.
It is diﬃcult to identify all the people who have contributed to the
development of our curriculum. We thank all the lecturers, recitation
instructors, and tutors who have worked with us over the past ﬁeen
years and put in many extra hours on our subject, especially Bill Siebert,
Albert Meyer, Joe Stoy, Randy Davis, Louis Braida, Eric Grimson, Rod
Brooks, Lynn Stein and Peter Szolovits. We would like to specially ac
knowledge the outstanding teaching contributions of Franklyn Turbak,
now at Wellesley; his work in undergraduate instruction set a standard
that we can all aspire to. We are grateful to Jerry Saltzer and Jim Miller
for helping us grapple with the mysteries of concurrency, and to Peter
Szolovits and David McAllester for their contributions to the exposition
of nondeterministic evaluation in Chapter 4.
Many people have put in signiﬁcant eﬀort presenting this material
at other universities. Some of the people we have worked closely with
are Jacob Katzenelson at the Technion, Hardy Mayer at the University
xxvi
of California at Irvine, Joe Stoy at Oxford, Elisha Sacks at Purdue, and
Jan Komorowski at the Norwegian University of Science and Technol
ogy. We are exceptionally proud of our colleagues who have received
major teaching awards for their adaptations of this subject at other uni
versities, including Kenneth Yip at Yale, Brian Harvey at the University
of California at Berkeley, and Dan Huenlocher at Cornell.
Al Moyé arranged for us to teach this material to engineers at Hewle
Packard, and for the production of videotapes of these lectures. We
would like to thank the talented instructors—in particular Jim Miller,
Bill Siebert, and Mike Eisenberg—who have designed continuing edu
cation courses incorporating these tapes and taught them at universities
and industry all over the world.
Many educators in other countries have put in signiﬁcant work
translating the ﬁrst edition. Michel Briand, Pierre Chamard, and An
dré Pic produced a French edition; Susanne DanielsHerold produced
a German edition; and Fumio Motoyoshi produced a Japanese edition.
We do not know who produced the Chinese edition, but we consider
it an honor to have been selected as the subject of an “unauthorized”
translation.
It is hard to enumerate all the people who have made technical con
tributions to the development of the Scheme systems we use for in
structional purposes. In addition to Guy Steele, principal wizards have
included Chris Hanson, Joe Bowbeer, Jim Miller, Guillermo Rozas, and
Stephen Adams. Others who have put in signiﬁcant time are Richard
Stallman, Alan Bawden, Kent Pitman, Jon Ta, Neil Mayle, John Lamp
ing, Gwyn Osnos, Tracy Larrabee, George Carree, Soma Chaudhuri,
Bill Chiarchiaro, Steven Kirsch, Leigh Klotz, Wayne Noss, Todd Cass,
Patrick O’Donnell, Kevin eobald, Daniel Weise, Kenneth Sinclair, An
thony Courtemanche, Henry M. Wu, Andrew Berlin, and Ruth Shyu.
xxvii
Beyond the implementation, we would like to thank the many
people who worked on the Scheme standard, including William
Clinger and Jonathan Rees, who edited the R4RS, and Chris Haynes,
David Bartley, Chris Hanson, and Jim Miller, who prepared the
standard.
Dan Friedman has been a longtime leader of the Scheme commu
nity. e community’s broader work goes beyond issues of language
design to encompass signiﬁcant educational innovations, such as the
highschool curriculum based on EdScheme by Schemer’s Inc., and the
wonderful books by Mike Eisenberg and by Brian Harvey and Mahew
Wright.
We appreciate the work of those who contributed to making this a
real book, especially Terry Ehling, Larry Cohen, and Paul Bethge at the
Press. Ella Mazel found the wonderful cover image. For the second
edition we are particularly grateful to Bernard and Ella Mazel for help
with the book design, and to David Jones, TEX wizard extraordinaire.
We also are indebted to those readers who made penetrating comments
on the new dra: Jacob Katzenelson, Hardy Mayer, Jim Miller, and es
pecially Brian Harvey, who did unto this book as Julie did unto his book
Simply Scheme.
Finally, we would like to acknowledge the support of the organiza
tions that have encouraged this work over the years, including support
from HewlePackard, made possible by Ira Goldstein and Joel Birn
baum, and support from , made possible by Bob Kahn.
xxviii
Building Abstractions with Procedures
e acts of the mind, wherein it exerts its power over simple
ideas, are chieﬂy these three: 1. Combining several simple
ideas into one compound one, and thus all complex ideas
are made. 2. e second is bringing two ideas, whether sim
ple or complex, together, and seing them by one another
so as to take a view of them at once, without uniting them
into one, by which it gets all its ideas of relations. 3. e
third is separating them from all other ideas that accom
pany them in their real existence: this is called abstraction,
and thus all its general ideas are made.
—John Locke, An Essay Concerning Human Understanding
(1690)
W the idea of a computational process. Com
putational processes are abstract beings that inhabit computers.
As they evolve, processes manipulate other abstract things called data.
1
e evolution of a process is directed by a paern of rules called a pro
gram. People create programs to direct processes. In eﬀect, we conjure
the spirits of the computer with our spells.
A computational process is indeed much like a sorcerer’s idea of a
spirit. It cannot be seen or touched. It is not composed of maer at all.
However, it is very real. It can perform intellectual work. It can answer
questions. It can aﬀect the world by disbursing money at a bank or by
controlling a robot arm in a factory. e programs we use to conjure
processes are like a sorcerer’s spells. ey are carefully composed from
symbolic expressions in arcane and esoteric programming languages that
prescribe the tasks we want our processes to perform.
A computational process, in a correctly working computer, executes
programs precisely and accurately. us, like the sorcerer’s appren
tice, novice programmers must learn to understand and to anticipate
the consequences of their conjuring. Even small errors (usually called
bugs or glitches) in programs can have complex and unanticipated con
sequences.
Fortunately, learning to program is considerably less dangerous than
learning sorcery, because the spirits we deal with are conveniently con
tained in a secure way. Realworld programming, however, requires
care, expertise, and wisdom. A small bug in a computeraided design
program, for example, can lead to the catastrophic collapse of an air
plane or a dam or the selfdestruction of an industrial robot.
Master soware engineers have the ability to organize programs so
that they can be reasonably sure that the resulting processes will per
form the tasks intended. ey can visualize the behavior of their sys
tems in advance. ey know how to structure programs so that unan
ticipated problems do not lead to catastrophic consequences, and when
problems do arise, they can debug their programs. Welldesigned com
2
putational systems, like welldesigned automobiles or nuclear reactors,
are designed in a modular manner, so that the parts can be constructed,
replaced, and debugged separately.
Programming in Lisp
We need an appropriate language for describing processes, and we will
use for this purpose the programming language Lisp. Just as our every
day thoughts are usually expressed in our natural language (such as En
glish, French, or Japanese), and descriptions of quantitative phenomena
are expressed with mathematical notations, our procedural thoughts
will be expressed in Lisp. Lisp was invented in the late 1950s as a for
malism for reasoning about the use of certain kinds of logical expres
sions, called recursion equations, as a model for computation. e lan
guage was conceived by John McCarthy and is based on his paper “Re
cursive Functions of Symbolic Expressions and eir Computation by
Machine” (McCarthy 1960).
Despite its inception as a mathematical formalism, Lisp is a practi
cal programming language. A Lisp interpreter is a machine that carries
out processes described in the Lisp language. e ﬁrst Lisp interpreter
was implemented by McCarthy with the help of colleagues and stu
dents in the Artiﬁcial Intelligence Group of the Research Laboratory
of Electronics and in the Computation Center.1 Lisp, whose name
is an acronym for LISt Processing, was designed to provide symbol
manipulating capabilities for aacking programming problems such as
the symbolic diﬀerentiation and integration of algebraic expressions.
It included for this purpose new data objects known as atoms and lists,
1e Lisp 1 Programmer’s Manual appeared in 1960, and the Lisp 1.5 Programmer’s
Manual (McCarthy et al. 1965) was published in 1962. e early history of Lisp is de
scribed in McCarthy 1978.
3
which most strikingly set it apart from all other languages of the period.
Lisp was not the product of a concerted design eﬀort. Instead, it
evolved informally in an experimental manner in response to users’
needs and to pragmatic implementation considerations. Lisp’s informal
evolution has continued through the years, and the community of Lisp
users has traditionally resisted aempts to promulgate any “oﬃcial”
deﬁnition of the language. is evolution, together with the ﬂexibility
and elegance of the initial conception, has enabled Lisp, which is the sec
ond oldest language in widespread use today (only Fortran is older), to
continually adapt to encompass the most modern ideas about program
design. us, Lisp is by now a family of dialects, which, while sharing
most of the original features, may diﬀer from one another in signiﬁcant
ways. e dialect of Lisp used in this book is called Scheme.2
Because of its experimental character and its emphasis on symbol
manipulation, Lisp was at ﬁrst very ineﬃcient for numerical compu
tations, at least in comparison with Fortran. Over the years, however,
2e two dialects in which most major Lisp programs of the 1970s were wrien are
MacLisp (Moon 1978; Pitman 1983), developed at the Project , and Interlisp
(Teitelman 1974), developed at Bolt Beranek and Newman Inc. and the Xerox Palo Alto
Research Center. Portable Standard Lisp (Hearn 1969; Griss 1981) was a Lisp dialect
designed to be easily portable between diﬀerent machines. MacLisp spawned a number
of subdialects, such as Franz Lisp, which was developed at the University of California
at Berkeley, and Zetalisp (Moon and Weinreb 1981), which was based on a special
purpose processor designed at the Artiﬁcial Intelligence Laboratory to run Lisp
very eﬃciently. e Lisp dialect used in this book, called Scheme (Steele and Sussman
1975), was invented in 1975 by Guy Lewis Steele Jr. and Gerald Jay Sussman of the
Artiﬁcial Intelligence Laboratory and later reimplemented for instructional use at .
Scheme became an standard in 1990 (IEEE 1990). e Common Lisp dialect (Steele
1982, Steele 1990) was developed by the Lisp community to combine features from the
earlier Lisp dialects to make an industrial standard for Lisp. Common Lisp became an
standard in 1994 (ANSI 1994).
4
Lisp compilers have been developed that translate programs into ma
chine code that can perform numerical computations reasonably eﬃ
ciently. And for special applications, Lisp has been used with great ef
fectiveness.3 Although Lisp has not yet overcome its old reputation as
hopelessly ineﬃcient, Lisp is now used in many applications where ef
ﬁciency is not the central concern. For example, Lisp has become a lan
guage of choice for operatingsystem shell languages and for extension
languages for editors and computeraided design systems.
If Lisp is not a mainstream language, why are we using it as the
framework for our discussion of programming? Because the language
possesses unique features that make it an excellent medium for studying
important programming constructs and data structures and for relating
them to the linguistic features that support them. e most signiﬁcant of
these features is the fact that Lisp descriptions of processes, called proce
dures, can themselves be represented and manipulated as Lisp data. e
importance of this is that there are powerful programdesign techniques
that rely on the ability to blur the traditional distinction between “pas
sive” data and “active” processes. As we shall discover, Lisp’s ﬂexibility
in handling procedures as data makes it one of the most convenient
languages in existence for exploring these techniques. e ability to
represent procedures as data also makes Lisp an excellent language for
writing programs that must manipulate other programs as data, such as
the interpreters and compilers that support computer languages. Above
and beyond these considerations, programming in Lisp is great fun.
3One such special application was a breakthrough computation of scientiﬁc
importance—an integration of the motion of the Solar System that extended previous
results by nearly two orders of magnitude, and demonstrated that the dynamics of the
Solar System is chaotic. is computation was made possible by new integration al
gorithms, a specialpurpose compiler, and a specialpurpose computer all implemented
with the aid of soware tools wrien in Lisp (Abelson et al. 1992; Sussman and Wisdom
1992).
5
1.1 The Elements of Programming
A powerful programming language is more than just a means for in
structing a computer to perform tasks. e language also serves as a
framework within which we organize our ideas about processes. us,
when we describe a language, we should pay particular aention 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:
• primitive expressions, which represent the simplest entities the
language is concerned with,
• means of combination, by which compound elements are built
from simpler ones, and
• means of abstraction, by which compound elements can be named
and manipulated as units.
In programming, we deal with two kinds of elements: procedures and
data. (Later we will discover that they are really not so distinct.) Infor
mally, data is “stuﬀ” that we want to manipulate, and procedures are
descriptions of the rules for manipulating the data. us, any powerful
programming language should be able to describe primitive data and
primitive procedures and should have methods for combining and ab
stracting procedures and data.
In this chapter we will deal only with simple numerical data so that
we can focus on the rules for building procedures.4 In later chapters we
4e characterization of numbers as “simple data” is a barefaced bluﬀ. In fact, the
treatment of numbers is one of the trickiest and most confusing aspects of any pro
6
will see that these same rules allow us to build procedures to manipulate
compound data as well.
1.1.1 Expressions
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 siing at a computer terminal. You type an expression, and
the interpreter responds by displaying the result of its evaluating that
expression.
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
486
the interpreter will respond by printing5
486
gramming language. Some typical issues involved are these: Some computer systems
distinguish integers, such as 2, from real numbers, such as 2.71. Is the real number 2.00
diﬀerent 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 repre
sent? Is the range of integers the same as the range of real numbers? Above and beyond
these questions, of course, lies a collection of issues concerning roundoﬀ and trunca
tion errors—the entire science of numerical analysis. Since our focus in this book is on
largescale program design rather than on numerical techniques, we are going to ignore
these problems. e numerical examples in this chapter will exhibit the usual roundoﬀ
behavior that one observes when using arithmetic operations that preserve a limited
number of decimal places of accuracy in noninteger operations.
5roughout this book, 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
laer in slanted characters.
7
Expressions representing numbers may be combined with an expres
sion representing a primitive procedure (such as + or *) to form a com
pound expression that represents the application of the procedure to
those numbers. For example:
(+ 137 349)
486
( 1000 334)
666
(* 5 99)
495
(/ 10 5)
2
(+ 2.7 10)
12.7
Expressions such as these, formed by delimiting a list of expressions
within parentheses in order to denote procedure application, are called
combinations. e lemost element in the list is called the operator, and
the other elements are called operands. e value of a combination is
obtained by applying the procedure speciﬁed by the operator to the ar
guments that are the values of the operands.
e convention of placing the operator to the le of the operands
is known as preﬁx notation, and it may be somewhat confusing at ﬁrst
because it departs signiﬁcantly from the customary mathematical con
vention. Preﬁx notation has several advantages, however. One of them
is that it can accommodate procedures that may take an arbitrary num
ber of arguments, as in the following examples:
8
(+ 21 35 12 7)
75
(* 25 4 12)
1200
No ambiguity can arise, because the operator is always the lemost el
ement and the entire combination is delimited by the parentheses.
A second advantage of preﬁx notation is that it extends in a straight
forward way to allow combinations to be nested, that is, to have combi
nations whose elements are themselves combinations:
(+ (* 3 5) ( 10 6))
19
ere is no limit (in principle) to the depth of such nesting and to the
overall complexity of the expressions that the Lisp interpreter can eval
uate. It is we humans who get confused by still relatively simple expres
sions such as
(+ (* 3 (+ (* 2 4) (+ 3 5))) (+ ( 10 7) 6))
which the interpreter would readily evaluate to be 57. We can help our
selves by writing such an expression in the form
(+ (* 3
(+ (* 2 4)
(+ 3 5)))
(+ ( 10 7)
6))
following a formaing convention known as preyprinting, in which
each long combination is wrien so that the operands are aligned ver
tically. e resulting indentations display clearly the structure of the
9
expression.6
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. is mode of operation is oen
expressed by saying that the interpreter runs in a readevalprint loop.
Observe in particular that it is not necessary to explicitly instruct the
interpreter to print the value of the expression.7
1.1.2 Naming and the Environment
A critical aspect of a programming language is the means it provides
for using names to refer to computational objects. We say that the name
identiﬁes a variable whose value is the object.
In the Scheme dialect of Lisp, we name things with define. Typing
(define size 2)
causes the interpreter to associate the value 2 with the name size.8
Once the name size has been associated with the number 2, we can
refer to the value 2 by name:
size
2
6Lisp systems typically provide features to aid the user in formaing expressions.
Two especially useful features are one that automatically indents to the proper prey
print position whenever a new line is started and one that highlights the matching le
parenthesis whenever a right parenthesis is typed.
7Lisp obeys the convention that every expression has a value. is convention, to
gether with the old reputation of Lisp as an ineﬃcient 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.”
8In this book, we do not show the interpreter’s response to evaluating deﬁnitions,
since this is highly implementationdependent.
10
(* 5 size)
10
Here are further examples of the use of define:
(define pi 3.14159)
(define radius 10)
(* pi (* radius radius))
314.159
(define circumference (* 2 pi radius))
circumference
62.8318
define 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 circumference 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 build
ing, step by step, computational objects of increasing complexity. e
interpreter makes this stepbystep program construction particularly
convenient because nameobject associations can be created incremen
tally in successive interactions. is feature encourages the incremental
development and testing of programs and is largely responsible for the
fact that a Lisp program usually consists of a large number of relatively
simple procedures.
It should be clear that the possibility of associating values with sym
bols and later retrieving them means that the interpreter must maintain
some sort of memory that keeps track of the nameobject pairs. is
memory is called the environment (more precisely the global environ
ment, since we will see later that a computation may involve a number
11
of diﬀerent environments).9
1.1.3 Evaluating Combinations
One of our goals in this chapter is to isolate issues about thinking pro
cedurally. As a case in point, let us consider that, in evaluating combi
nations, the interpreter is itself following a procedure.
To evaluate a combination, do the following:
1. Evaluate the subexpressions of the combination.
2. Apply the procedure that is the value of the lemost subexpres
sion (the operator) to the arguments that are the values of the
other subexpressions (the operands).
Even this simple rule illustrates some important points about processes
in general. First, observe that the ﬁrst step dictates that in order to ac
complish the evaluation process for a combination we must ﬁrst per
form the evaluation process on each element of the combination. us,
the evaluation rule is recursive in nature; that is, it includes, as one of
its steps, the need to invoke the rule itself.10
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
9Chapter 3 will show that this notion of environment is crucial, both for under
standing how the interpreter works and for implementing interpreters.
10It may seem strange that the evaluation rule says, as part of the ﬁrst step, that
we should evaluate the lemost element of a combination, since at this point that can
only be an operator such as + or * representing a builtin 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.
12
Figure 1.1: Tree representation, showing the value of each
subcombination.
(* (+ 2 (* 4 6))
(+ 3 5 7))
requires that the evaluation rule be applied to four diﬀerent combina
tions. We can obtain a picture of this process by representing the combi
nation in the form of a tree, as shown in Figure 1.1. Each combination is
represented by a node with branches corresponding to the operator and
the operands of the combination stemming from it. e 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 tree accumulation.
Next, observe that the repeated application of the ﬁrst step brings us
to the point where we need to evaluate, not combinations, but primitive
expressions such as numerals, builtin operators, or other names. We
13
152624239075364+**+take care of the primitive cases by stipulating that
• the values of numerals are the numbers that they name,
• the values of builtin operators are the machine instruction se
quences that carry out the corresponding operations, and
• the values of other names are the objects associated with those
names in the environment.
We may regard the second rule as a special case of the third one by stip
ulating that symbols such as + and * are also included in the global envi
ronment, and are associated with the sequences of machine instructions
that are their “values.” e key point to notice is the role of the environ
ment 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 (+ x 1) without specifying any information
about the environment that would provide a meaning for the symbol
x (or even for the symbol +). As we shall see in Chapter 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.
Notice that the evaluation rule given above does not handle deﬁni
tions. For instance, evaluating (define x 3) does not apply define to
two arguments, one of which is the value of the symbol x and the other
of which is 3, since the purpose of the define is precisely to associate x
with a value. (at is, (define x 3) is not a combination.)
Such exceptions to the general evaluation rule are called special forms.
define is the only example of a special form that we have seen so far,
but we will meet others shortly. Each special form has its own evalu
ation rule. e various kinds of expressions (each with its associated
14
evaluation rule) constitute the 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 de
scribed by a simple general rule together with specialized rules for a
small number of special forms.11
1.1.4 Compound Procedures
We have identiﬁed in Lisp some of the elements that must appear in any
powerful programming language:
• Numbers and arithmetic operations are primitive data and proce
dures.
• Nesting of combinations provides a means of combining opera
tions.
• Deﬁnitions that associate names with values provide a limited
means of abstraction.
Now we will learn about procedure deﬁnitions, a much more powerful
abstraction technique by which a compound operation can be given a
name and then referred to as a unit.
11Special syntactic forms that are simply convenient alternative surface structures
for things that can be wrien in more uniform ways are sometimes called syntactic
sugar, to use a phrase coined by Peter Landin. In comparison with users of other lan
guages, Lisp programmers, as a rule, are less concerned with maers of syntax. (By
contrast, examine any Pascal manual and notice how much of it is devoted to descrip
tions of syntax.) is disdain for syntax is due partly to the ﬂexibility of Lisp, which
makes it easy to change surface syntax, and partly to the observation that many “con
venient” 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.”
15
We begin by examining how to express the idea of “squaring.” We
might say, “To square something, multiply it by itself.” is is expressed
in our language as
(define (square x) (* x x))
We can understand this in the following way:
(define (square

x)

(*

x

x))

square
something, multiply it by
itself.

To
We have here a compound procedure, which has been given the name
square. e procedure represents the operation of multiplying some
thing by itself. e thing to be multiplied is given a local name, x, which
plays the same role that a pronoun plays in natural language. Evaluating
the deﬁnition creates this compound procedure and associates it with
the name square.12
e general form of a procedure deﬁnition is
(define (⟨name⟩ ⟨formal parameters⟩)
⟨body⟩)
e ⟨name⟩ is a symbol to be associated with the procedure deﬁnition in
the environment.13 e ⟨formal parameters⟩ are the names used within
the body of the procedure to refer to the corresponding arguments of
the procedure. e ⟨body⟩ is an expression that will yield the value of
12Observe that there are two diﬀerent operations being combined here: we are creat
ing the procedure, and we are giving it the name square. 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 1.3.2.
13roughout this book, we will describe the general syntax of expressions by using
italic symbols delimited by angle brackets—e.g., ⟨name⟩—to denote the “slots” in the
expression to be ﬁlled in when such an expression is actually used.
16
the procedure application when the formal parameters are replaced by
the actual arguments to which the procedure is applied.14 e ⟨name⟩
and the⟨formal parameters⟩ are grouped within parentheses, just as they
would be in an actual call to the procedure being deﬁned.
Having deﬁned square, we can now use it:
(square 21)
441
(square (+ 2 5))
49
(square (square 3))
81
We can also use square as a building block in deﬁning other procedures.
For example, x 2 + y2 can be expressed as
(+ (square x) (square y))
We can easily deﬁne a procedure sumofsquares that, given any two
numbers as arguments, produces the sum of their squares:
(define (sumofsquares x y)
(+ (square x) (square y)))
(sumofsquares 3 4)
25
Now we can use sumofsquares as a building block in constructing
further procedures:
(define (f a)
(sumofsquares (+ a 1) (* a 2)))
(f 5)
136
14More 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 ﬁnal expression as the value of the procedure application.
17
Compound procedures are used in exactly the same way as primitive
procedures. Indeed, one could not tell by looking at the deﬁnition of
sumofsquares given above whether square was built into the inter
preter, like + and *, or deﬁned as a compound procedure.
1.1.5 The Substitution Model for Procedure Application
To evaluate a combination whose operator names a compound proce
dure, the interpreter follows much the same process as for combina
tions whose operators name primitive procedures, which we described
in Section 1.1.3. at is, the interpreter evaluates the elements of the
combination and applies the procedure (which is the value of the oper
ator of the combination) to the arguments (which are the values of the
operands of the combination).
We can assume that the mechanism for applying primitive proce
dures to arguments is built into the interpreter. For compound proce
dures, the application process is as follows:
To apply a compound procedure to arguments, evaluate the
body of the procedure with each formal parameter replaced
by the corresponding argument.
To illustrate this process, let’s evaluate the combination
(f 5)
where f is the procedure deﬁned in Section 1.1.4. We begin by retrieving
the body of f:
(sumofsquares (+ a 1) (* a 2))
en we replace the formal parameter a by the argument 5:
(sumofsquares (+ 5 1) (* 5 2))
18
us the problem reduces to the evaluation of a combination with two
operands and an operator sumofsquares. Evaluating this combina
tion 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 (+ 5 1) produces 6 and (* 5 2) produces 10, so
we must apply the sumofsquares procedure to 6 and 10. ese values
are substituted for the formal parameters x and y in the body of sum
ofsquares, reducing the expression to
(+ (square 6) (square 10))
If we use the deﬁnition of square, this reduces to
(+ (* 6 6) (* 10 10))
which reduces by multiplication to
(+ 36 100)
and ﬁnally to
136
e process we have just described is called the substitution model 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:
• e purpose of the substitution is to help us think about proce
dure application, not to provide a description of how the inter
preter really works. Typical interpreters do not evaluate proce
dure applications by manipulating the text of a procedure to sub
stitute values for the formal parameters. In practice, the “substi
tution” is accomplished by using a local environment for the for
mal parameters. We will discuss this more fully in Chapter 3 and
19
Chapter 4 when we examine the implementation of an interpreter
in detail.
• Over the course of this book, we will present a sequence of in
creasingly elaborate models of how interpreters work, culminat
ing with a complete implementation of an interpreter and com
piler in Chapter 5. e substitution model is only the ﬁrst of these
models—a way to get started thinking formally about the evalu
ation process. In general, when modeling phenomena in science
and engineering, we begin with simpliﬁed, incomplete models.
As we examine things in greater detail, these simple models be
come inadequate and must be replaced by more reﬁned models.
e substitution model is no exception. In particular, when we
address in Chapter 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.15
Applicative order versus normal order
According to the description of evaluation given in Section 1.1.3, the
interpreter ﬁrst evaluates the operator and operands and then applies
the resulting procedure to the resulting arguments. is 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
15Despite the simplicity of the substitution idea, it turns out to be surprisingly com
plicated to give a rigorous mathematical deﬁnition of the substitution process. e
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 def
initions of substitution in the literature of logic and programming semantics. See Stoy
1977 for a careful discussion of substitution.
20
ﬁrst 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 (f 5) would
proceed according to the sequence of expansions
(sumofsquares (+ 5 1) (* 5 2))
(+
(+
(square (+ 5 1))
(* (+ 5 1) (+ 5 1))
(square (* 5 2))
)
(* (* 5 2) (* 5 2)))
followed by the reductions
(+
(+
(* 6 6)
(* 10 10))
36
100)
136
is gives the same answer as our previous evaluation model, but the
process is diﬀerent. In particular, the evaluations of (+ 5 1) and (* 5
2) are each performed twice here, corresponding to the reduction of the
expression (* x x) with x replaced respectively by (+ 5 1) and (* 5
2).
is alternative “fully expand and then reduce” evaluation method
is known as normalorder evaluation, in contrast to the “evaluate the
arguments and then apply” method that the interpreter actually uses,
which is called applicativeorder evaluation. It can be shown that, for
procedure applications that can be modeled using substitution (includ
ing all the procedures in the ﬁrst two chapters of this book) and that
yield legitimate values, normalorder and applicativeorder evaluation
produce the same value. (See Exercise 1.5 for an instance of an “illegit
imate” value where normalorder and applicativeorder evaluation do
not give the same result.)
Lisp uses applicativeorder evaluation, partly because of the addi
tional eﬃciency obtained from avoiding multiple evaluations of expres
sions such as those illustrated with (+ 5 1) and (* 5 2) above and, more
21
signiﬁcantly, because normalorder evaluation becomes much more com
plicated to deal with when we leave the realm of procedures that can be
modeled by substitution. On the other hand, normalorder evaluation
can be an extremely valuable tool, and we will investigate some of its
implications in Chapter 3 and Chapter 4.16
1.1.6 Conditional Expressions and Predicates
e expressive power of the class of procedures that we can deﬁne at
this point is very limited, because we have no way to make tests and
to perform diﬀerent operations depending on the result of a test. For
instance, we cannot deﬁne a procedure that computes the absolute value
of a number by testing whether the number is positive, negative, or zero
and taking diﬀerent actions in the diﬀerent cases according to the rule
8>>><>>>: x
0
(cid:0)x
jxj =
if
if
if
x > 0;
x = 0;
x < 0:
is construct is called a case analysis, and there is a special form in
Lisp for notating such a case analysis. It is called cond (which stands for
“conditional”), and it is used as follows:
(define (abs x)
(cond ((> x 0) x)
((= x 0) 0)
((< x 0) ( x))))
e general form of a conditional expression is
16In Chapter 3 we will introduce stream processing, which is a way of handling appar
ently “inﬁnite” data structures by incorporating a limited form of normalorder evalu
ation. In Section 4.2 we will modify the Scheme interpreter to produce a normalorder
variant of Scheme.
22
(cond (⟨p1⟩ ⟨e1⟩)
(⟨p2⟩ ⟨e2⟩)
(⟨pn⟩ ⟨en⟩))
: : :
consisting of the symbol cond followed by parenthesized pairs of ex
pressions
(⟨p⟩ ⟨e⟩)
called clauses. e ﬁrst expression in each pair is a predicate—that is, an
expression whose value is interpreted as either true or false.17
Conditional expressions are evaluated as follows. e predicate ⟨p1⟩
is evaluated ﬁrst. If its value is false, then ⟨p2⟩ is evaluated. If ⟨p2⟩’s
value is also false, then ⟨p3⟩ is evaluated. is process continues until
a predicate is found whose value is true, in which case the interpreter
returns the value of the corresponding consequent expression ⟨e⟩ of the
clause as the value of the conditional expression. If none of the ⟨p⟩’s is
found to be true, the value of the cond is undeﬁned.
e word predicate is used for procedures that return true or false,
as well as for expressions that evaluate to true or false. e absolute
value procedure abs makes use of the primitive predicates >, <, and =.18
ese take two numbers as arguments and test whether the ﬁrst number
is, respectively, greater than, less than, or equal to the second number,
returning true or false accordingly.
Another way to write the absolutevalue procedure is
17“Interpreted as either true or false” means this: In Scheme, there are two distin
guished values that are denoted by the constants #t and #f. When the interpreter checks
a predicate’s value, it interprets #f as false. Any other value is treated as true. (us,
providing #t is logically unnecessary, but it is convenient.) In this book we will use
names true and false, which are associated with the values #t and #f respectively.
18abs also uses the “minus” operator , which, when used with a single operand, as
in ( x), indicates negation.
23
(define (abs x)
(cond ((< x 0) ( x))
(else x)))
which could be expressed in English as “If x is less than zero return (cid:0)x;
otherwise return x.” else is a special symbol that can be used in place of
the ⟨p⟩ in the ﬁnal clause of a cond. is causes the cond to return as its
value the value of the corresponding ⟨e⟩ whenever all previous clauses
have been bypassed. In fact, any expression that always evaluates to a
true value could be used as the ⟨p⟩ here.
Here is yet another way to write the absolutevalue procedure:
(define (abs x)
(if (< x 0)
( x)
x))
is uses the special form if, a restricted type of conditional that can
be used when there are precisely two cases in the case analysis. e
general form of an if expression is
(if ⟨predicate⟩ ⟨consequent⟩ ⟨alternative⟩)
To evaluate an if expression, the interpreter starts by evaluating the
⟨predicate⟩ part of the expression. If the ⟨predicate⟩ evaluates to a true
value, the interpreter then evaluates the ⟨consequent⟩ and returns its
value. Otherwise it evaluates the ⟨alternative⟩ and returns its value.19
In addition to primitive predicates such as <, =, and >, there are log
ical composition operations, which enable us to construct compound
19A minor diﬀerence between if and cond is that the ⟨e⟩ part of each cond clause may
be a sequence of expressions. If the corresponding ⟨p⟩ is found to be true, the expres
sions ⟨e⟩ are evaluated in sequence and the value of the ﬁnal expression in the sequence
is returned as the value of the cond. In an if expression, however, the ⟨consequent⟩ and
⟨alternative⟩ must be single expressions.
24
predicates. e three most frequently used are these:
: : :
: : :
⟨en⟩)
⟨en⟩)
• (and ⟨e1⟩
e interpreter evaluates the expressions ⟨e⟩ one at a time, in le
toright order. If any ⟨e⟩ evaluates to false, the value of the and
expression is false, and the rest of the ⟨e⟩’s are not evaluated. If
all ⟨e⟩’s evaluate to true values, the value of the and expression is
the value of the last one.
• (or ⟨e1⟩
e interpreter evaluates the expressions ⟨e⟩ one at a time, in le
toright order. If any ⟨e⟩ evaluates to a true value, that value is
returned as the value of the or expression, and the rest of the
⟨e⟩’s are not evaluated. If all ⟨e⟩’s evaluate to false, the value of
the or expression is false.
• (not ⟨e⟩)
e value of a not expression is true when the expression ⟨e⟩
evaluates to false, and false otherwise.
Notice that and and or are special forms, not procedures, because the
subexpressions are not necessarily all evaluated. not is an ordinary pro
cedure.
As an example of how these are used, the condition that a number
x be in the range 5 < x < 10 may be expressed as
(and (> x 5) (< x 10))
As another example, we can deﬁne a predicate to test whether one num
ber is greater than or equal to another as
(define (>= x y) (or (> x y) (= x y)))
25
or alternatively as
(define (>= x y) (not (< x y)))
Exercise 1.1: Below is a sequence of expressions. What is
the result printed by the interpreter in response to each ex
pression? Assume that the sequence is to be evaluated in
the order in which it is presented.
10
(+ 5 3 4)
( 9 1)
(/ 6 2)
(+ (* 2 4) ( 4 6))
(define a 3)
(define b (+ a 1))
(+ a b (* a b))
(= a b)
(if (and (> b a) (< b (* a b)))
b
a)
(cond ((= a 4) 6)
((= b 4) (+ 6 7 a))
(else 25))
(+ 2 (if (> b a) b a))
(* (cond ((> a b) a)
((< a b) b)
(else 1))
(+ a 1))
26
Exercise 1.2: Translate the following expression into preﬁx
form:
5 + 4 + (2 (cid:0) (3 (cid:0) (6 + 4
5)))
3(6 (cid:0) 2)(2 (cid:0) 7)
:
Exercise 1.3: Deﬁne a procedure that takes three numbers
as arguments and returns the sum of the squares of the two
larger numbers.
Exercise 1.4: Observe that our model of evaluation allows
for combinations whose operators are compound expres
sions. Use this observation to describe the behavior of the
following procedure:
(define (aplusabsb a b)
((if (> b 0) + ) a b))
Exercise 1.5: Ben Bitdiddle has invented a test to determine
whether the interpreter he is faced with is using applicative
order evaluation or normalorder evaluation. He deﬁnes the
following two procedures:
(define (p) (p))
(define (test x y)
(if (= x 0) 0 y))
en he evaluates the expression
(test 0 (p))
What behavior will Ben observe with an interpreter that
uses applicativeorder evaluation? What behavior will he
observe with an interpreter that uses normalorder evalu
ation? Explain your answer. (Assume that the evaluation
27
rule for the special form if is the same whether the in
terpreter is using normal or applicative order: e predi
cate expression is evaluated ﬁrst, and the result determines
whether to evaluate the consequent or the alternative ex
pression.)
1.1.7 Example: Square Roots by Newton’s Method
Procedures, as introduced above, are much like ordinary mathematical
functions. ey specify a value that is determined by one or more pa
rameters. But there is an important diﬀerence between mathematical
functions and computer procedures. Procedures must be eﬀective.
As a case in point, consider the problem of computing square roots.
We can deﬁne the squareroot function as
p
x = the y such that y (cid:21) 0 and y2 = x :
is 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
deﬁnition does not describe a procedure. Indeed, it tells us almost noth
ing about how to actually ﬁnd the square root of a given number. It will
not help maers to rephrase this deﬁnition in pseudoLisp:
(define (sqrt x)
(the y (and (>= y 0)
(= (square y) x))))
is only begs the question.
e contrast between function and procedure is a reﬂection of the
general distinction between describing properties of things and describ
ing how to do things, or, as it is sometimes referred to, the distinction
28
between declarative knowledge and imperative knowledge. In mathe
matics we are usually concerned with declarative (what is) descriptions,
whereas in computer science we are usually concerned with imperative
(how to) descriptions.20
How does one compute square roots? e most common way is to
use Newton’s method of successive approximations, which says that
whenever we have a guess y for the value of the square root of a number
x, we can perform a simple manipulation to get a beer guess (one closer
to the actual square root) by averaging y with x=y.21 For example, we
can compute the square root of 2 as follows. Suppose our initial guess
is 1:
Guess
1
1.5
1.4167
1.4142
Average
((2 + 1)/2) = 1.5
((1.3333 + 1.5)/2) = 1.4167
((1.4167 + 1.4118)/2) = 1.4142
...
Quotient
(2/1) = 2
(2/1.5) = 1.3333
(2/1.4167) = 1.4118
...
20Declarative and imperative descriptions are intimately related, as indeed are math
ematics and computer science. For instance, to say that the answer produced by a pro
gram is “correct” is to make a declarative statement about the program. ere is a large
amount of research aimed at establishing techniques for proving that programs are
correct, and much of the technical diﬃculty 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 programminglanguage design is the exploration of socalled
very highlevel languages, in which one actually programs in terms of declarative state
ments. e idea is to make interpreters sophisticated enough so that, given “what is”
knowledge speciﬁed by the programmer, they can generate “how to” knowledge auto
matically. is cannot be done in general, but there are important areas where progress
has been made. We shall revisit this idea in Chapter 4.
21is squareroot algorithm is actually a special case of Newton’s method, which is
a general technique for ﬁnding roots of equations. e squareroot algorithm itself was
developed by Heron of Alexandria in the ﬁrst century .. We will see how to express
the general Newton’s method as a Lisp procedure in Section 1.3.4.
29
Continuing this process, we obtain beer and beer approximations to
the square root.
Now let’s formalize the process in terms of procedures. We start
with a value for the 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:
(define (sqrtiter guess x)
(if (goodenough? guess x)
guess
(sqrtiter (improve guess x) x)))
A guess is improved by averaging it with the quotient of the radicand
and the old guess:
(define (improve guess x)
(average guess (/ x guess)))
where
(define (average x y)
(/ (+ x y) 2))
We also have to say what we mean by “good enough.” e following
will do for illustration, but it is not really a very good test. (See Exercise
1.7.) e idea is to improve the answer until it is close enough so that its
square diﬀers from the radicand by less than a predetermined tolerance
(here 0.001):22
(define (goodenough? guess x)
(< (abs ( (square guess) x)) 0.001))
22We will usually give predicates names ending with question marks, to help us re
member that they are predicates. is is just a stylistic convention. As far as the inter
preter is concerned, the question mark is just an ordinary character.
30
Finally, we need a way to get started. For instance, we can always guess
that the square root of any number is 1:23
(define (sqrt x)
(sqrtiter 1.0 x))
If we type these deﬁnitions to the interpreter, we can use sqrt just as
we can use any procedure:
(sqrt 9)
3.00009155413138
(sqrt (+ 100 37))
11.704699917758145
(sqrt (+ (sqrt 2) (sqrt 3)))
1.7739279023207892
(square (sqrt 1000))
1000.000369924366
e sqrt program also illustrates that the simple procedural language
we have introduced so far is suﬃcient for writing any purely numeri
cal program that one could write in, say, C or Pascal. is might seem
surprising, since we have not included in our language any iterative
23Observe that we express our initial guess as 1.0 rather than 1. is would not make
any diﬀerence in many Lisp implementations. Scheme, however, distinguishes be
tween 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 2.1.1.) If we start with an initial guess of 1 in our squareroot
program, and x is an exact integer, all subsequent values produced in the squareroot
computation will be rational numbers rather than decimals. Mixed operations on ratio
nal numbers and decimals always yield decimals, so starting with an initial guess of 1.0
forces all subsequent values to be decimals.
31
(looping) constructs that direct the computer to do something over and
over again. sqrtiter, on the other hand, demonstrates how iteration
can be accomplished using no special construct other than the ordinary
ability to call a procedure.24
Exercise 1.6: Alyssa P. Hacker doesn’t see why if needs to
be provided as a special form. “Why can’t I just deﬁne it as
an ordinary procedure in terms of cond?” she asks. Alyssa’s
friend Eva Lu Ator claims this can indeed be done, and she
deﬁnes a new version of if:
(define (newif predicate thenclause elseclause)
(cond (predicate thenclause)
(else elseclause)))
Eva demonstrates the program for Alyssa:
(newif (= 2 3) 0 5)
5
(newif (= 1 1) 0 5)
0
Delighted, Alyssa uses newif to rewrite the squareroot
program:
(define (sqrtiter guess x)
(newif (goodenough? guess x)
guess
(sqrtiter (improve guess x) x)))
What happens when Alyssa aempts to use this to compute
square roots? Explain.
24Readers who are worried about the eﬃciency issues involved in using procedure
calls to implement iteration should note the remarks on “tail recursion” in Section 1.2.1.
32
Exercise 1.7: e goodenough? test used in computing
square roots will not be very eﬀective for ﬁnding the square
roots of very small numbers. Also, in real computers, arith
metic operations are almost always performed with lim
ited precision. is makes our test inadequate for very large
numbers. Explain these statements, with examples showing
how the test fails for small and large numbers. An alterna
tive strategy for implementing goodenough? is to watch
how guess changes from one iteration to the next and to
stop when the change is a very small fraction of the guess.
Design a squareroot procedure that uses this kind of end
test. Does this work beer for small and large numbers?
Exercise 1.8: Newton’s method for cube roots is based on
the fact that if y is an approximation to the cube root of x,
then a beer approximation is given by the value
x=y2 + 2y
3
:
Use this formula to implement a cuberoot procedure anal
ogous to the squareroot procedure. (In Section 1.3.4 we will
see how to implement Newton’s method in general as an
abstraction of these squareroot and cuberoot procedures.)
1.1.8 Procedures as BlackBox Abstractions
sqrt is our ﬁrst example of a process deﬁned by a set of mutually deﬁned
procedures. Notice that the deﬁnition of sqrtiter is recursive; that is,
the procedure is deﬁned in terms of itself. e idea of being able to
deﬁne a procedure in terms of itself may be disturbing; it may seem
33
Figure 1.2: Procedural decomposition of the sqrt program.
unclear how such a “circular” deﬁnition could make sense at all, much
less specify a welldeﬁned process to be carried out by a computer. is
will be addressed more carefully in Section 1.2. But ﬁrst let’s consider
some other important points illustrated by the sqrt example.
Observe that the problem of computing square roots breaks up nat
urally 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. e entire sqrt program can be
viewed as a cluster of procedures (shown in Figure 1.2) that mirrors the
decomposition of the problem into subproblems.
e importance of this decomposition strategy is not simply that
one is dividing the program into parts. Aer all, we could take any large
program and divide it into parts—the ﬁrst ten lines, the next ten lines,
the next ten lines, and so on. Rather, it is crucial that each procedure ac
complishes an identiﬁable task that can be used as a module in deﬁning
other procedures. For example, when we deﬁne the goodenough? pro
cedure in terms of square, we are able to regard the square procedure
as a “black box.” We are not at that moment concerned with how the
procedure computes its result, only with the fact that it computes the
square. e details of how the square is computed can be suppressed,
to be considered at a later time. Indeed, as far as the goodenough? pro
34
sqrt  sqrtiter / \ goodenough improve / \ \square abs averagecedure is concerned, square is not quite a procedure but rather an ab
straction of a procedure, a socalled procedural abstraction. At this level
of abstraction, any procedure that computes the square is equally good.
us, 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.25
(define (square x) (* x x))
(define (square x) (exp (double (log x))))
(define (double x) (+ x x))
So a procedure deﬁnition should be able to suppress detail. e users
of the procedure may not have wrien 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.
Local names
One detail of a procedure’s implementation that should not maer to
the user of the procedure is the implementer’s choice of names for the
procedure’s formal parameters. us, the following procedures should
not be distinguishable:
(define (square x) (* x x))
(define (square y) (* y y))
25It is not even clear which of these procedures is a more eﬃcient implementation.
is depends upon the hardware available. ere are machines for which the “obvious”
implementation is the less eﬃcient one. Consider a machine that has extensive tables
of logarithms and antilogarithms stored in a very eﬃcient manner.
35
is principle—that the meaning of a procedure should be independent
of the parameter names used by its author—seems on the surface to
be selfevident, but its consequences are profound. e simplest conse
quence is that the parameter names of a procedure must be local to the
body of the procedure. For example, we used square in the deﬁnition
of goodenough? in our squareroot procedure:
(define (goodenough? guess x)
(< (abs ( (square guess) x))
0.001))
e intention of the author of goodenough? is to determine if the square
of the ﬁrst argument is within a given tolerance of the second argument.
We see that the author of goodenough? used the name guess to refer to
the ﬁrst argument and x to refer to the second argument. e argument
of square is guess. If the author of square used x (as above) to refer to
that argument, we see that the x in goodenough? must be a diﬀerent x
than the one in square. Running the procedure square must not aﬀect
the value of x that is used by goodenough?, because that value of x
may be needed by goodenough? aer square is done computing.
If the parameters were not local to the bodies of their respective
procedures, then the parameter x in square could be confused with the
parameter x in goodenough?, and the behavior of goodenough? would
depend upon which version of square we used. us, square would not
be the black box we desired.
A formal parameter of a procedure has a very special role in the
procedure deﬁnition, in that it doesn’t maer what name the formal
parameter has. Such a name is called a bound variable, and we say that
the procedure deﬁnition binds its formal parameters. e meaning of
a procedure deﬁnition is unchanged if a bound variable is consistently
36
renamed throughout the deﬁnition.26 If a variable is not bound, we say
that it is free. e set of expressions for which a binding deﬁnes a name
is called the scope of that name. In a procedure deﬁnition, the bound
variables declared as the formal parameters of the procedure have the
body of the procedure as their scope.
In the deﬁnition of goodenough? above, guess and x are bound
variables but <, , abs, and square are free. e meaning of good
enough? should be independent of the names we choose for guess and
x so long as they are distinct and diﬀerent from <, , abs, and square.
(If we renamed guess to abs we would have introduced a bug by cap
turing the variable abs. It would have changed from free to bound.) e
meaning of goodenough? is not independent of the names of its free
variables, however. It surely depends upon the fact (external to this def
inition) that the symbol abs names a procedure for computing the abso
lute value of a number. goodenough? will compute a diﬀerent function
if we substitute cos for abs in its deﬁnition.
Internal definitions and block structure
We have one kind of name isolation available to us so far: e formal
parameters of a procedure are local to the body of the procedure. e
squareroot program illustrates another way in which we would like
to control the use of names. e existing program consists of separate
procedures:
(define (sqrt x)
(sqrtiter 1.0 x))
(define (sqrtiter guess x)
(if (goodenough? guess x)
26e concept of consistent renaming is actually subtle and diﬃcult to deﬁne for
mally. Famous logicians have made embarrassing errors here.
37
guess
(sqrtiter (improve guess x) x)))
(define (goodenough? guess x)
(< (abs ( (square guess) x)) 0.001))
(define (improve guess x)
(average guess (/ x guess)))
e problem with this program is that the only procedure that is impor
tant to users of sqrt is sqrt. e other procedures (sqrtiter, good
enough?, and improve) only cluer up their minds. ey may not deﬁne
any other procedure called goodenough? as part of another program
to work together with the squareroot program, because sqrt needs it.
e 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 proce
dures named goodenough? and improve as auxiliary procedures. We
would like to localize the subprocedures, hiding them inside sqrt so
that sqrt could coexist with other successive approximations, each hav
ing its own private goodenough? procedure. To make this possible, we
allow a procedure to have internal deﬁnitions that are local to that pro
cedure. For example, in the squareroot problem we can write
(define (sqrt x)
(define (goodenough? guess x)
(< (abs ( (square guess) x)) 0.001))
(define (improve guess x) (average guess (/ x guess)))
(define (sqrtiter guess x)
(if (goodenough? guess x)
guess
(sqrtiter (improve guess x) x)))
(sqrtiter 1.0 x))
38
Such nesting of deﬁnitions, called block structure, is basically the right
solution to the simplest namepackaging problem. But there is a bet
ter idea lurking here. In addition to internalizing the deﬁnitions of the
auxiliary procedures, we can simplify them. Since x is bound in the deﬁ
nition of sqrt, the procedures goodenough?, improve, and sqrtiter,
which are deﬁned internally to sqrt, are in the scope of x. us, it is
not necessary to pass x explicitly to each of these procedures. Instead,
we allow x to be a free variable in the internal deﬁnitions, as shown be
low. en x gets its value from the argument with which the enclosing
procedure sqrt is called. is discipline is called lexical scoping.27
(define (sqrt x)
(define (goodenough? guess)
(< (abs ( (square guess) x)) 0.001))
(define (improve guess)
(average guess (/ x guess)))
(define (sqrtiter guess)
(if (goodenough? guess)
guess
(sqrtiter (improve guess))))
(sqrtiter 1.0))
We will use block structure extensively to help us break up large pro
grams into tractable pieces.28 e idea of block structure originated with
the programming language Algol 60. It appears in most advanced pro
gramming languages and is an important tool for helping to organize
the construction of large programs.
27Lexical scoping dictates that free variables in a procedure are taken to refer to
bindings made by enclosing procedure deﬁnitions; that is, they are looked up in the
environment in which the procedure was deﬁned. We will see how this works in detail
in chapter 3 when we study environments and the detailed behavior of the interpreter.
28Embedded deﬁnitions must come ﬁrst in a procedure body. e management is not
responsible for the consequences of running programs that intertwine deﬁnition and
use.
39
1.2 Procedures and the Processes They Generate
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 deﬁning 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 paerns of usage in the do
main. We lack the knowledge of which moves are worth making (which
procedures are worth deﬁning). We lack the experience to predict the
consequences of making a move (executing a procedure).
e ability to visualize the consequences of the actions under con
sideration 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, plan
ning framing, lighting, exposure, and development to obtain the desired
eﬀects. 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 aer we have
developed such a skill can we learn to reliably construct programs that
exhibit the desired behavior.
A procedure is a paern for the local evolution of a computational
process. It speciﬁes how each stage of the process is built upon the previ
ous stage. We would like to be able to make statements about the overall,
40
or global, behavior of a process whose local evolution has been speciﬁed
by a procedure. is is very diﬃcult to do in general, but we can at least
try to describe some typical paerns of process evolution.
In this section we will examine some common “shapes” for pro
cesses generated by simple procedures. We will also investigate the
rates at which these processes consume the important computational
resources of time and space. e procedures we will consider are very
simple. eir role is like that played by test paerns in photography: as
oversimpliﬁed prototypical paerns, rather than practical examples in
their own right.
1.2.1 Linear Recursion and Iteration
We begin by considering the factorial function, deﬁned by
n! = n (cid:1) (n (cid:0) 1) (cid:1) (n (cid:0) 2)(cid:1) (cid:1) (cid:1) 3 (cid:1) 2 (cid:1) 1:
ere are many ways to compute factorials. One way is to make use
of the observation that n! is equal to n times (n (cid:0) 1)! for any positive
integer n:
n! = n (cid:1) [(n (cid:0) 1) (cid:1) (n (cid:0) 2)(cid:1) (cid:1) (cid:1) 3 (cid:1) 2 (cid:1) 1] = n (cid:1) (n (cid:0) 1)!:
us, we can compute n! by computing (n (cid:0) 1)! and multiplying the
result by n. If we add the stipulation that 1! is equal to 1, this observation
translates directly into a procedure:
(define (factorial n)
(if (= n 1)
1
(* n (factorial ( n 1)))))
41
Figure 1.3: A linear recursive process for computing 6!.
We can use the substitution model of Section 1.1.5 to watch this proce
dure in action computing 6!, as shown in Figure 1.3.
Now let’s take a diﬀerent perspective on computing factorials. We
could describe a rule for computing n! by specifying that we ﬁrst mul
tiply 1 by 2, then multiply the result by 3, then by 4, and so on until we
reach n. More formally, we maintain a running product, together with
a counter that counts from 1 up to n. 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
product counter * product
counter counter + 1
and stipulating that n! is the value of the product when the counter
exceeds n.
Once again, we can recast our description as a procedure for com
puting factorials:29
29In a real program we would probably use the block structure introduced in the last
section to hide the deﬁnition of factiter:
42
(factorial 6)(* 6 (factorial 5))(* 6 (* 5 (factorial 4)))(* 6 (* 5 (* 4 (factorial 3))))(* 6 (* 5 (* 4 (* 3 (factorial 2)))))(* 6 (* 5 (* 4 (* 3 (* 2 (factorial 1))))))(* 6 (* 5 (* 4 (* 3 (* 2 1)))))(* 6 (* 5 (* 4 (* 3 2))))(* 6 (* 5 (* 4 6)))(* 6 (* 5 24))(* 6 120)720 Figure 1.4: A linear iterative process for computing 6!.
(define (factorial n)
(factiter 1 1 n))
(define (factiter product counter maxcount)
(if (> counter maxcount)
product
(factiter (* counter product)
(+ counter 1)
maxcount)))
As before, we can use the substitution model to visualize the process of
computing 6!, as shown in Figure 1.4.
(define (factorial n)
(define (iter product counter)
(if (> counter n)
product
(iter (* counter product)
(+ counter 1))))
(iter 1 1))
We avoided doing this here so as to minimize the number of things to think about at
once.
43
(factorial 6)(factiter 1 1 6)(factiter 1 2 6)(factiter 2 3 6)(factiter 6 4 6)(factiter 24 5 6)(factiter 120 6 6)(factiter 720 7 6)720Compare the two processes. From one point of view, they seem
hardly diﬀerent at all. Both compute the same mathematical function on
the same domain, and each requires a number of steps proportional to n
to compute n!. 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 “shapes” of the two processes, we
ﬁnd that they evolve quite diﬀerently.
Consider the ﬁrst process. e substitution model reveals a shape of
expansion followed by contraction, indicated by the arrow in Figure 1.3.
e expansion occurs as the process builds up a chain of deferred oper
ations (in this case, a chain of multiplications). e contraction occurs
as the operations are actually performed. is type of process, charac
terized by a chain of deferred operations, is called a recursive process.
Carrying out this process requires that the interpreter keep track of the
operations to be performed later on. In the computation of n!, the length
of the chain of deferred multiplications, and hence the amount of infor
mation needed to keep track of it, grows linearly with n (is proportional
to n), just like the number of steps. Such a process is called a linear re
cursive process.
By contrast, the second process does not grow and shrink. At each
step, all we need to keep track of, for any n, are the current values of
the variables product, counter, and maxcount. We call this an iterative
process. In general, an iterative process is one whose state can be sum
marized by a ﬁxed number of state variables, together with a ﬁxed rule
that describes how the state variables should be updated as the process
moves from state to state and an (optional) end test that speciﬁes con
ditions under which the process should terminate. In computing n!, the
number of steps required grows linearly with n. Such a process is called
a linear iterative process.
44
e contrast between the two processes can be seen in another way.
In the iterative case, the program variables provide a complete descrip
tion of the state of the process at any point. If we stopped the compu
tation between steps, all we would need to do to resume the computa
tion is to supply the interpreter with the values of the three program
variables. Not so with the recursive process. In this case there is some
additional “hidden” information, maintained by the interpreter and not
contained in the program variables, which indicates “where the process
is” in negotiating the chain of deferred operations. e longer the chain,
the more information must be maintained.30
In contrasting iteration and recursion, we must be careful not to
confuse the notion of a recursive process with the notion of a recursive
procedure. When we describe a procedure as recursive, we are referring
to the syntactic fact that the procedure deﬁnition refers (either directly
or indirectly) to the procedure itself. But when we describe a process
as following a paern that is, say, linearly recursive, we are speaking
about how the process evolves, not about the syntax of how a procedure
is wrien. It may seem disturbing that we refer to a recursive procedure
such as factiter as generating an iterative process. However, the pro
cess really is iterative: Its state is captured completely by its three state
variables, and an interpreter need keep track of only three variables in
order to execute the process.
One reason that the distinction between process and procedure may
be confusing is that most implementations of common languages (in
cluding Ada, Pascal, and C) are designed in such a way that the interpre
tation of any recursive procedure consumes an amount of memory that
30When we discuss the implementation of procedures on register machines in Chap
ter 5, we will see that any iterative process can be realized “in hardware” as a machine
that has a ﬁxed set of registers and no auxiliary memory. In contrast, realizing a re
cursive process requires a machine that uses an auxiliary data structure known as a
stack.
45
grows with the number of procedure calls, even when the process de
scribed is, in principle, iterative. As a consequence, these languages can
describe iterative processes only by resorting to specialpurpose “loop
ing constructs” such as do, repeat, until, for, and while. e imple
mentation of Scheme we shall consider in Chapter 5 does not share this
defect. It will execute an iterative process in constant space, even if the
iterative process is described by a recursive procedure. An implemen
tation with this property is called tailrecursive. With a tailrecursive
implementation, iteration can be expressed using the ordinary proce
dure call mechanism, so that special iteration constructs are useful only
as syntactic sugar.31
Exercise 1.9: Each of the following two procedures deﬁnes
a method for adding two positive integers in terms of the
procedures inc, which increments its argument by 1, and
dec, which decrements its argument by 1.
(define (+ a b)
(if (= a 0) b (inc (+ (dec a) b))))
(define (+ a b)
(if (= a 0) b (+ (dec a) (inc b))))
Using the substitution model, illustrate the process gener
ated by each procedure in evaluating (+ 4 5). Are these
processes iterative or recursive?
31Tail recursion has long been known as a compiler optimization trick. A coherent
semantic basis for tail recursion was provided by Carl Hewi (1977), who explained it in
terms of the “messagepassing” model of computation that we shall discuss in Chapter
3. Inspired by this, Gerald Jay Sussman and Guy Lewis Steele Jr. (see Steele and Sussman
1975) constructed a tailrecursive interpreter for Scheme. Steele later showed how tail
recursion is a consequence of the natural way to compile procedure calls (Steele 1977).
e standard for Scheme requires that Scheme implementations be tailrecursive.
46
Exercise 1.10: e following procedure computes a math
ematical function called Ackermann’s function.
(define (A x y)
(cond ((= y 0) 0)
((= x 0) (* 2 y))
((= y 1) 2)
(else (A ( x 1) (A x ( y 1))))))
What are the values of the following expressions?
(A 1 10)
(A 2 4)
(A 3 3)
Consider the following procedures, where A is the proce
dure deﬁned above:
(define (f n) (A 0 n))
(define (g n) (A 1 n))
(define (h n) (A 2 n))
(define (k n) (* 5 n n))
Give concise mathematical deﬁnitions for the functions com
puted by the procedures f, g, and h for positive integer val
ues of n. For example, (k n) computes 5n2.
1.2.2 Tree Recursion
Another common paern of computation is called tree recursion. As an
example, consider computing the sequence of Fibonacci numbers, in
which each number is the sum of the preceding two:
0; 1; 1; 2; 3; 5; 8; 13; 21; : : : :
47
In general, the Fibonacci numbers can be deﬁned by the rule
Fib(n) =
1
Fib(n (cid:0) 1) + Fib(n (cid:0) 2)
if n = 0;
if n = 1;
otherwise:
8>>>>><>>>>>: 0
We can immediately translate this deﬁnition into a recursive procedure
for computing Fibonacci numbers:
(define (fib n)
(cond ((= n 0) 0)
((= n 1) 1)
(else (+ (fib ( n 1))
(fib ( n 2))))))
Consider the paern of this computation. To compute (fib 5), we com
pute (fib 4) and (fib 3). To compute (fib 4), we compute (fib 3)
and (fib 2). In general, the evolved process looks like a tree, as shown
in Figure 1.5. Notice that the branches split into two at each level (ex
cept at the boom); this reﬂects the fact that the fib procedure calls
itself twice each time it is invoked.
is procedure is instructive as a prototypical tree recursion, but it
is a terrible way to compute Fibonacci numbers because it does so much
redundant computation. Notice in Figure 1.5 that the entire computation
of (fib 3)—almost half the work—is duplicated. In fact, it is not hard to
show that the number of times the procedure will compute (fib 1) or
(fib 0) (the number of leaves in the above tree, in general) is precisely
Fib(n + 1). To get an idea of how bad this is, one can show that the value
p
of Fib(n) grows exponentially with n. More precisely (see Exercise 1.13),
Fib(n) is the closest integer to ϕn=
p
5, where
(cid:25) 1:6180
5
ϕ =
1 +
2
48
Figure 1.5: e treerecursive process generated in com
puting (fib 5).
is the golden ratio, which satisﬁes the equation
ϕ2 = ϕ + 1:
us, the process uses a number of steps that grows exponentially with
the input. On the other hand, the space required grows only linearly
with the input, because we need keep track only of which nodes are
above us in the tree at any point in the computation. In general, the
number of steps required by a treerecursive process will be propor
tional to the number of nodes in the tree, while the space required will
be proportional to the maximum depth of the tree.
We can also formulate an iterative process for computing the Fi
bonacci numbers. e idea is to use a pair of integers a and b, initialized
to Fib(1) = 1 and Fib(0) = 0, and to repeatedly apply the simultaneous
49
fib5 fib4 fib3 fib3 fib2 fib2 fib1 1 fib2 fib1 fib1 fib0 fib1 fib0 1 1 0 1 0fib1 fib01 0transformations
a a + b;
b a:
It is not hard to show that, aer applying this transformation n times, a
and b will be equal, respectively, to Fib(n + 1) and Fib(n). us, we can
compute Fibonacci numbers iteratively using the procedure
(define (fib n)
(fibiter 1 0 n))
(define (fibiter a b count)
(if (= count 0)
b
(fibiter (+ a b) a ( count 1))))
is second method for computing Fib(n) is a linear iteration. e diﬀer
ence in number of steps required by the two methods—one linear in n,
one growing as fast as Fib(n) itself—is enormous, even for small inputs.
One should not conclude from this that treerecursive processes
are useless. When we consider processes that operate on hierarchically
structured data rather than numbers, we will ﬁnd that tree recursion is
a natural and powerful tool.32 But even in numerical operations, tree
recursive processes can be useful in helping us to understand and de
sign programs. For instance, although the ﬁrst fib procedure is much
less eﬃcient than the second one, it is more straightforward, being lile
more than a translation into Lisp of the deﬁnition of the Fibonacci se
quence. To formulate the iterative algorithm required noticing that the
computation could be recast as an iteration with three state variables.
32An example of this was hinted at in Section 1.1.3. e interpreter itself evaluates
expressions using a treerecursive process.
50
Example: Counting change
It takes only a bit of cleverness to come up with the iterative Fibonacci
algorithm. In contrast, consider the following problem: How many dif
ferent ways can we make change of $1.00, given halfdollars, quarters,
dimes, nickels, and pennies? More generally, can we write a procedure
to compute the number of ways to change any given amount of money?
is problem has a simple solution as a recursive procedure. Sup
pose we think of the types of coins available as arranged in some order.
en the following relation holds:
e number of ways to change amount a using n kinds of coins
equals
• the number of ways to change amount a using all but the ﬁrst
kind of coin, plus
• the number of ways to change amount a (cid:0) d using all n kinds of
coins, where d is the denomination of the ﬁrst kind of coin.
To see why this is true, observe that the ways to make change can be
divided into two groups: those that do not use any of the ﬁrst kind of
coin, and those that do. erefore, the total number of ways to make
change for some amount is equal to the number of ways to make change
for the amount without using any of the ﬁrst kind of coin, plus the
number of ways to make change assuming that we do use the ﬁrst kind
of coin. But the laer number is equal to the number of ways to make
change for the amount that remains aer using a coin of the ﬁrst kind.
us, we can recursively reduce the problem of changing a given
amount to the problem of changing smaller amounts using fewer kinds
of coins. Consider this reduction rule carefully, and convince yourself
51
that we can use it to describe an algorithm if we specify the following
degenerate cases:33
• If a is exactly 0, we should count that as 1 way to make change.
• If a is less than 0, we should count that as 0 ways to make change.
• If n is 0, we should count that as 0 ways to make change.
We can easily translate this description into a recursive procedure:
(define (countchange amount) (cc amount 5))
(define (cc amount kindsofcoins)
(cond ((= amount 0) 1)
((or (< amount 0) (= kindsofcoins 0)) 0)
(else (+ (cc amount
( kindsofcoins 1))
(cc ( amount
(firstdenomination
kindsofcoins))
kindsofcoins)))))
(define (firstdenomination kindsofcoins)
(cond ((= kindsofcoins 1) 1)
((= kindsofcoins 2) 5)
((= kindsofcoins 3) 10)
((= kindsofcoins 4) 25)
((= kindsofcoins 5) 50)))
(e firstdenomination procedure takes as input the number of kinds
of coins available and returns the denomination of the ﬁrst kind. Here
we are thinking of the coins as arranged in order from largest to small
est, but any order would do as well.) We can now answer our original
question about changing a dollar:
33For example, work through in detail how the reduction rule applies to the problem
of making change for 10 cents using pennies and nickels.
52
(countchange 100)
292
countchange generates a treerecursive process with redundancies sim
ilar to those in our ﬁrst implementation of fib. (It will take quite a while
for that 292 to be computed.) On the other hand, it is not obvious how
to design a beer algorithm for computing the result, and we leave this
problem as a challenge. e observation that a treerecursive process
may be highly ineﬃcient but oen easy to specify and understand has
led people to propose that one could get the best of both worlds by
designing a “smart compiler” that could transform treerecursive pro
cedures into more eﬃcient procedures that compute the same result.34
8>><>>: n
Exercise 1.11: A function f is deﬁned by the rule that
if n < 3,
f (n) =
f (n (cid:0) 1) + 2f (n (cid:0) 2) + 3f (n (cid:0) 3)
if n (cid:21) 3.
Write a procedure that computes f by means of a recursive
process. Write a procedure that computes f by means of an
iterative process.
Exercise 1.12: e following paern of numbers is called
Pascal’s triangle.
34One approach to coping with redundant computations is to arrange maers so
that we automatically construct a table of values as they are computed. Each time we
are asked to apply the procedure to some argument, we ﬁrst look to see if the value
is already stored in the table, in which case we avoid performing the redundant com
putation. is strategy, known as tabulation or memoization, can be implemented in a
straightforward way. Tabulation can sometimes be used to transform processes that
require an exponential number of steps (such as countchange) into processes whose
space and time requirements grow linearly with the input. See Exercise 3.27.
53
1
2
6
1
3
1
4
1
3
1
4
. . .
1
1
1
1
e numbers at the edge of the triangle are all 1, and each
number inside the triangle is the sum of the two numbers
above it.35 Write a procedure that computes elements of
Pascal’s triangle by means of a recursive process.
p
5, where ϕ = (1 +
p
5)=2. Hint: Let ψ = (1 (cid:0) p
Exercise 1.13: Prove that Fib(n) is the closest integer to
ϕn=
5)=2.
p
Use induction and the deﬁnition of the Fibonacci numbers
(see Section 1.2.2) to prove that Fib(n) = (ϕn (cid:0) ψ n)=
5.
1.2.3 Orders of Growth
e previous examples illustrate that processes can diﬀer considerably
in the rates at which they consume computational resources. One con
venient way to describe this diﬀerence is to use the notion of order of
growth to obtain a gross measure of the resources required by a process
as the inputs become larger.
35e elements of Pascal’s triangle are called the binomial coeﬃcients, because the
nth row consists of the coeﬃcients of the terms in the expansion of (x + y)n. is pat
tern for computing the coeﬃcients appeared in Blaise Pascal’s 1653 seminal work on
probability theory, Traité du triangle arithmétique. According to Knuth (1973), the same
paern appears in the Szuyuen Yüchien (“e Precious Mirror of the Four Elements”),
published by the Chinese mathematician Chu Shihchieh in 1303, in the works of the
twelhcentury Persian poet and mathematician Omar Khayyam, and in the works of
the twelhcentury Hindu mathematician Bháscara Áchárya.
54
Let n be a parameter that measures the size of the problem, and let
R(n) be the amount of resources the process requires for a problem of
size n. In our previous examples we took n to be the number for which
a given function is to be computed, but there are other possibilities. For
instance, if our goal is to compute an approximation to the square root of
a number, we might take n to be the number of digits accuracy required.
For matrix multiplication we might take n to be the number of rows in
the matrices. In general there are a number of properties of the problem
with respect to which it will be desirable to analyze a given process.
Similarly, R(n) might measure the number of internal storage registers
used, the number of elementary machine operations performed, and so
on. In computers that do only a ﬁxed number of operations at a time, the
time required will be proportional to the number of elementary machine
operations performed.
We say that R(n) has order of growth Θ(f (n)), wrien R(n) = Θ(f (n))
(pronounced “theta of f (n)”), if there are positive constants k1 and k2
independent of n such that k1f (n) (cid:20) R(n) (cid:20) k2f (n) for any suﬃciently
large value ofn. (In other words, for largen, the value R(n) is sandwiched
between k1f (n) and k2f (n).)
For instance, with the linear recursive process for computing facto
rial described in Section 1.2.1 the number of steps grows proportionally
to the input n. us, the steps required for this process grows as Θ(n).
We also saw that the space required grows as Θ(n). For the iterative
factorial, the number of steps is still Θ(n) but the space is Θ(1)—that
is, constant.36 e treerecursive Fibonacci computation requires Θ(ϕn)
36ese statements mask a great deal of oversimpliﬁcation. For instance, if we count
process steps as “machine operations” we are making the assumption that the number
of machine operations needed to perform, say, a multiplication is independent of the
size of the numbers to be multiplied, which is false if the numbers are suﬃciently large.
Similar remarks hold for the estimates of space. Like the design and description of a
process, the analysis of a process can be carried out at various levels of abstraction.
55
steps and space Θ(n), where ϕ is the golden ratio described in Section
1.2.2.
Orders of growth provide only a crude description of the behavior
of a process. For example, a process requiring n2 steps and a process
requiring 1000n2 steps and a process requiring 3n2 + 10n + 17 steps all
have Θ(n2) order of growth. On the other hand, order of growth provides
a useful indication of how we may expect the behavior of the process to
change as we change the size of the problem. For a Θ(n) (linear) process,
doubling the size will roughly double the amount of resources used. For
an exponential process, each increment in problem size will multiply the
resource utilization by a constant factor. In the remainder of Section 1.2
we will examine two algorithms whose order of growth is logarithmic,
so that doubling the problem size increases the resource requirement
by a constant amount.
Exercise 1.14: Draw the tree illustrating the process gen
erated by the countchange procedure of Section 1.2.2 in
making change for 11 cents. What are the orders of growth
of the space and number of steps used by this process as
the amount to be changed increases?
Exercise 1.15: e sine of an angle (speciﬁed in radians)
can be computed by making use of the approximation sin x (cid:25) x
if x is suﬃciently small, and the trigonometric identity
sin x = 3 sin
x
3
(cid:0) 4 sin3 x
3
to reduce the size of the argument of sin. (For purposes of
this exercise an angle is considered “suﬃciently small” if its
magnitude is not greater than 0.1 radians.) ese ideas are
incorporated in the following procedures:
56
(define (cube x) (* x x x))
(define (p x) ( (* 3 x) (* 4 (cube x))))
(define (sine angle)
(if (not (> (abs angle) 0.1))
angle
(p (sine (/ angle 3.0)))))
a. How many times is the procedure p applied when (sine
12.15) is evaluated?
b. What is the order of growth in space and number of
steps (as a function of a) used by the process generated
by the sine procedure when (sine a) is evaluated?
1.2.4 Exponentiation
Consider the problem of computing the exponential of a given number.
We would like a procedure that takes as arguments a base b and a posi
tive integer exponent n and computes bn. One way to do this is via the
recursive deﬁnition
bn = b (cid:1) bn(cid:0)1;
b0 = 1;
which translates readily into the procedure
(define (expt b n)
(if (= n 0)
1
(* b (expt b ( n 1)))))
is is a linear recursive process, which requires Θ(n) steps and Θ(n)
space. Just as with factorial, we can readily formulate an equivalent lin
ear iteration:
57
(define (expt b n)
(exptiter b n 1))
(define (exptiter b counter product)
(if (= counter 0)
product
(exptiter b
( counter 1)
(* b product))))
is version requires Θ(n) steps and Θ(1) space.
We can compute exponentials in fewer steps by using successive
squaring. For instance, rather than computing b8 as
b (cid:1) (b (cid:1) (b (cid:1) (b (cid:1) (b (cid:1) (b (cid:1) (b (cid:1) b)))))) ;
we can compute it using three multiplications:
b2 = b (cid:1) b;
b4 = b2 (cid:1) b2;
b8 = b4 (cid:1) b4:
is method works ﬁne for exponents that are powers of 2. We can
also take advantage of successive squaring in computing exponentials
in general if we use the rule
bn = (bn=2)2
bn = b (cid:1) bn(cid:0)1
if n is even;
if n is odd:
We can express this method as a procedure:
(define (fastexpt b n)
(cond ((= n 0) 1)
((even? n) (square (fastexpt b (/ n 2))))
(else (* b (fastexpt b ( n 1))))))
58
where the predicate to test whether an integer is even is deﬁned in terms
of the primitive procedure remainder by
(define (even? n)
(= (remainder n 2) 0))
e process evolved by fastexpt grows logarithmically with n in both
space and number of steps. To see this, observe that computing b2n us
ing fastexpt requires only one more multiplication than computing
bn. e size of the exponent we can compute therefore doubles (approx
imately) with every new multiplication we are allowed. us, the num
ber of multiplications required for an exponent of n grows about as fast
as the logarithm of n to the base 2. e process has Θ(logn) growth.37
e diﬀerence between Θ(logn) growth and Θ(n) growth becomes
striking as n becomes large. For example, fastexpt for n = 1000 re
quires only 14 multiplications.38 It is also possible to use the idea of
successive squaring to devise an iterative algorithm that computes ex
ponentials with a logarithmic number of steps (see Exercise 1.16), al
though, as is oen the case with iterative algorithms, this is not wrien
down so straightforwardly as the recursive algorithm.39
Exercise 1.16: Design a procedure that evolves an itera
tive exponentiation process that uses successive squaring
37More precisely, the number of multiplications required is equal to 1 less than the
log base 2 of n plus the number of ones in the binary representation of n. is total
is always less than twice the log base 2 of n. e arbitrary constants k1 and k2 in the
deﬁnition of order notation imply that, for a logarithmic process, the base to which
logarithms are taken does not maer, so all such processes are described as Θ(logn).
38You may wonder why anyone would care about raising numbers to the 1000th
power. See Section 1.2.6.
39is iterative algorithm is ancient. It appears in the Chandahsutra by Áchárya
Pingala, wrien before 200 .. See Knuth 1981, section 4.6.3, for a full discussion and
analysis of this and other methods of exponentiation.
59
and uses a logarithmic number of steps, as does fastexpt.
(Hint: Using the observation that (bn=2)2 = (b2)n=2, keep,
along with the exponent n and the base b, an additional
state variable a, and deﬁne the state transformation in such
a way that the product abn is unchanged from state to state.
At the beginning of the process a is taken to be 1, and the
answer is given by the value of a at the end of the process.
In general, the technique of deﬁning an invariant quantity
that remains unchanged from state to state is a powerful
way to think about the design of iterative algorithms.)
Exercise 1.17: e exponentiation algorithms in this sec
tion are based on performing exponentiation by means of
repeated multiplication. In a similar way, one can perform
integer multiplication by means of repeated addition. e
following multiplication procedure (in which it is assumed
that our language can only add, not multiply) is analogous
to the expt procedure:
(define (* a b)
(if (= b 0)
0
(+ a (* a ( b 1)))))
is algorithm takes a number of steps that is linear in b.
Now suppose we include, together with addition, opera
tions double, which doubles an integer, and halve, which
divides an (even) integer by 2. Using these, design a mul
tiplication procedure analogous to fastexpt that uses a
logarithmic number of steps.
60
Exercise 1.18: Using the results of Exercise 1.16 and Exer
cise 1.17, devise a procedure that generates an iterative pro
cess for multiplying two integers in terms of adding, dou
bling, and halving and uses a logarithmic number of steps.40
Exercise 1.19: ere is a clever algorithm for computing
the Fibonacci numbers in a logarithmic number of steps.
Recall the transformation of the state variables a and b in
the fibiter process of Section 1.2.2: a a +b and b a.
Call this transformation T , and observe that applying T
over and over again n times, starting with 1 and 0, produces
the pair Fib(n + 1) and Fib(n). In other words, the Fibonacci
numbers are produced by applying T n, the nth power of the
transformationT , starting with the pair (1, 0). Now consider
T to be the special case of p = 0 and q = 1 in a family of
transformations Tpq, where Tpq transforms the pair (a; b)
according to a bq + aq + ap and b bp + aq. Show
that if we apply such a transformation Tpq twice, the eﬀect
is the same as using a single transformation Tp′q′ of the
same form, and compute p
in terms of p and q. is
gives us an explicit way to square these transformations,
and thus we can compute T n using successive squaring, as
in the fastexpt procedure. Put this all together to com
plete the following procedure, which runs in a logarithmic
number of steps:41
and q
′
′
40is algorithm, which is sometimes known as the “Russian peasant method” of
multiplication, is ancient. Examples of its use are found in the Rhind Papyrus, one of the
two oldest mathematical documents in existence, wrien about 1700 .. (and copied
from an even older document) by an Egyptian scribe named A’hmose.
41is exercise was suggested to us by Joe Stoy, based on an example in Kaldewaij
1990.
61
(define (fib n)
(fibiter 1 0 0 1 n))
(define (fibiter a b p q count)
(cond ((= count 0) b)
((even? count)
(fibiter a
b⟨??⟩
⟨??⟩
(/ count 2)))
; compute p
; compute q
′
′
(else (fibiter (+ (* b q) (* a q) (* a p))
(+ (* b p) (* a q))
p
q
( count 1)))))
1.2.5 Greatest Common Divisors
e greatest common divisor () of two integers a and b is deﬁned to
be the largest integer that divides both a and b with no remainder. For
example, the of 16 and 28 is 4. In Chapter 2, when we investigate
how to implement rationalnumber arithmetic, we will need to be able
to compute s in order to reduce rational numbers to lowest terms.
(To reduce a rational number to lowest terms, we must divide both the
numerator and the denominator by their . For example, 16/28 re
duces to 4/7.) One way to ﬁnd the of two integers is to factor them
and search for common factors, but there is a famous algorithm that is
much more eﬃcient.
e idea of the algorithm is based on the observation that, if r is the
remainder when a is divided by b, then the common divisors of a and b
are precisely the same as the common divisors of b and r. us, we can
62
use the equation
GCD(a,b) = GCD(b,r)
to successively reduce the problem of computing a to the problem
of computing the of smaller and smaller pairs of integers. For ex
ample,
GCD(206,40) = GCD(40,6)
= GCD(6,4)
= GCD(4,2)
= GCD(2,0)
= 2
reduces (, ) to (, ), which is 2. It is possible to show that
starting with any two positive integers and performing repeated reduc
tions will always eventually produce a pair where the second number is
0. en the is the other number in the pair. is method for com
puting the is known as Euclid’s Algorithm.42
It is easy to express Euclid’s Algorithm as a procedure:
(define (gcd a b)
(if (= b 0)
a
(gcd b (remainder a b))))
is generates an iterative process, whose number of steps grows as the
logarithm of the numbers involved.
42Euclid’s Algorithm is so called because it appears in Euclid’s Elements (Book 7, ca.
300 ..). According to Knuth (1973), it can be considered the oldest known nontrivial
algorithm. e ancient Egyptian method of multiplication (Exercise 1.18) is surely older,
but, as Knuth explains, Euclid’s algorithm is the oldest known to have been presented
as a general algorithm, rather than as a set of illustrative examples.
63
e fact that the number of steps required by Euclid’s Algorithm
has logarithmic growth bears an interesting relation to the Fibonacci
numbers:
Lamé’s Theorem: If Euclid’s Algorithm requires k steps to
compute the of some pair, then the smaller number in
the pair must be greater than or equal to the kth Fibonacci
number.43
We can use this theorem to get an orderofgrowth estimate for Euclid’s
p
Algorithm. Let n be the smaller of the two inputs to the procedure. If the
process takes k steps, then we must have n (cid:21) Fib(k) (cid:25) ϕk =
5. erefore
the number of steps k grows as the logarithm (to the base ϕ) of n. Hence,
the order of growth is Θ(logn).
43is theorem was proved in 1845 by Gabriel Lamé, a French mathematician and
engineer known chieﬂy for his contributions to mathematical physics. To prove the
theorem, we consider pairs (ak ; bk ), where ak (cid:21) bk , for which Euclid’s Algorithm
terminates in k steps. e proof is based on the claim that, if (ak +1; bk +1) ! (ak ; bk ) !
(ak(cid:0)1; bk(cid:0)1) are three successive pairs in the reduction process, then we must have
bk +1 (cid:21) bk + bk(cid:0)1. To verify the claim, consider that a reduction step is deﬁned by
applying the transformation ak(cid:0)1 = bk ; bk(cid:0)1 = remainder of ak divided by bk . e
second equation means that ak = qbk + bk(cid:0)1 for some positive integer q. And since q
must be at least 1 we have ak = qbk +bk(cid:0)1 (cid:21) bk +bk(cid:0)1. But in the previous reduction
step we have bk +1 = ak . erefore, bk +1 = ak (cid:21) bk +bk(cid:0)1. is veriﬁes the claim. Now
we can prove the theorem by induction on k, the number of steps that the algorithm
requires to terminate. e result is true for k = 1, since this merely requires that b be at
least as large as Fib(1) = 1. Now, assume that the result is true for all integers less than or
equal to k and establish the result for k + 1. Let (ak +1; bk +1) ! (ak ; bk ) ! (ak(cid:0)1; bk(cid:0)1)
be successive pairs in the reduction process. By our induction hypotheses, we have
bk(cid:0)1 (cid:21) Fib(k (cid:0) 1) and bk (cid:21) Fib(k). us, applying the claim we just proved together
with the deﬁnition of the Fibonacci numbers gives bk +1 (cid:21) bk +bk(cid:0)1 (cid:21) Fib(k) + Fib(k (cid:0)
1) = Fib(k + 1), which completes the proof of Lamé’s eorem.
64
Exercise 1.20: e process that a procedure generates is
of course dependent on the rules used by the interpreter.
As an example, consider the iterative gcd procedure given
above. Suppose we were to interpret this procedure using
normalorder evaluation, as discussed in Section 1.1.5. (e
normalorderevaluation rule for if is described in Exercise
1.5.) Using the substitution method (for normal order), illus
trate the process generated in evaluating (gcd 206 40) and
indicate the remainder operations that are actually per
formed. How many remainder operations are actually per
formed in the normalorder evaluation of (gcd 206 40)?
In the applicativeorder evaluation?
1.2.6 Example: Testing for Primality
p
is section describes two methods for checking the primality of an in
teger n, one with order of growth Θ(
n), and a “probabilistic” algorithm
with order of growth Θ(logn). e exercises at the end of this section
suggest programming projects based on these algorithms.
Searching for divisors
Since ancient times, mathematicians have been fascinated by problems
concerning prime numbers, and many people have worked on the prob
lem of determining ways to test if numbers are prime. One way to test
if a number is prime is to ﬁnd the number’s divisors. e following pro
gram ﬁnds the smallest integral divisor (greater than 1) of a given num
ber n. It does this in a straightforward way, by testing n for divisibility
by successive integers starting with 2.
(define (smallestdivisor n) (finddivisor n 2))
65
(define (finddivisor n testdivisor)
(cond ((> (square testdivisor) n) n)
((divides? testdivisor n) testdivisor)
(else (finddivisor n (+ testdivisor 1)))))
(define (divides? a b) (= (remainder b a) 0))
We can test whether a number is prime as follows: n is prime if and only
if n is its own smallest divisor.
(define (prime? n)
(= n (smallestdivisor n)))
p
e end test for finddivisor is based on the fact that if n is not prime it
p
n.44 is means that the algo
must have a divisor less than or equal to
n. Consequently, the num
rithm need only test divisors between 1 and
p
ber of steps required to identify n as prime will have order of growth
n).
Θ(
The Fermat test
e Θ(logn) primality test is based on a result from number theory
known as Fermat’s Lile eorem.45
p
44If d is a divisor of n, then so is n=d. But d and n=d cannot both be greater than
n.
45Pierre de Fermat (16011665) is considered to be the founder of modern number the
ory. He obtained many important numbertheoretic results, but he usually announced
just the results, without providing his proofs. Fermat’s Lile eorem was stated in a
leer he wrote in 1640. e ﬁrst published proof was given by Euler in 1736 (and an
earlier, identical proof was discovered in the unpublished manuscripts of Leibniz). e
most famous of Fermat’s results—known as Fermat’s Last eorem—was joed down
in 1637 in his copy of the book Arithmetic (by the thirdcentury Greek mathematician
Diophantus) with the remark “I have discovered a truly remarkable proof, but this mar
gin is too small to contain it.” Finding a proof of Fermat’s Last eorem became one of
the most famous challenges in number theory. A complete solution was ﬁnally given
in 1995 by Andrew Wiles of Princeton University.
66
Fermat’s Lile Theorem: If n is a prime number and a
is any positive integer less than n, then a raised to the nth
power is congruent to a modulo n.
(Two numbers are said to be congruent modulo n if they both have the
same remainder when divided by n. e remainder of a number a when
divided by n is also referred to as the remainder of a modulo n, or simply
as a modulo n.)
If n is not prime, then, in general, most of the numbers a < n will
not satisfy the above relation. is leads to the following algorithm for
testing primality: Given a number n, pick a random number a < n and
compute the remainder of an modulo n. If the result is not equal to a,
then n is certainly not prime. If it is a, then chances are good that n is
prime. Now pick another random number a and test it with the same
method. If it also satisﬁes the equation, then we can be even more con
ﬁdent that n is prime. By trying more and more values of a, we can
increase our conﬁdence in the result. is algorithm is known as the
Fermat test.
To implement the Fermat test, we need a procedure that computes
the exponential of a number modulo another number:
(define (expmod base exp m)
(cond ((= exp 0) 1)
((even? exp)
(remainder
(square (expmod base (/ exp 2) m))
m))
(else
(remainder
(* base (expmod base ( exp 1) m))
m))))
67
is is very similar to the fastexpt procedure of Section 1.2.4. It uses
successive squaring, so that the number of steps grows logarithmically
with the exponent.46
e Fermat test is performed by choosing at random a number a be
tween 1 and n(cid:0)1 inclusive and checking whether the remainder modulo
n of the nth power of a is equal to a. e random number a is chosen us
ing the procedure random, which we assume is included as a primitive
in Scheme. random returns a nonnegative integer less than its integer
input. Hence, to obtain a random number between 1 and n (cid:0) 1, we call
random with an input of n (cid:0) 1 and add 1 to the result:
(define (fermattest n)
(define (tryit a)
(= (expmod a n n) a))
(tryit (+ 1 (random ( n 1)))))
e following procedure runs the test a given number of times, as spec
iﬁed by a parameter. Its value is true if the test succeeds every time, and
false otherwise.
(define (fastprime? n times)
(cond ((= times 0) true)
((fermattest n) (fastprime? n ( times 1)))
(else false)))
46e reduction steps in the cases where the exponent e is greater than 1 are based
on the fact that, for any integers x, y, and m, we can ﬁnd the remainder of x times y
modulo m by computing separately the remainders of x modulo m and y modulo m,
multiplying these, and then taking the remainder of the result modulo m. For instance,
in the case where e is even, we compute the remainder of be=2 modulo m, square this,
and take the remainder modulo m. is technique is useful because it means we can
perform our computation without ever having to deal with numbers much larger than
m. (Compare Exercise 1.25.)
68
Probabilistic methods
e Fermat test diﬀers in character from most familiar algorithms, in
which one computes an answer that is guaranteed to be correct. Here,
the answer obtained is only probably correct. More precisely, if n ever
fails the Fermat test, we can be certain that n is not prime. But the fact
that n passes the test, while an extremely strong indication, is still not
a guarantee that n is prime. What we would like to say is that for any
number n, if we perform the test enough times and ﬁnd that n always
passes the test, then the probability of error in our primality test can be
made as small as we like.
Unfortunately, this assertion is not quite correct. ere do exist num
bers that fool the Fermat test: numbers n that are not prime and yet have
the property that an is congruent to a modulo n for all integers a < n.
Such numbers are extremely rare, so the Fermat test is quite reliable in
practice.47
ere are variations of the Fermat test that cannot be fooled. In these
tests, as with the Fermat method, one tests the primality of an integer n
by choosing a random integer a < n and checking some condition that
depends upon n and a. (See Exercise 1.28 for an example of such a test.)
On the other hand, in contrast to the Fermat test, one can prove that,
for any n, the condition does not hold for most of the integers a < n
unless n is prime. us, if n passes the test for some random choice of
47 Numbers that fool the Fermat test are called Carmichael numbers, and lile is
known about them other than that they are extremely rare. ere are 255 Carmichael
numbers below 100,000,000. e smallest few are 561, 1105, 1729, 2465, 2821, and 6601.
In testing primality of very large numbers chosen at random, the chance of stumbling
upon a value that fools the Fermat test is less than the chance that cosmic radiation will
cause the computer to make an error in carrying out a “correct” algorithm. Considering
an algorithm to be inadequate for the ﬁrst reason but not for the second illustrates the
diﬀerence between mathematics and engineering.
69
a, the chances are beer than even that n is prime. If n passes the test
for two random choices of a, the chances are beer than 3 out of 4 that
n is prime. By running the test with more and more randomly chosen
values of a we can make the probability of error as small as we like.
e existence of tests for which one can prove that the chance of
error becomes arbitrarily small has sparked interest in algorithms of this
type, which have come to be known as probabilistic algorithms. ere is
a great deal of research activity in this area, and probabilistic algorithms
have been fruitfully applied to many ﬁelds.48
Exercise 1.21: Use the smallestdivisor procedure to ﬁnd
the smallest divisor of each of the following numbers: 199,
1999, 19999.
Exercise 1.22: Most Lisp implementations include a prim
itive called runtime that returns an integer that speciﬁes
the amount of time the system has been running (mea
sured, for example, in microseconds). e following timed
primetest procedure, when called with an integern, prints
n and checks to see if n is prime. If n is prime, the procedure
prints three asterisks followed by the amount of time used
in performing the test.
48One of the most striking applications of probabilistic prime testing has been to the
ﬁeld of cryptography. Although it is now computationally infeasible to factor an arbi
trary 200digit number, the primality of such a number can be checked in a few seconds
with the Fermat test. is fact forms the basis of a technique for constructing “unbreak
able codes” suggested by Rivest et al. (1977). e resulting RSA algorithm has become
a widely used technique for enhancing the security of electronic communications. Be
cause of this and related developments, the study of prime numbers, once considered
the epitome of a topic in “pure” mathematics to be studied only for its own sake, now
turns out to have important practical applications to cryptography, electronic funds
transfer, and information retrieval.
70
(define (timedprimetest n)
(newline)
(display n)
(startprimetest n (runtime)))
(define (startprimetest n starttime)
(if (prime? n)
(reportprime ( (runtime) starttime))))
(define (reportprime elapsedtime)
(display " *** ")
(display elapsedtime))
Using this procedure, write a procedure searchforprimes
that checks the primality of consecutive odd integers in a
speciﬁed range. Use your procedure to ﬁnd the three small
est primes larger than 1000; larger than 10,000; larger than
100,000; larger than 1,000,000. Note the time needed to test
p
each prime. Since the testing algorithm has order of growth
n), you should expect that testing for primes around
of Θ(
10,000 should take about
10 times as long as testing for
primes around 1000. Do your timing data bear this out?
p
How well do the data for 100,000 and 1,000,000 support the
n) prediction? Is your result compatible with the notion
Θ(
that programs on your machine run in time proportional to
the number of steps required for the computation?
p
Exercise 1.23: e smallestdivisor procedure shown at
the start of this section does lots of needless testing: Aer it
checks to see if the number is divisible by 2 there is no point
in checking to see if it is divisible by any larger even num
bers. is suggests that the values used for testdivisor
should not be 2, 3, 4, 5, 6, : : :, but rather 2, 3, 5, 7, 9, : : :.
71
To implement this change, deﬁne a procedure next that re
turns 3 if its input is equal to 2 and otherwise returns its in
put plus 2. Modify the smallestdivisor procedure to use
(next testdivisor) instead of (+ testdivisor 1).
With timedprimetest incorporating this modiﬁed ver
sion of smallestdivisor, run the test for each of the 12
primes found in Exercise 1.22. Since this modiﬁcation halves
the number of test steps, you should expect it to run about
twice as fast. Is this expectation conﬁrmed? If not, what is
the observed ratio of the speeds of the two algorithms, and
how do you explain the fact that it is diﬀerent from 2?
Exercise 1.24: Modify the timedprimetest procedure of
Exercise 1.22 to use fastprime? (the Fermat method), and
test each of the 12 primes you found in that exercise. Since
the Fermat test has Θ(logn) growth, how would you expect
the time to test primes near 1,000,000 to compare with the
time needed to test primes near 1000? Do your data bear
this out? Can you explain any discrepancy you ﬁnd?
Exercise 1.25: Alyssa P. Hacker complains that we went to
a lot of extra work in writing expmod. Aer all, she says,
since we already know how to compute exponentials, we
could have simply wrien
(define (expmod base exp m)
(remainder (fastexpt base exp) m))
Is she correct? Would this procedure serve as well for our
fast prime tester? Explain.
72
Exercise 1.26: Louis Reasoner is having great diﬃculty do
ing Exercise 1.24. His fastprime? test seems to run more
slowly than his prime? test. Louis calls his friend Eva Lu
Ator over to help. When they examine Louis’s code, they
ﬁnd that he has rewrien the expmod procedure to use an
explicit multiplication, rather than calling square:
(define (expmod base exp m)
(cond ((= exp 0) 1)
((even? exp)
(remainder (* (expmod base (/ exp 2) m)
(expmod base (/ exp 2) m))
m))
(else
(remainder (* base
(expmod base ( exp 1) m))
m))))
“I don’t see what diﬀerence that could make,” says Louis.
“I do.” says Eva. “By writing the procedure like that, you
have transformed the Θ(logn) process into a Θ(n) process.”
Explain.
Exercise 1.27: Demonstrate that the Carmichael numbers
listed in Footnote 1.47 really do fool the Fermat test. at is,
write a procedure that takes an integer n and tests whether
an is congruent to a modulo n for every a < n, and try your
procedure on the given Carmichael numbers.
Exercise 1.28: One variant of the Fermat test that cannot
be fooled is called the MillerRabin test (Miller 1976; Rabin
1980). is starts from an alternate form of Fermat’s Lile
73
eorem, which states that if n is a prime number and a is
any positive integer less than n, then a raised to the (n(cid:0)1)st
power is congruent to 1 modulo n. To test the primality of a
number n by the MillerRabin test, we pick a random num
ber a < n and raise a to the (n(cid:0) 1)st power modulo n using
the expmod procedure. However, whenever we perform the
squaring step in expmod, we check to see if we have discov
ered a “nontrivial square root of 1 modulo n,” that is, a num
ber not equal to 1 or n(cid:0)1 whose square is equal to 1 modulo
n. It is possible to prove that if such a nontrivial square root
of 1 exists, then n is not prime. It is also possible to prove
that if n is an odd number that is not prime, then, for at least
half the numbers a < n, computing an(cid:0)1 in this way will
reveal a nontrivial square root of 1 modulo n. (is is why
the MillerRabin test cannot be fooled.) Modify the expmod
procedure to signal if it discovers a nontrivial square root
of 1, and use this to implement the MillerRabin test with
a procedure analogous to fermattest. Check your pro
cedure by testing various known primes and nonprimes.
Hint: One convenient way to make expmod signal is to have
it return 0.
1.3 Formulating Abstractions
with HigherOrder Procedures
We have seen that procedures are, in eﬀect, abstractions that describe
compound operations on numbers independent of the particular num
bers. For example, when we
74
(define (cube x) (* x x x))
we are not talking about the cube of a particular number, but rather
about a method for obtaining the cube of any number. Of course we
could get along without ever deﬁning this procedure, by always writing
expressions such as
(* 3 3 3)
(* x x x)
(* y y y)
and never mentioning cube explicitly. is would place us at a serious
disadvantage, forcing us to work always at the level of the particular op
erations that happen to be primitives in the language (multiplication, in
this case) rather than in terms of higherlevel operations. Our programs
would be able to compute cubes, but our language would lack the ability
to express the concept of cubing. One of the things we should demand
from a powerful programming language is the ability to build abstrac
tions by assigning names to common paerns and then to work in terms
of the abstractions directly. Procedures provide this ability. is is why
all but the most primitive programming languages include mechanisms
for deﬁning procedures.
Yet even in numerical processing we will be severely limited in our
ability to create abstractions if we are restricted to procedures whose pa
rameters must be numbers. Oen the same programming paern will
be used with a number of diﬀerent procedures. To express such paerns
as concepts, we will need to construct procedures that can accept pro
cedures as arguments or return procedures as values. Procedures that
manipulate procedures are called higherorder procedures. is section
shows how higherorder procedures can serve as powerful abstraction
mechanisms, vastly increasing the expressive power of our language.
75
1.3.1 Procedures as Arguments
Consider the following three procedures. e ﬁrst computes the sum of
the integers from a through b:
(define (sumintegers a b)
(if (> a b)
0
(+ a (sumintegers (+ a 1) b))))
e second computes the sum of the cubes of the integers in the given
range:
(define (sumcubes a b)
(if (> a b)
0
(+ (cube a)
(sumcubes (+ a 1) b))))
e third computes the sum of a sequence of terms in the series
1
9 (cid:1) 11
which converges to π =8 (very slowly):49
1
5 (cid:1) 7
1
1 (cid:1) 3
+
+
+ : : : ;
(define (pisum a b)
(if (> a b)
0
(+ (/ 1.0 (* a (+ a 2)))
(pisum (+ a 4) b))))
49is series, usually wrien in the equivalent form π
4
7 + : : :, is due
to Leibniz. We’ll see how to use this as the basis for some fancy numerical tricks in
Section 3.5.3.
3 + 1
5
= 1 (cid:0) 1
(cid:0) 1
76
ese three procedures clearly share a common underlying paern.
ey are for the most part identical, diﬀering only in the name of the
procedure, the function of a used to compute the term to be added, and
the function that provides the next value of a. We could generate each
of the procedures by ﬁlling in slots in the same template:
(define (⟨name⟩ a b)
(if (> a b)
0
(+ (⟨term⟩ a)
(⟨name⟩ (⟨next⟩ a) b))))
e presence of such a common paern is strong evidence that there is
a useful abstraction waiting to be brought to the surface. Indeed, math
ematicians long ago identiﬁed the abstraction of summation of a series
and invented “sigma notation,” for example
b∑
f (n) = f (a) + (cid:1) (cid:1) (cid:1) + f (b);
n=a
to express this concept. e power of sigma notation is that it allows
mathematicians to deal with the concept of summation itself rather than
only with particular sums—for example, to formulate general results
about sums that are independent of the particular series being summed.
Similarly, as program designers, we would like our language to be
powerful enough so that we can write a procedure that expresses the
concept of summation itself rather than only procedures that compute
particular sums. We can do so readily in our procedural language by
taking the common template shown above and transforming the “slots”
into formal parameters:
(define (sum term a next b)
(if (> a b)
77
0
(+ (term a)
(sum term (next a) next b))))
Notice that sum takes as its arguments the lower and upper bounds a
and b together with the procedures term and next. We can use sum just
as we would any procedure. For example, we can use it (along with a
procedure inc that increments its argument by 1) to deﬁne sumcubes:
(define (inc n) (+ n 1))
(define (sumcubes a b)
(sum cube a inc b))
Using this, we can compute the sum of the cubes of the integers from 1
to 10:
(sumcubes 1 10)
3025
With the aid of an identity procedure to compute the term, we can deﬁne
sumintegers in terms of sum:
(define (identity x) x)
(define (sumintegers a b)
(sum identity a inc b))
en we can add up the integers from 1 to 10:
(sumintegers 1 10)
55
We can also deﬁne pisum in the same way:50
50Notice that we have used block structure (Section 1.1.8) to embed the deﬁnitions of
pinext and piterm within pisum, since these procedures are unlikely to be useful
for any other purpose. We will see how to get rid of them altogether in Section 1.3.2.
78
(define (pisum a b)
(define (piterm x)
(/ 1.0 (* x (+ x 2))))
(define (pinext x)
(+ x 4))
(sum piterm a pinext b))
Using these procedures, we can compute an approximation to π:
(* 8 (pisum 1 1000))
3.139592655589783
Once we have sum, we can use it as a building block in formulating fur
ther concepts. For instance, the deﬁnite integral of a function f between
the limits a and b can be approximated numerically using the formula
[
(
∫
b
f =
a
)
dx
2
(
(
)
dx
2
f
a +
+ f
a + dx +
+ f
a + 2dx +
+ : : :
dx
]
)
dx
2
for small values of dx. We can express this directly as a procedure:
(define (integral f a b dx)
(define (adddx x)
(+ x dx))
(* (sum f (+ a (/ dx 2.0)) adddx b)
dx))
(integral cube 0 1 0.01)
.24998750000000042
(integral cube 0 1 0.001)
.249999875000001
(e exact value of the integral of cube between 0 and 1 is 1/4.)
79
Exercise 1.29: Simpson’s Rule is a more accurate method
of numerical integration than the method illustrated above.
Using Simpson’s Rule, the integral of a function f between
a and b is approximated as
(y0 + 4y1 + 2y2 + 4y3 + 2y4 + (cid:1) (cid:1) (cid:1) + 2yn(cid:0)2 + 4yn(cid:0)1 + yn);
h
3
where h = (b (cid:0) a)=n, for some even integer n, and yk =
f (a + kh). (Increasing n increases the accuracy of the ap
proximation.) Deﬁne a procedure that takes as arguments
f , a, b, and n and returns the value of the integral, com
puted using Simpson’s Rule. Use your procedure to inte
grate cube between 0 and 1 (with n = 100 and n = 1000),
and compare the results to those of the integral procedure
shown above.
Exercise 1.30: e sum procedure above generates a linear
recursion. e procedure can be rewrien so that the sum
is performed iteratively. Show how to do this by ﬁlling in
the missing expressions in the following deﬁnition:
(define (sum term a next b)
(define (iter a result)
(if ⟨??⟩
⟨??⟩
(iter ⟨??⟩ ⟨??⟩)))
(iter ⟨??⟩ ⟨??⟩))
Exercise 1.31:
a. e sum procedure is only the simplest of a vast num
ber of similar abstractions that can be captured as higher
80
order procedures.51 Write an analogous procedure called
product that returns the product of the values of a
function at points over a given range. Show how to de
ﬁne factorial in terms of product. Also use product
to compute approximations to π using the formula52
= 2 (cid:1) 4 (cid:1) 4 (cid:1) 6 (cid:1) 6 (cid:1) 8(cid:1) (cid:1) (cid:1)
3 (cid:1) 3 (cid:1) 5 (cid:1) 5 (cid:1) 7 (cid:1) 7(cid:1) (cid:1) (cid:1) :
π
4
b. If your product procedure generates a recursive pro
cess, write one that generates an iterative process. If
it generates an iterative process, write one that gen
erates a recursive process.
Exercise 1.32:
a. Show that sum and product (Exercise 1.31) are both
special cases of a still more general notion called accumulate
that combines a collection of terms, using some gen
eral accumulation function:
(accumulate combiner nullvalue term a next b)
51e intent of Exercise 1.31 through Exercise 1.33 is to demonstrate the expressive
power that is aained by using an appropriate abstraction to consolidate many seem
ingly disparate operations. However, though accumulation and ﬁltering are elegant
ideas, our hands are somewhat tied in using them at this point since we do not yet
have data structures to provide suitable means of combination for these abstractions.
We will return to these ideas in Section 2.2.3 when we show how to use sequences as
interfaces for combining ﬁlters and accumulators to build even more powerful abstrac
tions. We will see there how these methods really come into their own as a powerful
and elegant approach to designing programs.
52is formula was discovered by the seventeenthcentury English mathematician
John Wallis.
81
accumulate takes as arguments the same term and
range speciﬁcations as sum and product, together with
a combiner procedure (of two arguments) that speci
ﬁes how the current term is to be combined with the
accumulation of the preceding terms and a nullvalue
that speciﬁes what base value to use when the terms
run out. Write accumulate and show how sum and
product can both be deﬁned as simple calls to accumulate.
b. If your accumulate procedure generates a recursive
process, write one that generates an iterative process.
If it generates an iterative process, write one that gen
erates a recursive process.
Exercise 1.33: You can obtain an even more general ver
sion of accumulate (Exercise 1.32) by introducing the no
tion of a ﬁlter on the terms to be combined. at is, combine
only those terms derived from values in the range that sat
isfy a speciﬁed condition. e resulting filteredaccumulate
abstraction takes the same arguments as accumulate, to
gether with an additional predicate of one argument that
speciﬁes the ﬁlter. Write filteredaccumulate as a proce
dure. Show how to express the following using filtered
accumulate:
a. the sum of the squares of the prime numbers in the
interval a to b (assuming that you have a prime? pred
icate already wrien)
b. the product of all the positive integers less than n that
are relatively prime to n (i.e., all positive integersi < n
such that (i; n) = 1).
82
1.3.2 Constructing Procedures Using lambda
In using sum as in Section 1.3.1, it seems terribly awkward to have to
deﬁne trivial procedures such as piterm and pinext just so we can
use them as arguments to our higherorder procedure. Rather than de
ﬁne pinext and piterm, it would be more convenient to have a way
to directly specify “the procedure that returns its input incremented by
4” and “the procedure that returns the reciprocal of its input times its
input plus 2.” We can do this by introducing the special form lambda,
which creates procedures. Using lambda we can describe what we want
as
(lambda (x) (+ x 4))
and
(lambda (x) (/ 1.0 (* x (+ x 2))))
en our pisum procedure can be expressed without deﬁning any aux
iliary procedures as
(define (pisum a b)
(sum (lambda (x) (/ 1.0 (* x (+ x 2))))
a
(lambda (x) (+ x 4))
b))
Again using lambda, we can write the integral procedure without hav
ing to deﬁne the auxiliary procedure adddx:
(define (integral f a b dx)
(* (sum f
(+ a (/ dx 2.0))
(lambda (x) (+ x dx))
b)
dx))
83
In general, lambda is used to create procedures in the same way as
define, except that no name is speciﬁed for the procedure:
(lambda (⟨formalparameters⟩) ⟨body⟩)
e resulting procedure is just as much a procedure as one that is cre
ated using define. e only diﬀerence is that it has not been associated
with any name in the environment. In fact,
(define (plus4 x) (+ x 4))
is equivalent to
(define plus4 (lambda (x) (+ x 4)))
We can read a lambda expression as follows:
(lambda
4))

the procedure of an argument x that adds x and 4
(x)

(+

x


Like any expression that has a procedure as its value, a lambda expres
sion can be used as the operator in a combination such as
((lambda (x y z) (+ x y (square z)))
1 2 3)
12
or, more generally, in any context where we would normally use a pro
cedure name.53
53It would be clearer and less intimidating to people learning Lisp if a name more
obvious than lambda, such as makeprocedure, were used. But the convention is ﬁrmly
entrenched. e notation is adopted from the λcalculus, a mathematical formalism in
troduced by the mathematical logician Alonzo Church (1941). Church developed the
λcalculus to provide a rigorous foundation for studying the notions of function and
function application. e λcalculus has become a basic tool for mathematical investi
gations of the semantics of programming languages.
84
Using let to create local variables
Another use of lambda is in creating local variables. We oen need lo
cal variables in our procedures other than those that have been bound
as formal parameters. For example, suppose we wish to compute the
function
f (x ; y) = x(1 + xy)2 + y(1 (cid:0) y) + (1 + xy)(1 (cid:0) y);
which we could also express as
a = 1 + xy;
b = 1 (cid:0) y;
f (x ; y) = xa2 + yb + ab:
In writing a procedure to compute f , we would like to include as local
variables not only x and y but also the names of intermediate quantities
like a and b. One way to accomplish this is to use an auxiliary procedure
to bind the local variables:
(define (f x y)
(define (fhelper a b)
(+ (* x (square a))
(* y b)
(* a b)))
(fhelper (+ 1 (* x y))
( 1 y)))
Of course, we could use a lambda expression to specify an anonymous
procedure for binding our local variables. e body of f then becomes
a single call to that procedure:
(define (f x y)
((lambda (a b)
85
(+ (* x (square a))
(* y b)
(* a b)))
(+ 1 (* x y))
( 1 y)))
is construct is so useful that there is a special form called let to make
its use more convenient. Using let, the f procedure could be wrien as
(define (f x y)
(let ((a (+ 1 (* x y)))
(b ( 1 y)))
(+ (* x (square a))
(* y b)
(* a b))))
e general form of a let expression is
(let ((⟨var1⟩ ⟨exp1⟩)
(⟨var2⟩ ⟨exp2⟩)
(⟨varn⟩ ⟨expn⟩))
: : :
⟨body⟩)
which can be thought of as saying
let ⟨var1⟩ have the value ⟨exp1⟩ and
⟨var2⟩ have the value ⟨exp2⟩ and
: : :⟨varn⟩ have the value ⟨expn⟩
in ⟨body⟩
e ﬁrst part of the let expression is a list of nameexpression pairs.
When the let is evaluated, each name is associated with the value of
the corresponding expression. e body of the let is evaluated with
these names bound as local variables. e way this happens is that the
let expression is interpreted as an alternate syntax for
86
⟨body⟩)
((lambda (⟨var1⟩ : : : ⟨varn⟩)
⟨exp1⟩
: : :⟨expn⟩)
No new mechanism is required in the interpreter in order to provide
local variables. A let expression is simply syntactic sugar for the un
derlying lambda application.
We can see from this equivalence that the scope of a variable spec
iﬁed by a let expression is the body of the let. is implies that:
• let allows one to bind variables as locally as possible to where
they are to be used. For example, if the value of x is 5, the value
of the expression
(+ (let ((x 3))
(+ x (* x 10)))
x)
is 38. Here, the x in the body of the let is 3, so the value of the
let expression is 33. On the other hand, the x that is the second
argument to the outermost + is still 5.
• e variables’ values are computed outside the let. is maers
when the expressions that provide the values for the local vari
ables depend upon variables having the same names as the local
variables themselves. For example, if the value of x is 2, the ex
pression
(let ((x 3)
(y (+ x 2)))
(* x y))
87
will have the value 12 because, inside the body of the let, x will
be 3 and y will be 4 (which is the outer x plus 2).
Sometimes we can use internal deﬁnitions to get the same eﬀect as with
let. For example, we could have deﬁned the procedure f above as
(define (f x y)
(define a (+ 1 (* x y)))
(define b ( 1 y))
(+ (* x (square a))
(* y b)
(* a b)))
We prefer, however, to use let in situations like this and to use internal
define only for internal procedures.54
Exercise 1.34: Suppose we deﬁne the procedure
(define (f g) (g 2))
en we have
(f square)
4
(f (lambda (z) (* z (+ z 1))))
6
What happens if we (perversely) ask the interpreter to eval
uate the combination (f f)? Explain.
54Understanding internal deﬁnitions well enough to be sure a program means what
we intend it to mean requires a more elaborate model of the evaluation process than we
have presented in this chapter. e subtleties do not arise with internal deﬁnitions of
procedures, however. We will return to this issue in Section 4.1.6, aer we learn more
about evaluation.
88
1.3.3 Procedures as General Methods
We introduced compound procedures in Section 1.1.4 as a mechanism
for abstracting paerns of numerical operations so as to make them in
dependent of the particular numbers involved. With higherorder pro
cedures, such as the integral procedure of Section 1.3.1, we began to
see a more powerful kind of abstraction: procedures used to express
general methods of computation, independent of the particular func
tions involved. In this section we discuss two more elaborate examples—
general methods for ﬁnding zeros and ﬁxed points of functions—and
show how these methods can be expressed directly as procedures.
Finding roots of equations by the halfinterval method
e halfinterval method is a simple but powerful technique for ﬁnding
roots of an equation f (x) = 0, where f is a continuous function. e
idea is that, if we are given points a and b such that f (a) < 0 < f (b),
then f must have at least one zero between a and b. To locate a zero,
let x be the average of a and b, and compute f (x). If f (x) > 0, then
f must have a zero between a and x. If f (x) < 0, then f must have a
zero between x and b. Continuing in this way, we can identify smaller
and smaller intervals on which f must have a zero. When we reach a
point where the interval is small enough, the process stops. Since the
interval of uncertainty is reduced by half at each step of the process, the
number of steps required grows as Θ(log(L=T )), where L is the length
of the original interval and T is the error tolerance (that is, the size of
the interval we will consider “small enough”). Here is a procedure that
implements this strategy:
(define (search f negpoint pospoint)
(let ((midpoint (average negpoint pospoint)))
89
(if (closeenough? negpoint pospoint)
midpoint
(let ((testvalue (f midpoint)))
(cond ((positive? testvalue)
(search f negpoint midpoint))
((negative? testvalue)
(search f midpoint pospoint))
(else midpoint))))))
We assume that we are initially given the function f
together with
points at which its values are negative and positive. We ﬁrst compute
the midpoint of the two given points. Next we check to see if the given
interval is small enough, and if so we simply return the midpoint as our
answer. Otherwise, we compute as a test value the value of f at the mid
point. If the test value is positive, then we continue the process with a
new interval running from the original negative point to the midpoint.
If the test value is negative, we continue with the interval from the mid
point to the positive point. Finally, there is the possibility that the test
value is 0, in which case the midpoint is itself the root we are searching
for.
To test whether the endpoints are “close enough” we can use a pro
cedure similar to the one used in Section 1.1.7 for computing square
roots:55
(define (closeenough? x y) (< (abs ( x y)) 0.001))
search is awkward to use directly, because we can accidentally give it
points at which f ’s values do not have the required sign, in which case
55We have used 0.001 as a representative “small” number to indicate a tolerance for
the acceptable error in a calculation. e appropriate tolerance for a real calculation
depends upon the problem to be solved and the limitations of the computer and the
algorithm. is is oen a very subtle consideration, requiring help from a numerical
analyst or some other kind of magician.
90
we get a wrong answer. Instead we will use search via the following
procedure, which checks to see which of the endpoints has a negative
function value and which has a positive value, and calls the search pro
cedure accordingly. If the function has the same sign on the two given
points, the halfinterval method cannot be used, in which case the pro
cedure signals an error.56
(define (halfintervalmethod f a b)
(let ((avalue (f a))
(bvalue (f b)))
(cond ((and (negative? avalue) (positive? bvalue))
(search f a b))
((and (negative? bvalue) (positive? avalue))
(search f b a))
(else
(error "Values are not of opposite sign" a b)))))
e following example uses the halfinterval method to approximate π
as the root between 2 and 4 of sin x = 0:
(halfintervalmethod sin 2.0 4.0)
3.14111328125
Here is another example, using the halfinterval method to search for a
root of the equation x 3 (cid:0) 2x (cid:0) 3 = 0 between 1 and 2:
(halfintervalmethod (lambda (x) ( (* x x x) (* 2 x) 3))
1.0
2.0)
1.89306640625
56is can be accomplished using error, which takes as arguments a number of items
that are printed as error messages.
91
Finding fixed points of functions
A number x is called a ﬁxed point of a function f if x satisﬁes the equa
tion f (x) = x. For some functions f we can locate a ﬁxed point by
beginning with an initial guess and applying f repeatedly,
f (x);
f (f (x));
f (f (f (x)));
: : : ;
until the value does not change very much. Using this idea, we can de
vise a procedure fixedpoint that takes as inputs a function and an
initial guess and produces an approximation to a ﬁxed point of the func
tion. We apply the function repeatedly until we ﬁnd two successive val
ues whose diﬀerence is less than some prescribed tolerance:
(define tolerance 0.00001)
(define (fixedpoint f firstguess)
(define (closeenough? v1 v2)
(< (abs ( v1 v2))
tolerance))
(define (try guess)
(let ((next (f guess)))
(if (closeenough? guess next)
next
(try next))))
(try firstguess))
For example, we can use this method to approximate the ﬁxed point of
the cosine function, starting with 1 as an initial approximation:57
(fixedpoint cos 1.0)
.7390822985224023
Similarly, we can ﬁnd a solution to the equation y = sin y + cos y:
57Try this during a boring lecture: Set your calculator to radians mode and then
repeatedly press the cos buon until you obtain the ﬁxed point.
92
(fixedpoint (lambda (y) (+ (sin y) (cos y)))
1.0)
1.2587315962971173
e ﬁxedpoint process is reminiscent of the process we used for ﬁnding
square roots in Section 1.1.7. Both are based on the idea of repeatedly
improving a guess until the result satisﬁes some criterion. In fact, we can
readily formulate the squareroot computation as a ﬁxedpoint search.
Computing the square root of some number x requires ﬁnding a y such
that y2 = x. Puing this equation into the equivalent form y = x=y,
we recognize that we are looking for a ﬁxed point of the function58
y 7! x=y, and we can therefore try to compute square roots as
(define (sqrt x)
(fixedpoint (lambda (y) (/ x y))
1.0))
Unfortunately, this ﬁxedpoint search does not converge. Consider an
initial guess y1. e next guess is y2 = x=y1 and the next guess is y3 =
x=y2 = x=(x=y1) = y1. is results in an inﬁnite loop in which the two
guesses y1 and y2 repeat over and over, oscillating about the answer.
One way to control such oscillations is to prevent the guesses from
changing so much. Since the answer is always between our guess y and
x=y, we can make a new guess that is not as far from y as x=y by av
eraging y with x=y, so that the next guess aer y is 1
2(y + x=y) instead
of x=y. e process of making such a sequence of guesses is simply the
process of looking for a ﬁxed point of y 7! 1
2(y + x=y):
(define (sqrt x)
(fixedpoint (lambda (y) (average y (/ x y)))
1.0))
587! (pronounced “maps to”) is the mathematician’s way of writing lambda. y 7! x=y
means (lambda (y) (/ x y)), that is, the function whose value at y is x=y.
93
(Note that y = 1
2(y + x=y) is a simple transformation of the equation
y = x=y; to derive it, add y to both sides of the equation and divide by
2.)
With this modiﬁcation, the squareroot procedure works. In fact, if
we unravel the deﬁnitions, we can see that the sequence of approxi
mations to the square root generated here is precisely the same as the
one generated by our original squareroot procedure of Section 1.1.7.
is approach of averaging successive approximations to a solution, a
technique that we call average damping, oen aids the convergence of
ﬁxedpoint searches.
Exercise 1.35: Show that the golden ratio ϕ (Section 1.2.2)
is a ﬁxed point of the transformation x 7! 1 + 1=x, and
use this fact to compute ϕ by means of the fixedpoint
procedure.
Exercise 1.36: Modify fixedpoint so that it prints the
sequence of approximations it generates, using the newline
and display primitives shown in Exercise 1.22. en ﬁnd
a solution to x x = 1000 by ﬁnding a ﬁxed point of x 7!
log(1000)= log(x). (Use Scheme’s primitive log procedure,
which computes natural logarithms.) Compare the number
of steps this takes with and without average damping. (Note
that you cannot start fixedpoint with a guess of 1, as this
would cause division by log(1) = 0.)
Exercise 1.37:
a. An inﬁnite continued fraction is an expression of the
94
form
f =
D1 +
N1
N2
:
D2 +
N3
D3 + : : :
As an example, one can show that the inﬁnite con
tinued fraction expansion with the Ni and the Di all
equal to 1 produces 1=ϕ, where ϕ is the golden ratio
(described in Section 1.2.2). One way to approximate
an inﬁnite continued fraction is to truncate the expan
sion aer a given number of terms. Such a truncation—
a socalled kterm ﬁnite continued fraction—has the form
D1 +
:
N1
N2
: : : +
Nk
Dk
Suppose that n and d are procedures of one argument
(the term index i) that return the Ni and Di of the
terms of the continued fraction. Deﬁne a procedure
contfrac such that evaluating (contfrac n d k)
computes the value of the kterm ﬁnite continued frac
tion. Check your procedure by approximating 1=ϕ us
ing
(contfrac (lambda (i) 1.0)
(lambda (i) 1.0)
k)
95
for successive values of k. How large must you make
k in order to get an approximation that is accurate to
4 decimal places?
b. If your contfrac procedure generates a recursive pro
cess, write one that generates an iterative process. If
it generates an iterative process, write one that gen
erates a recursive process.
Exercise 1.38: In 1737, the Swiss mathematician Leonhard
Euler published a memoir De Fractionibus Continuis, which
included a continued fraction expansion for e (cid:0) 2, where
e is the base of the natural logarithms. In this fraction, the
Ni are all 1, and the Di are successively 1, 2, 1, 1, 4, 1, 1,
6, 1, 1, 8, : : :. Write a program that uses your contfrac
procedure from Exercise 1.37 to approximate e, based on
Euler’s expansion.
Exercise 1.39: A continued fraction representation of the
tangent function was published in 1770 by the German math
ematician J.H. Lambert:
tan x =
;
x
1 (cid:0)
x 2
3 (cid:0) x 2
5 (cid:0) : : :
where x is in radians. Deﬁne a procedure (tancf x k) that
computes an approximation to the tangent function based
on Lambert’s formula. k speciﬁes the number of terms to
compute, as in Exercise 1.37.
96
1.3.4 Procedures as Returned Values
e above examples demonstrate how the ability to pass procedures as
arguments signiﬁcantly enhances the expressive power of our program
ming language. We can achieve even more expressive power by creating
procedures whose returned values are themselves procedures.
We can illustrate this idea by looking again at the ﬁxedpoint exam
ple described at the end of Section 1.3.3. We formulated a new version
p
of the squareroot procedure as a ﬁxedpoint search, starting with the
x is a ﬁxedpoint of the function y 7! x=y. en we
observation that
used average damping to make the approximations converge. Average
damping is a useful general technique in itself. Namely, given a function
f , we consider the function whose value at x is equal to the average of
x and f (x).
We can express the idea of average damping by means of the fol
lowing procedure:
(define (averagedamp f)
(lambda (x) (average x (f x))))
averagedamp is a procedure that takes as its argument a procedure
f and returns as its value a procedure (produced by the lambda) that,
when applied to a number x, produces the average of x and (f x). For
example, applying averagedamp to the square procedure produces a
procedure whose value at some number x is the average of x and x 2.
Applying this resulting procedure to 10 returns the average of 10 and
100, or 55:59
59Observe that this is a combination whose operator is itself a combination. Exercise
1.4 already demonstrated the ability to form such combinations, but that was only a toy
example. Here we begin to see the real need for such combinations—when applying a
procedure that is obtained as the value returned by a higherorder procedure.
97
((averagedamp square) 10)
55
Using averagedamp, we can reformulate the squareroot procedure as
follows:
(define (sqrt x)
(fixedpoint (averagedamp (lambda (y) (/ x y)))
1.0))
Notice how this formulation makes explicit the three ideas in the method:
ﬁxedpoint search, average damping, and the function y 7! x=y. It is in
structive to compare this formulation of the squareroot method with
the original version given in Section 1.1.7. Bear in mind that these pro
cedures express the same process, and notice how much clearer the idea
becomes when we express the process in terms of these abstractions. In
general, there are many ways to formulate a process as a procedure. Ex
perienced programmers know how to choose procedural formulations
that are particularly perspicuous, and where useful elements of the pro
cess are exposed as separate entities that can be reused in other appli
cations. As a simple example of reuse, notice that the cube root of x is a
ﬁxed point of the function y 7! x=y2, so we can immediately generalize
our squareroot procedure to one that extracts cube roots:60
(define (cuberoot x)
(fixedpoint (averagedamp (lambda (y) (/ x (square y))))
1.0))
Newton’s method
When we ﬁrst introduced the squareroot procedure, in Section 1.1.7, we
mentioned that this was a special case of Newton’s method. If x 7! д(x)
60See Exercise 1.45 for a further generalization.
98
is a diﬀerentiable function, then a solution of the equation д(x) = 0 is a
ﬁxed point of the function x 7! f (x), where
f (x) = x (cid:0) д(x)
Dд(x)
and Dд(x) is the derivative of д evaluated at x. Newton’s method is the
use of the ﬁxedpoint method we saw above to approximate a solution
of the equation by ﬁnding a ﬁxed point of the function f:61
For many functions д and for suﬃciently good initial guesses for x,
Newton’s method converges very rapidly to a solution of д(x) = 0:62
In order to implement Newton’s method as a procedure, we must
ﬁrst express the idea of derivative. Note that “derivative,” like average
damping, is something that transforms a function into another function.
For instance, the derivative of the function x 7! x 3 is the function x 7!
3x 2: In general, if д is a function and dx is a small number, then the
derivative Dд of д is the function whose value at any number x is given
(in the limit of small dx) by
Dд(x) = д(x + dx) (cid:0) д(x)
:
dx
us, we can express the idea of derivative (taking dx to be, say, 0.00001)
as the procedure
(define (deriv g)
(lambda (x) (/ ( (g (+ x dx)) (g x)) dx)))
61Elementary calculus books usually describe Newton’s method in terms of the se
quence of approximations xn+1 = xn(cid:0)д(xn)=Dд(xn). Having language for talking about
processes and using the idea of ﬁxed points simpliﬁes the description of the method.
62Newton’s method does not always converge to an answer, but it can be shown
that in favorable cases each iteration doubles the numberofdigits accuracy of the ap
proximation to the solution. In such cases, Newton’s method will converge much more
rapidly than the halfinterval method.
99
along with the deﬁnition
(define dx 0.00001)
Like averagedamp, deriv is a procedure that takes a procedure as ar
gument and returns a procedure as value. For example, to approximate
the derivative of x 7! x 3 at 5 (whose exact value is 75) we can evaluate
(define (cube x) (* x x x))
((deriv cube) 5)
75.00014999664018
With the aid of deriv, we can express Newton’s method as a ﬁxedpoint
process:
(define (newtontransform g)
(lambda (x) ( x (/ (g x) ((deriv g) x)))))
(define (newtonsmethod g guess)
(fixedpoint (newtontransform g) guess))
e newtontransform procedure expresses the formula at the begin
ning of this section, and newtonsmethod is readily deﬁned in terms of
this. It takes as arguments a procedure that computes the function for
which we want to ﬁnd a zero, together with an initial guess. For in
stance, to ﬁnd the square root of x, we can use Newton’s method to ﬁnd
a zero of the function y 7! y2 (cid:0) x starting with an initial guess of 1.63
is provides yet another form of the squareroot procedure:
(define (sqrt x)
(newtonsmethod
(lambda (y) ( (square y) x)) 1.0))
63For ﬁnding square roots, Newton’s method converges rapidly to the correct solu
tion from any starting point.
100
Abstractions and firstclass procedures
We’ve seen two ways to express the squareroot computation as an in
stance of a more general method, once as a ﬁxedpoint search and once
using Newton’s method. Since Newton’s method was itself expressed
as a ﬁxedpoint process, we actually saw two ways to compute square
roots as ﬁxed points. Each method begins with a function and ﬁnds a
ﬁxed point of some transformation of the function. We can express this
general idea itself as a procedure:
(define (fixedpointoftransform g transform guess)
(fixedpoint (transform g) guess))
is very general procedure takes as its arguments a procedure g that
computes some function, a procedure that transforms g, and an initial
guess. e returned result is a ﬁxed point of the transformed function.
Using this abstraction, we can recast the ﬁrst squareroot computa
tion from this section (where we look for a ﬁxed point of the average
damped version of y 7! x=y) as an instance of this general method:
(define (sqrt x)
(fixedpointoftransform
(lambda (y) (/ x y)) averagedamp 1.0))
Similarly, we can express the second squareroot computation from this
section (an instance of Newton’s method that ﬁnds a ﬁxed point of the
Newton transform of y 7! y2 (cid:0) x) as
(define (sqrt x)
(fixedpointoftransform
(lambda (y) ( (square y) x)) newtontransform 1.0))
We began Section 1.3 with the observation that compound procedures
are a crucial abstraction mechanism, because they permit us to express
general methods of computing as explicit elements in our programming
101
language. Now we’ve seen how higherorder procedures permit us to
manipulate these general methods to create further abstractions.
As programmers, we should be alert to opportunities to identify the
underlying abstractions in our programs and to build upon them and
generalize them to create more powerful abstractions. is is not to
say that one should always write programs in the most abstract way
possible; expert programmers know how to choose the level of abstrac
tion appropriate to their task. But it is important to be able to think in
terms of these abstractions, so that we can be ready to apply them in
new contexts. e signiﬁcance of higherorder procedures is that they
enable us to represent these abstractions explicitly as elements in our
programming language, so that they can be handled just like other com
putational elements.
In general, programming languages impose restrictions on the ways
in which computational elements can be manipulated. Elements with
the fewest restrictions are said to have ﬁrstclass status. Some of the
“rights and privileges” of ﬁrstclass elements are:64
• ey may be named by variables.
• ey may be passed as arguments to procedures.
• ey may be returned as the results of procedures.
• ey may be included in data structures.65
Lisp, unlike other common programming languages, awards procedures
full ﬁrstclass status. is poses challenges for eﬃcient implementation,
64e notion of ﬁrstclass status of programminglanguage elements is due to the
British computer scientist Christopher Strachey (19161975).
65We’ll see examples of this aer we introduce data structures in Chapter 2.
102
but the resulting gain in expressive power is enormous.66
Exercise 1.40: Deﬁne a procedure cubic that can be used
together with the newtonsmethod procedure in expressions
of the form
(newtonsmethod (cubic a b c) 1)
to approximate zeros of the cubic x 3 + ax 2 + bx + c.
Exercise 1.41: Deﬁne a procedure double that takes a pro
cedure of one argument as argument and returns a proce
dure that applies the original procedure twice. For exam
ple, if inc is a procedure that adds 1 to its argument, then
(double inc) should be a procedure that adds 2. What
value is returned by
(((double (double double)) inc) 5)
Exercise 1.42: Let f and д be two oneargument functions.
e composition f aer д is deﬁned to be the function x 7!
f (д(x)). Deﬁne a procedure compose that implements com
position. For example, if inc is a procedure that adds 1 to
its argument,
((compose square inc) 6)
49
66e major implementation cost of ﬁrstclass procedures is that allowing procedures
to be returned as values requires reserving storage for a procedure’s free variables even
while the procedure is not executing. In the Scheme implementation we will study in
Section 4.1, these variables are stored in the procedure’s environment.
103
Exercise 1.43: If f is a numerical function and n is a posi
tive integer, then we can form the nth repeated application
of f , which is deﬁned to be the function whose value at
x is f (f (: : : (f (x)) : : : )). For example, if f is the function
x 7! x + 1, then the nth repeated application of f is the
function x 7! x +n. If f is the operation of squaring a num
ber, then the nth repeated application of f is the function
that raises its argument to the 2nth power. Write a proce
dure that takes as inputs a procedure that computes f and a
positive integer n and returns the procedure that computes
the nth repeated application of f . Your procedure should be
able to be used as follows:
((repeated square 2) 5)
625
Hint: You may ﬁnd it convenient to use compose from Ex
ercise 1.42.
Exercise 1.44: e idea of smoothing a function is an im
portant concept in signal processing. If f is a function and
dx is some small number, then the smoothed version of f is
the function whose value at a point x is the average of f (x(cid:0)
dx), f (x), and f (x +dx). Write a procedure smooth that takes
as input a procedure that computes f and returns a proce
dure that computes the smoothed f . It is sometimes valu
able to repeatedly smooth a function (that is, smooth the
smoothed function, and so on) to obtain the nfold smoothed
function. Show how to generate the nfold smoothed func
tion of any given function using smooth and repeated from
Exercise 1.43.
104
Exercise 1.45: We saw in Section 1.3.3 that aempting to
compute square roots by naively ﬁnding a ﬁxed point of
y 7! x=y does not converge, and that this can be ﬁxed by
average damping. e same method works for ﬁnding cube
roots as ﬁxed points of the averagedamped y 7! x=y2. Un
fortunately, the process does not work for fourth roots—a
single average damp is not enough to make a ﬁxedpoint
search for y 7! x=y3 converge. On the other hand, if we
average damp twice (i.e., use the average damp of the av
erage damp of y 7! x=y3) the ﬁxedpoint search does con
verge. Do some experiments to determine how many av
erage damps are required to compute nth roots as a ﬁxed
point search based upon repeated average damping of y 7!
x=yn(cid:0)1. Use this to implement a simple procedure for com
puting nth roots using fixedpoint, averagedamp, and the
repeated procedure of Exercise 1.43. Assume that any arith
metic operations you need are available as primitives.
Exercise 1.46: Several of the numerical methods described
in this chapter are instances of an extremely general com
putational strategy known as iterative improvement. Itera
tive improvement says that, to compute something, we start
with an initial guess for the answer, test if the guess is good
enough, and otherwise improve the guess and continue the
process using the improved guess as the new guess. Write
a procedure iterativeimprove that takes two procedures
as arguments: a method for telling whether a guess is good
enough and a method for improving a guess. iterative
improve should return as its value a procedure that takes a
guess as argument and keeps improving the guess until it is
105
good enough. Rewrite the sqrt procedure of Section 1.1.7
and the fixedpoint procedure of Section 1.3.3 in terms of
iterativeimprove.
106
Building Abstractions with Data
We now come to the decisive step of mathematical abstrac
tion: we forget about what the symbols stand for. : : :[e
mathematician] need not be idle; there are many operations
which he may carry out with these symbols, without ever
having to look at the things they stand for.
—Hermann Weyl, e Mathematical Way of inking
W Chapter 1 on computational processes and
on the role of procedures in program design. We saw how to
use primitive data (numbers) and primitive operations (arithmetic op
erations), how to combine procedures to form compound procedures
through composition, conditionals, and the use of parameters, and how
to abstract procedures by using define. We saw that a procedure can
be regarded as a paern for the local evolution of a process, and we
classiﬁed, reasoned about, and performed simple algorithmic analyses
of some common paerns for processes as embodied in procedures. We
107
also saw that higherorder procedures enhance the power of our lan
guage by enabling us to manipulate, and thereby to reason in terms of,
general methods of computation. is is much of the essence of pro
gramming.
In this chapter we are going to look at more complex data. All the
procedures in chapter 1 operate on simple numerical data, and simple
data are not suﬃcient for many of the problems we wish to address
using computation. Programs are typically designed to model complex
phenomena, and more oen than not one must construct computational
objects that have several parts in order to model realworld phenom
ena that have several aspects. us, whereas our focus in chapter 1 was
on building abstractions by combining procedures to form compound
procedures, we turn in this chapter to another key aspect of any pro
gramming language: the means it provides for building abstractions by
combining data objects to form compound data.
Why do we want compound data in a programming language? For
the same reasons that we want compound procedures: to elevate the
conceptual level at which we can design our programs, to increase the
modularity of our designs, and to enhance the expressive power of our
language. Just as the ability to deﬁne procedures enables us to deal with
processes at a higher conceptual level than that of the primitive oper
ations of the language, the ability to construct compound data objects
enables us to deal with data at a higher conceptual level than that of the
primitive data objects of the language.
Consider the task of designing a system to perform arithmetic with
rational numbers. We could imagine an operation addrat that takes
two rational numbers and produces their sum. In terms of simple data,
a rational number can be thought of as two integers: a numerator and
a denominator. us, we could design a program in which each ratio
nal number would be represented by two integers (a numerator and a
108
denominator) and where addrat would be implemented by two proce
dures (one producing the numerator of the sum and one producing the
denominator). But this would be awkward, because we would then need
to explicitly keep track of which numerators corresponded to which de
nominators. In a system intended to perform many operations on many
rational numbers, such bookkeeping details would cluer the programs
substantially, to say nothing of what they would do to our minds. It
would be much beer if we could “glue together” a numerator and de
nominator to form a pair—a compound data object—that our programs
could manipulate in a way that would be consistent with regarding a
rational number as a single conceptual unit.
e use of compound data also enables us to increase the modular
ity of our programs. If we can manipulate rational numbers directly as
objects in their own right, then we can separate the part of our program
that deals with rational numbers per se from the details of how rational
numbers may be represented as pairs of integers. e general technique
of isolating the parts of a program that deal with how data objects are
represented from the parts of a program that deal with how data objects
are used is a powerful design methodology called data abstraction. We
will see how data abstraction makes programs much easier to design,
maintain, and modify.
e use of compound data leads to a real increase in the expressive
power of our programming language. Consider the idea of forming a
“linear combination” ax + by. We might like to write a procedure that
would accept a, b, x, and y as arguments and return the value of ax +by.
is presents no diﬃculty if the arguments are to be numbers, because
we can readily deﬁne the procedure
(define (linearcombination a b x y)
(+ (* a x) (* b y)))
109
But suppose we are not concerned only with numbers. Suppose we
would like to express, in procedural terms, the idea that one can form
linear combinations whenever addition and multiplication are deﬁned—
for rational numbers, complex numbers, polynomials, or whatever. We
could express this as a procedure of the form
(define (linearcombination a b x y)
(add (mul a x) (mul b y)))
where add and mul are not the primitive procedures + and * but rather
more complex things that will perform the appropriate operations for
whatever kinds of data we pass in as the arguments a, b, x, and y. e
key point is that the only thing linearcombination should need to
know about a, b, x, and y is that the procedures add and mul will per
form the appropriate manipulations. From the perspective of the pro
cedure linearcombination, it is irrelevant what a, b, x, and y are and
even more irrelevant how they might happen to be represented in terms
of more primitive data. is same example shows why it is important
that our programming language provide the ability to manipulate com
pound objects directly: Without this, there is no way for a procedure
such as linearcombination to pass its arguments along to add and
mul without having to know their detailed structure.1
1e ability to directly manipulate procedures provides an analogous increase in the
expressive power of a programming language. For example, in Section 1.3.1 we intro
duced the sum procedure, which takes a procedure term as an argument and computes
the sum of the values of term over some speciﬁed interval. In order to deﬁne sum, it
is crucial that we be able to speak of a procedure such as term as an entity in its own
right, without regard for how term might be expressed with more primitive operations.
Indeed, if we did not have the notion of “a procedure,” it is doubtful that we would ever
even think of the possibility of deﬁning an operation such as sum. Moreover, insofar as
performing the summation is concerned, the details of how term may be constructed
from more primitive operations are irrelevant.
110
We begin this chapter by implementing the rationalnumber arith
metic system mentioned above. is will form the background for our
discussion of compound data and data abstraction. As with compound
procedures, the main issue to be addressed is that of abstraction as a
technique for coping with complexity, and we will see how data ab
straction enables us to erect suitable abstraction barriers between diﬀer
ent parts of a program.
We will see that the key to forming compound data is that a pro
gramming language should provide some kind of “glue” so that data
objects can be combined to form more complex data objects. ere are
many possible kinds of glue. Indeed, we will discover how to form com
pound data using no special “data” operations at all, only procedures.
is will further blur the distinction between “procedure” and “data,”
which was already becoming tenuous toward the end of chapter 1. We
will also explore some conventional techniques for representing sequences
and trees. One key idea in dealing with compound data is the notion of
closure—that the glue we use for combining data objects should allow
us to combine not only primitive data objects, but compound data ob
jects as well. Another key idea is that compound data objects can serve
as conventional interfaces for combining program modules in mixand
match ways. We illustrate some of these ideas by presenting a simple
graphics language that exploits closure.
We will then augment the representational power of our language
by introducing symbolic expressions—data whose elementary parts can
be arbitrary symbols rather than only numbers. We explore various al
ternatives for representing sets of objects. We will ﬁnd that, just as a
given numerical function can be computed by many diﬀerent computa
tional processes, there are many ways in which a given data structure
can be represented in terms of simpler objects, and the choice of rep
resentation can have signiﬁcant impact on the time and space require
111
ments of processes that manipulate the data. We will investigate these
ideas in the context of symbolic diﬀerentiation, the representation of
sets, and the encoding of information.
Next we will take up the problem of working with data that may be
represented diﬀerently by diﬀerent parts of a program. is leads to the
need to implement generic operations, which must handle many diﬀerent
types of data. Maintaining modularity in the presence of generic oper
ations requires more powerful abstraction barriers than can be erected
with simple data abstraction alone. In particular, we introduce data
directed programming as a technique that allows individual data repre
sentations to be designed in isolation and then combined additively (i.e.,
without modiﬁcation). To illustrate the power of this approach to sys
tem design, we close the chapter by applying what we have learned to
the implementation of a package for performing symbolic arithmetic on
polynomials, in which the coeﬃcients of the polynomials can be inte
gers, rational numbers, complex numbers, and even other polynomials.
2.1 Introduction to Data Abstraction
In Section 1.1.8, we noted that a procedure used as an element in creat
ing a more complex procedure could be regarded not only as a collection
of particular operations but also as a procedural abstraction. at is, the
details of how the procedure was implemented could be suppressed,
and the particular procedure itself could be replaced by any other pro
cedure with the same overall behavior. In other words, we could make
an abstraction that would separate the way the procedure would be used
from the details of how the procedure would be implemented in terms
of more primitive procedures. e analogous notion for compound data
is called data abstraction. Data abstraction is a methodology that enables
112
us to isolate how a compound data object is used from the details of how
it is constructed from more primitive data objects.
e basic idea of data abstraction is to structure the programs that
are to use compound data objects so that they operate on “abstract data.”
at is, our programs should use data in such a way as to make no as
sumptions about the data that are not strictly necessary for performing
the task at hand. At the same time, a “concrete” data representation is
deﬁned independent of the programs that use the data. e interface be
tween these two parts of our system will be a set of procedures, called se
lectors and constructors, that implement the abstract data in terms of the
concrete representation. To illustrate this technique, we will consider
how to design a set of procedures for manipulating rational numbers.
2.1.1 Example: Arithmetic Operations
for Rational Numbers
Suppose we want to do arithmetic with rational numbers. We want to
be able to add, subtract, multiply, and divide them and to test whether
two rational numbers are equal.
Let us begin by assuming that we already have a way of construct
ing a rational number from a numerator and a denominator. We also
assume that, given a rational number, we have a way of extracting (or
selecting) its numerator and its denominator. Let us further assume that
the constructor and selectors are available as procedures:
• (makerat ⟨n⟩ ⟨d⟩) returns the rational number whose numera
tor is the integer ⟨n⟩ and whose denominator is the integer ⟨d⟩.
• (numer ⟨x⟩) returns the numerator of the rational number ⟨x⟩.
• (denom ⟨x⟩) returns the denominator of the rational number ⟨x⟩.
113
We are using here a powerful strategy of synthesis: wishful thinking.
We haven’t yet said how a rational number is represented, or how the
procedures numer, denom, and makerat should be implemented. Even
so, if we did have these three procedures, we could then add, subtract,
multiply, divide, and test equality by using the following relations:
n2
n1
+
d2
d1
(cid:0) n2
n1
d1
d2
(cid:1) n2
n1
d1
d2
n1=d1
n2=d2
n1
d1
;
;
d1d2
d1d2
;
= n1d2 + n2d1
= n1d2 (cid:0) n2d1
= n1n2
d1d2
= n1d2
d1n2
= n2
d2
;
if and only if n1d2 = n2d1:
We can express these rules as procedures:
(define (addrat x y)
(makerat (+ (* (numer x) (denom y))
(* (numer y) (denom x)))
(* (denom x) (denom y))))
(define (subrat x y)
(makerat ( (* (numer x) (denom y))
(* (numer y) (denom x)))
(* (denom x) (denom y))))
(define (mulrat x y)
(makerat (* (numer x) (numer y))
(* (denom x) (denom y))))
(define (divrat x y)
(makerat (* (numer x) (denom y))
(* (denom x) (numer y))))
114
(define (equalrat? x y)
(= (* (numer x) (denom y))
(* (numer y) (denom x))))
Now we have the operations on rational numbers deﬁned in terms
of the selector and constructor procedures numer, denom, and makerat.
But we haven’t yet deﬁned these. What we need is some way to glue
together a numerator and a denominator to form a rational number.
Pairs
To enable us to implement the concrete level of our data abstraction,
our language provides a compound structure called a pair, which can
be constructed with the primitive procedure cons. is procedure takes
two arguments and returns a compound data object that contains the
two arguments as parts. Given a pair, we can extract the parts using the
primitive procedures car and cdr.2 us, we can use cons, car, and cdr
as follows:
(define x (cons 1 2))
(car x)
1
(cdr x)
2
Notice that a pair is a data object that can be given a name and manip
ulated, just like a primitive data object. Moreover, cons can be used to
form pairs whose elements are pairs, and so on:
2e name cons stands for “construct.” e names car and cdr derive from the orig
inal implementation of Lisp on the . at machine had an addressing scheme
that allowed one to reference the “address” and “decrement” parts of a memory location.
car stands for “Contents of Address part of Register” and cdr (pronounced “coulder”)
stands for “Contents of Decrement part of Register.”
115
(define x (cons 1 2))
(define y (cons 3 4))
(define z (cons x y))
(car (car z))
1
(car (cdr z))
3
In Section 2.2 we will see how this ability to combine pairs means that
pairs can be used as generalpurpose building blocks to create all sorts
of complex data structures. e single compounddata primitive pair,
implemented by the procedures cons, car, and cdr, is the only glue we
need. Data objects constructed from pairs are called liststructured data.
Representing rational numbers
Pairs oﬀer a natural way to complete the rationalnumber system. Sim
ply represent a rational number as a pair of two integers: a numerator
and a denominator. en makerat, numer, and denom are readily im
plemented as follows:3
3Another way to deﬁne the selectors and constructor is
(define makerat cons)
(define numer car)
(define denom cdr)
e ﬁrst deﬁnition associates the name makerat with the value of the expression
cons, which is the primitive procedure that constructs pairs. us makerat and cons
are names for the same primitive constructor.
Deﬁning selectors and constructors in this way is eﬃcient: Instead of makerat call
ing cons, makerat is cons, so there is only one procedure called, not two, when make
rat is called. On the other hand, doing this defeats debugging aids that trace procedure
calls or put breakpoints on procedure calls: You may want to watch makerat being
called, but you certainly don’t want to watch every call to cons.
We have chosen not to use this style of deﬁnition in this book.
116
(define (makerat n d) (cons n d))
(define (numer x) (car x))
(define (denom x) (cdr x))
Also, in order to display the results of our computations, we can print
rational numbers by printing the numerator, a slash, and the denomi
nator:4
(define (printrat x)
(newline)
(display (numer x))
(display "/")
(display (denom x)))
Now we can try our rationalnumber procedures:
(define onehalf (makerat 1 2))
(printrat onehalf)
1/2
(define onethird (makerat 1 3))
(printrat (addrat onehalf onethird))
5/6
(printrat (mulrat onehalf onethird))
1/6
(printrat (addrat onethird onethird))
6/9
As the ﬁnal example shows, our rationalnumber implementation does
not reduce rational numbers to lowest terms. We can remedy this by
changing makerat. If we have a gcd procedure like the one in Section
1.2.5 that produces the greatest common divisor of two integers, we can
4display is the Scheme primitive for printing data. e Scheme primitive newline
starts a new line for printing. Neither of these procedures returns a useful value, so
in the uses of printrat below, we show only what printrat prints, not what the
interpreter prints as the value returned by printrat.
117
use gcd to reduce the numerator and the denominator to lowest terms
before constructing the pair:
(define (makerat n d)
(let ((g (gcd n d)))
(cons (/ n g) (/ d g))))
Now we have
(printrat (addrat onethird onethird))
2/3
as desired. is modiﬁcation was accomplished by changing the con
structor makerat without changing any of the procedures (such as
addrat and mulrat) that implement the actual operations.
Exercise 2.1: Deﬁne a beer version of makerat that han
dles both positive and negative arguments. makerat should
normalize the sign so that if the rational number is positive,
both the numerator and denominator are positive, and if
the rational number is negative, only the numerator is neg
ative.
2.1.2 Abstraction Barriers
Before continuing with more examples of compound data and data ab
straction, let us consider some of the issues raised by the rationalnumber
example. We deﬁned the rationalnumber operations in terms of a con
structor makerat and selectors numer and denom. In general, the under
lying idea of data abstraction is to identify for each type of data object
a basic set of operations in terms of which all manipulations of data
objects of that type will be expressed, and then to use only those oper
ations in manipulating the data.
118
Figure 2.1: Dataabstraction barriers in the rational
number package.
We can envision the structure of the rationalnumber system as
shown in Figure 2.1. e horizontal lines represent abstraction barriers
that isolate diﬀerent “levels” of the system. At each level, the barrier
separates the programs (above) that use the data abstraction from the
programs (below) that implement the data abstraction. Programs that
use rational numbers manipulate them solely in terms of the proce
dures supplied “for public use” by the rationalnumber package: add
rat, subrat, mulrat, divrat, and equalrat?. ese, in turn, are
implemented solely in terms of the constructor and selectors makerat,
numer, and denom, which themselves are implemented in terms of pairs.
e details of how pairs are implemented are irrelevant to the rest of
the rationalnumber package so long as pairs can be manipulated by
the use of cons, car, and cdr. In eﬀect, procedures at each level are the
119
Programs that use rational numbersRational numbers in problem domainaddrat subrat ...Rational numbers as numerators and denominatorsmakerat numer denomRational numbers as pairscons car cdrHowever pairs are implementedinterfaces that deﬁne the abstraction barriers and connect the diﬀerent
levels.
is simple idea has many advantages. One advantage is that it
makes programs much easier to maintain and to modify. Any complex
data structure can be represented in a variety of ways with the prim
itive data structures provided by a programming language. Of course,
the choice of representation inﬂuences the programs that operate on it;
thus, if the representation were to be changed at some later time, all
such programs might have to be modiﬁed accordingly. is task could
be timeconsuming and expensive in the case of large programs unless
the dependence on the representation were to be conﬁned by design to
a very few program modules.
For example, an alternate way to address the problem of reducing
rational numbers to lowest terms is to perform the reduction whenever
we access the parts of a rational number, rather than when we construct
it. is leads to diﬀerent constructor and selector procedures:
(define (makerat n d) (cons n d))
(define (numer x)
(let ((g (gcd (car x) (cdr x))))
(/ (car x) g)))
(define (denom x)
(let ((g (gcd (car x) (cdr x))))
(/ (cdr x) g)))
e diﬀerence between this implementation and the previous one lies
in when we compute the gcd. If in our typical use of rational numbers
we access the numerators and denominators of the same rational num
bers many times, it would be preferable to compute the gcd when the
rational numbers are constructed. If not, we may be beer oﬀ waiting
until access time to compute the gcd. In any case, when we change from
120
one representation to the other, the procedures addrat, subrat, and
so on do not have to be modiﬁed at all.
Constraining the dependence on the representation to a few in
terface procedures helps us design programs as well as modify them,
because it allows us to maintain the ﬂexibility to consider alternate
implementations. To continue with our simple example, suppose we
are designing a rationalnumber package and we can’t decide initially
whether to perform the gcd at construction time or at selection time.
e dataabstraction methodology gives us a way to defer that decision
without losing the ability to make progress on the rest of the system.
Exercise 2.2: Consider the problem of representing line
segments in a plane. Each segment is represented as a pair
of points: a starting point and an ending point. Deﬁne a
constructor makesegment and selectors startsegment and
endsegment that deﬁne the representation of segments in
terms of points. Furthermore, a point can be represented
as a pair of numbers: the x coordinate and the y coordi
nate. Accordingly, specify a constructor makepoint and
selectors xpoint and ypoint that deﬁne this representa
tion. Finally, using your selectors and constructors, deﬁne a
procedure midpointsegment that takes a line segment as
argument and returns its midpoint (the point whose coor
dinates are the average of the coordinates of the endpoints).
To try your procedures, you’ll need a way to print points:
(define (printpoint p)
(newline)
(display "(")
(display (xpoint p))
(display ",")
121
(display (ypoint p))
(display ")"))
Exercise 2.3: Implement a representation for rectangles in
a plane. (Hint: You may want to make use of Exercise 2.2.) In
terms of your constructors and selectors, create procedures
that compute the perimeter and the area of a given rectan
gle. Now implement a diﬀerent representation for rectan
gles. Can you design your system with suitable abstraction
barriers, so that the same perimeter and area procedures
will work using either representation?
2.1.3 What Is Meant by Data?
We began the rationalnumber implementation in Section 2.1.1 by im
plementing the rationalnumber operations addrat, subrat, and so
on in terms of three unspeciﬁed procedures: makerat, numer, and denom.
At that point, we could think of the operations as being deﬁned in terms
of data objects—numerators, denominators, and rational numbers—whose
behavior was speciﬁed by the laer three procedures.
But exactly what is meant by data? It is not enough to say “whatever
is implemented by the given selectors and constructors.” Clearly, not
every arbitrary set of three procedures can serve as an appropriate basis
for the rationalnumber implementation. We need to guarantee that, if
we construct a rational number x from a pair of integers n and d, then
extracting the numer and the denom of x and dividing them should yield
the same result as dividing n by d. In other words, makerat, numer,
and denom must satisfy the condition that, for any integer n and any
122
nonzero integer d, if x is (makerat n d), then
(numer x)
(denom x)
=
n
d
:
In fact, this is the only condition makerat, numer, and denom must fulﬁll
in order to form a suitable basis for a rationalnumber representation.
In general, we can think of data as deﬁned by some collection of se
lectors and constructors, together with speciﬁed conditions that these
procedures must fulﬁll in order to be a valid representation.5
is point of view can serve to deﬁne not only “highlevel” data ob
jects, such as rational numbers, but lowerlevel objects as well. Consider
the notion of a pair, which we used in order to deﬁne our rational num
bers. We never actually said what a pair was, only that the language
supplied procedures cons, car, and cdr for operating on pairs. But the
only thing we need to know about these three operations is that if we
glue two objects together using cons we can retrieve the objects using
car and cdr. at is, the operations satisfy the condition that, for any
objects x and y, if z is (cons x y) then (car z) is x and (cdr z) is y.
5Surprisingly, this idea is very diﬃcult to formulate rigorously. ere are two ap
proaches to giving such a formulation. One, pioneered by C. A. R. Hoare (1972), is
known as the method of abstract models. It formalizes the “procedures plus conditions”
speciﬁcation as outlined in the rationalnumber example above. Note that the condi
tion on the rationalnumber representation was stated in terms of facts about integers
(equality and division). In general, abstract models deﬁne new kinds of data objects
in terms of previously deﬁned types of data objects. Assertions about data objects can
therefore be checked by reducing them to assertions about previously deﬁned data ob
jects. Another approach, introduced by Zilles at , by Goguen, atcher, Wagner, and
Wright at (see atcher et al. 1978), and by Guag at Toronto (see Guag 1977), is
called algebraic speciﬁcation. It regards the “procedures” as elements of an abstract alge
braic system whose behavior is speciﬁed by axioms that correspond to our “conditions,”
and uses the techniques of abstract algebra to check assertions about data objects. Both
methods are surveyed in the paper by Liskov and Zilles (1975).
123
Indeed, we mentioned that these three procedures are included as prim
itives in our language. However, any triple of procedures that satisﬁes
the above condition can be used as the basis for implementing pairs.
is point is illustrated strikingly by the fact that we could implement
cons, car, and cdr without using any data structures at all but only
using procedures. Here are the deﬁnitions:
(define (cons x y)
(define (dispatch m)
(cond ((= m 0) x)
((= m 1) y)
(else (error "Argument not 0 or 1: CONS" m))))
dispatch)
(define (car z) (z 0))
(define (cdr z) (z 1))
is use of procedures corresponds to nothing like our intuitive notion
of what data should be. Nevertheless, all we need to do to show that
this is a valid way to represent pairs is to verify that these procedures
satisfy the condition given above.
e subtle point to notice is that the value returned by (cons x y) is
a procedure—namely the internally deﬁned procedure dispatch, which
takes one argument and returns either x or y depending on whether the
argument is 0 or 1. Correspondingly, (car z) is deﬁned to apply z to 0.
Hence, if z is the procedure formed by (cons x y), then z applied to 0
will yield x. us, we have shown that (car (cons x y)) yields x, as
desired. Similarly, (cdr (cons x y)) applies the procedure returned by
(cons x y) to 1, which returns y. erefore, this procedural implemen
tation of pairs is a valid implementation, and if we access pairs using
only cons, car, and cdr we cannot distinguish this implementation from
one that uses “real” data structures.
e point of exhibiting the procedural representation of pairs is not
124
that our language works this way (Scheme, and Lisp systems in general,
implement pairs directly, for eﬃciency reasons) but that it could work
this way. e procedural representation, although obscure, is a perfectly
adequate way to represent pairs, since it fulﬁlls the only conditions that
pairs need to fulﬁll. is example also demonstrates that the ability to
manipulate procedures as objects automatically provides the ability to
represent compound data. is may seem a curiosity now, but procedu
ral representations of data will play a central role in our programming
repertoire. is style of programming is oen called message passing,
and we will be using it as a basic tool in Chapter 3 when we address the
issues of modeling and simulation.
Exercise 2.4: Here is an alternative procedural representa
tion of pairs. For this representation, verify that (car (cons
x y)) yields x for any objects x and y.
(define (cons x y)
(lambda (m) (m x y)))
(define (car z)
(z (lambda (p q) p)))
What is the corresponding deﬁnition of cdr? (Hint: To ver
ify that this works, make use of the substitution model of
Section 1.1.5.)
Exercise 2.5: Show that we can represent pairs of nonneg
ative integers using only numbers and arithmetic opera
tions if we represent the pair a and b as the integer that is
the product 2a3b. Give the corresponding deﬁnitions of the
procedures cons, car, and cdr.
125
Exercise 2.6: In case representing pairs as procedures wasn’t
mindboggling enough, consider that, in a language that
can manipulate procedures, we can get by without numbers
(at least insofar as nonnegative integers are concerned) by
implementing 0 and the operation of adding 1 as
(define zero (lambda (f) (lambda (x) x)))
(define (add1 n)
(lambda (f) (lambda (x) (f ((n f) x)))))
is representation is known as Church numerals, aer its
inventor, Alonzo Church, the logician who invented the λ
calculus.
Deﬁne one and two directly (not in terms of zero and add
1). (Hint: Use substitution to evaluate (add1 zero)). Give
a direct deﬁnition of the addition procedure + (not in terms
of repeated application of add1).
2.1.4 Extended Exercise: Interval Arithmetic
Alyssa P. Hacker is designing a system to help people solve engineer
ing problems. One feature she wants to provide in her system is the
ability to manipulate inexact quantities (such as measured parameters
of physical devices) with known precision, so that when computations
are done with such approximate quantities the results will be numbers
of known precision.
Electrical engineers will be using Alyssa’s system to compute elec
trical quantities. It is sometimes necessary for them to compute the
value of a parallel equivalent resistance Rp of two resistors R1, R2 using
the formula
Rp =
1
:
1=R1 + 1=R2
126
Resistance values are usually known only up to some tolerance guaran
teed by the manufacturer of the resistor. For example, if you buy a resis
tor labeled “6.8 ohms with 10% tolerance” you can only be sure that the
resistor has a resistance between 6:8(cid:0) 0:68 = 6:12 and 6:8 + 0:68 = 7:48
ohms. us, if you have a 6.8ohm 10% resistor in parallel with a 4.7ohm
5% resistor, the resistance of the combination can range from about 2.58
ohms (if the two resistors are at the lower bounds) to about 2.97 ohms
(if the two resistors are at the upper bounds).
Alyssa’s idea is to implement “interval arithmetic” as a set of arith
metic operations for combining “intervals” (objects that represent the
range of possible values of an inexact quantity). e result of adding,
subtracting, multiplying, or dividing two intervals is itself an interval,
representing the range of the result.
Alyssa postulates the existence of an abstract object called an “in
terval” that has two endpoints: a lower bound and an upper bound. She
also presumes that, given the endpoints of an interval, she can con
struct the interval using the data constructor makeinterval. Alyssa
ﬁrst writes a procedure for adding two intervals. She reasons that the
minimum value the sum could be is the sum of the two lower bounds
and the maximum value it could be is the sum of the two upper bounds:
(define (addinterval x y)
(makeinterval (+ (lowerbound x) (lowerbound y))
(+ (upperbound x) (upperbound y))))
Alyssa also works out the product of two intervals by ﬁnding the min
imum and the maximum of the products of the bounds and using them
as the bounds of the resulting interval. (min and max are primitives that
ﬁnd the minimum or maximum of any number of arguments.)
(define (mulinterval x y)
(let ((p1 (* (lowerbound x) (lowerbound y)))
127
(p2 (* (lowerbound x) (upperbound y)))
(p3 (* (upperbound x) (lowerbound y)))
(p4 (* (upperbound x) (upperbound y))))
(makeinterval (min p1 p2 p3 p4)
(max p1 p2 p3 p4))))
To divide two intervals, Alyssa multiplies the ﬁrst by the reciprocal of
the second. Note that the bounds of the reciprocal interval are the re
ciprocal of the upper bound and the reciprocal of the lower bound, in
that order.
(define (divinterval x y)
(mulinterval
x
(makeinterval (/ 1.0 (upperbound y))
(/ 1.0 (lowerbound y)))))
Exercise 2.7: Alyssa’s program is incomplete because she
has not speciﬁed the implementation of the interval ab
straction. Here is a deﬁnition of the interval constructor:
(define (makeinterval a b) (cons a b))
Deﬁne selectors upperbound and lowerbound to complete
the implementation.
Exercise 2.8: Using reasoning analogous to Alyssa’s, de
scribe how the diﬀerence of two intervals may be com
puted. Deﬁne a corresponding subtraction procedure, called
subinterval.
Exercise 2.9: e width of an interval is half of the diﬀer
ence between its upper and lower bounds. e width is a
128
measure of the uncertainty of the number speciﬁed by the
interval. For some arithmetic operations the width of the
result of combining two intervals is a function only of the
widths of the argument intervals, whereas for others the
width of the combination is not a function of the widths of
the argument intervals. Show that the width of the sum (or
diﬀerence) of two intervals is a function only of the widths
of the intervals being added (or subtracted). Give examples
to show that this is not true for multiplication or division.
Exercise 2.10: Ben Bitdiddle, an expert systems program
mer, looks over Alyssa’s shoulder and comments that it is
not clear what it means to divide by an interval that spans
zero. Modify Alyssa’s code to check for this condition and
to signal an error if it occurs.
Exercise 2.11: In passing, Ben also cryptically comments:
“By testing the signs of the endpoints of the intervals, it is
possible to break mulinterval into nine cases, only one
of which requires more than two multiplications.” Rewrite
this procedure using Ben’s suggestion.
Aer debugging her program, Alyssa shows it to a poten
tial user, who complains that her program solves the wrong
problem. He wants a program that can deal with numbers
represented as a center value and an additive tolerance; for
example, he wants to work with intervals such as 3:5(cid:6) 0:15
rather than [3.35, 3.65]. Alyssa returns to her desk and ﬁxes
this problem by supplying an alternate constructor and al
ternate selectors:
129
(define (makecenterwidth c w)
(makeinterval ( c w) (+ c w)))
(define (center i)
(/ (+ (lowerbound i) (upperbound i)) 2))
(define (width i)
(/ ( (upperbound i) (lowerbound i)) 2))
Unfortunately, most of Alyssa’s users are engineers. Real
engineering situations usually involve measurements with
only a small uncertainty, measured as the ratio of the width
of the interval to the midpoint of the interval. Engineers
usually specify percentage tolerances on the parameters of
devices, as in the resistor speciﬁcations given earlier.
Exercise 2.12: Deﬁne a constructor makecenterpercent
that takes a center and a percentage tolerance and pro
duces the desired interval. You must also deﬁne a selector
percent that produces the percentage tolerance for a given
interval. e center selector is the same as the one shown
above.
Exercise 2.13: Show that under the assumption of small
percentage tolerances there is a simple formula for the ap
proximate percentage tolerance of the product of two in
tervals in terms of the tolerances of the factors. You may
simplify the problem by assuming that all numbers are pos
itive.
Aer considerable work, Alyssa P. Hacker delivers her ﬁn
ished system. Several years later, aer she has forgoen all
about it, she gets a frenzied call from an irate user, Lem E.
Tweakit. It seems that Lem has noticed that the formula for
130
parallel resistors can be wrien in two algebraically equiv
alent ways:
R1R2
R1 + R2
and
1
1=R1 + 1=R2
:
He has wrien the following two programs, each of which
computes the parallelresistors formula diﬀerently:
(define (par1 r1 r2)
(divinterval (mulinterval r1 r2)
(addinterval r1 r2)))
(define (par2 r1 r2)
(let ((one (makeinterval 1 1)))
(divinterval
one (addinterval (divinterval one r1)
(divinterval one r2)))))
Lem complains that Alyssa’s program gives diﬀerent an
swers for the two ways of computing. is is a serious com
plaint.
Exercise 2.14: Demonstrate that Lem is right. Investigate
the behavior of the system on a variety of arithmetic ex
pressions. Make some intervals A and B, and use them in
computing the expressions A=A and A=B. You will get the
most insight by using intervals whose width is a small per
centage of the center value. Examine the results of the com
putation in centerpercent form (see Exercise 2.12).
131
Exercise 2.15: Eva Lu Ator, another user, has also noticed
the diﬀerent intervals computed by diﬀerent but algebraically
equivalent expressions. She says that a formula to compute
with intervals using Alyssa’s system will produce tighter
error bounds if it can be wrien in such a form that no vari
able that represents an uncertain number is repeated. us,
she says, par2 is a “beer” program for parallel resistances
than par1. Is she right? Why?
Exercise 2.16: Explain, in general, why equivalent alge
braic expressions may lead to diﬀerent answers. Can you
devise an intervalarithmetic package that does not have
this shortcoming, or is this task impossible? (Warning: is
problem is very diﬃcult.)
2.2 Hierarchical Data and the Closure Property
As we have seen, pairs provide a primitive “glue” that we can use to
construct compound data objects. Figure 2.2 shows a standard way to
visualize a pair—in this case, the pair formed by (cons 1 2). In this
representation, which is called boxandpointer notation, each object is
shown as a pointer to a box. e box for a primitive object contains a
representation of the object. For example, the box for a number contains
a numeral. e box for a pair is actually a double box, the le part con
taining (a pointer to) the car of the pair and the right part containing
the cdr.
We have already seen that cons can be used to combine not only
numbers but pairs as well. (You made use of this fact, or should have,
in doing Exercise 2.2 and Exercise 2.3.) As a consequence, pairs pro
vide a universal building block from which we can construct all sorts of
132
Figure 2.2: Boxandpointer representation of (cons 1 2).
Figure 2.3: Two ways to combine 1, 2, 3, and 4 using pairs.
data structures. Figure 2.3 shows two ways to use pairs to combine the
numbers 1, 2, 3, and 4.
e ability to create pairs whose elements are pairs is the essence
of list structure’s importance as a representational tool. We refer to this
ability as the closure property of cons. In general, an operation for com
bining data objects satisﬁes the closure property if the results of com
bining things with that operation can themselves be combined using the
same operation.6 Closure is the key to power in any means of combina
6e use of the word “closure” here comes from abstract algebra, where a set of
133
2114233412(cons (cons 1 2) (cons (cons 1 (cons 3 4)) (cons 2 3)) 4)tion because it permits us to create hierarchical structures—structures
made up of parts, which themselves are made up of parts, and so on.
From the outset of Chapter 1, we’ve made essential use of closure
in dealing with procedures, because all but the very simplest programs
rely on the fact that the elements of a combination can themselves be
combinations. In this section, we take up the consequences of closure
for compound data. We describe some conventional techniques for us
ing pairs to represent sequences and trees, and we exhibit a graphics
language that illustrates closure in a vivid way.7
2.2.1 Representing Sequences
One of the useful structures we can build with pairs is a sequence—an
ordered collection of data objects. ere are, of course, many ways to
elements is said to be closed under an operation if applying the operation to elements
in the set produces an element that is again an element of the set. e Lisp community
also (unfortunately) uses the word “closure” to describe a totally unrelated concept: A
closure is an implementation technique for representing procedures with free variables.
We do not use the word “closure” in this second sense in this book.
7e notion that a means of combination should satisfy closure is a straightfor
ward idea. Unfortunately, the data combiners provided in many popular programming
languages do not satisfy closure, or make closure cumbersome to exploit. In Fortran
or Basic, one typically combines data elements by assembling them into arrays—but
one cannot form arrays whose elements are themselves arrays. Pascal and C admit
structures whose elements are structures. However, this requires that the program
mer manipulate pointers explicitly, and adhere to the restriction that each ﬁeld of a
structure can contain only elements of a prespeciﬁed form. Unlike Lisp with its pairs,
these languages have no builtin generalpurpose glue that makes it easy to manipulate
compound data in a uniform way. is limitation lies behind Alan Perlis’s comment in
his foreword to this book: “In Pascal the plethora of declarable data structures induces
a specialization within functions that inhibits and penalizes casual cooperation. It is
beer to have 100 functions operate on one data structure than to have 10 functions
operate on 10 data structures.”
134
Figure 2.4: e sequence 1, 2, 3, 4 represented as a chain
of pairs.
represent sequences in terms of pairs. One particularly straightforward
representation is illustrated in Figure 2.4, where the sequence 1, 2, 3, 4 is
represented as a chain of pairs. e car of each pair is the corresponding
item in the chain, and the cdr of the pair is the next pair in the chain.
e cdr of the ﬁnal pair signals the end of the sequence by pointing to
a distinguished value that is not a pair, represented in boxandpointer
diagrams as a diagonal line and in programs as the value of the variable
nil. e entire sequence is constructed by nested cons operations:
(cons 1
(cons 2
(cons 3
(cons 4 nil))))
Such a sequence of pairs, formed by nested conses, is called a list,
and Scheme provides a primitive called list to help in constructing
lists.8 e above sequence could be produced by (list 1 2 3 4). In
general,
(list ⟨a1⟩ ⟨a2⟩ : : : ⟨an⟩)
8In this book, we use list to mean a chain of pairs terminated by the endoflist
marker. In contrast, the term list structure refers to any data structure made out of pairs,
not just to lists.
135
1423is equivalent to
(cons ⟨a1⟩
(cons ⟨a2⟩
(cons : : :
(cons ⟨an⟩
nil): : :)))
Lisp systems conventionally print lists by printing the sequence of el
ements, enclosed in parentheses. us, the data object in Figure 2.4 is
printed as (1 2 3 4):
(define onethroughfour (list 1 2 3 4))
onethroughfour
(1 2 3 4)
Be careful not to confuse the expression (list 1 2 3 4) with the list
(1 2 3 4), which is the result obtained when the expression is evalu
ated. Aempting to evaluate the expression (1 2 3 4) will signal an
error when the interpreter tries to apply the procedure 1 to arguments
2, 3, and 4.
We can think of car as selecting the ﬁrst item in the list, and of
cdr as selecting the sublist consisting of all but the ﬁrst item. Nested
applications of car and cdr can be used to extract the second, third,
and subsequent items in the list.9 e constructor cons makes a list like
the original one, but with an additional item at the beginning.
9Since nested applications of car and cdr are cumbersome to write, Lisp dialects
provide abbreviations for them—for instance,
(cadr ⟨arg⟩) = (car (cdr ⟨arg⟩))
e names of all such procedures start with c and end with r. Each a between them
stands for a car operation and each d for a cdr operation, to be applied in the same
order in which they appear in the name. e names car and cdr persist because simple
combinations like cadr are pronounceable.
136
(car onethroughfour)
1
(cdr onethroughfour)
(2 3 4)
(car (cdr onethroughfour))
2
(cons 10 onethroughfour)
(10 1 2 3 4)
(cons 5 onethroughfour)
(5 1 2 3 4)
e value of nil, used to terminate the chain of pairs, can be thought of
as a sequence of no elements, the empty list. e word nil is a contraction
of the Latin word nihil, which means “nothing.”10
List operations
e use of pairs to represent sequences of elements as lists is accompa
nied by conventional programming techniques for manipulating lists by
successively “cdring down” the lists. For example, the procedure list
ref takes as arguments a list and a number n and returns the nth item
of the list. It is customary to number the elements of the list beginning
with 0. e method for computing listref is the following:
10It’s remarkable how much energy in the standardization of Lisp dialects has been
dissipated in arguments that are literally over nothing: Should nil be an ordinary
name? Should the value of nil be a symbol? Should it be a list? Should it be a pair?
In Scheme, nil is an ordinary name, which we use in this section as a variable whose
value is the endoflist marker (just as true is an ordinary variable that has a true value).
Other dialects of Lisp, including Common Lisp, treat nil as a special symbol. e au
thors of this book, who have endured too many language standardization brawls, would
like to avoid the entire issue. Once we have introduced quotation in Section 2.3, we will
denote the empty list as '() and dispense with the variable nil entirely.
137
• For n = 0, listref should return the car of the list.
• Otherwise, listref should return the (n (cid:0) 1)st item of the cdr
of the list.
(define (listref items n)
(if (= n 0)
(car items)
(listref (cdr items) ( n 1))))
(define squares (list 1 4 9 16 25))
(listref squares 3)
16
Oen we cdr down the whole list. To aid in this, Scheme includes a
primitive predicate null?, which tests whether its argument is the empty
list. e procedure length, which returns the number of items in a list,
illustrates this typical paern of use:
(define (length items)
(if (null? items)
0
(+ 1 (length (cdr items)))))
(define odds (list 1 3 5 7))
(length odds)
4
e length procedure implements a simple recursive plan. e reduc
tion step is:
• e length of any list is 1 plus the length of the cdr of the list.
is is applied successively until we reach the base case:
• e length of the empty list is 0.
138
We could also compute length in an iterative style:
(define (length items)
(define (lengthiter a count)
(if (null? a)
count
(lengthiter (cdr a) (+ 1 count))))
(lengthiter items 0))
Another conventional programming technique is to “cons up” an an
swer list while cdring down a list, as in the procedure append, which
takes two lists as arguments and combines their elements to make a new
list:
(append squares odds)
(1 4 9 16 25 1 3 5 7)
(append odds squares)
(1 3 5 7 1 4 9 16 25)
append is also implemented using a recursive plan. To append lists list1
and list2, do the following:
• If list1 is the empty list, then the result is just list2.
• Otherwise, append the cdr of list1 and list2, and cons the car
of list1 onto the result:
(define (append list1 list2)
(if (null? list1)
list2
(cons (car list1) (append (cdr list1) list2))))
Exercise 2.17: Deﬁne a procedure lastpair that returns
the list that contains only the last element of a given (nonempty)
list:
139
(lastpair (list 23 72 149 34))
(34)
Exercise 2.18: Deﬁne a procedure reverse that takes a list
as argument and returns a list of the same elements in re
verse order:
(reverse (list 1 4 9 16 25))
(25 16 9 4 1)
Exercise 2.19: Consider the changecounting program of
Section 1.2.2. It would be nice to be able to easily change the
currency used by the program, so that we could compute
the number of ways to change a British pound, for example.
As the program is wrien, the knowledge of the currency is
distributed partly into the procedure firstdenomination
and partly into the procedure countchange (which knows
that there are ﬁve kinds of U.S. coins). It would be nicer
to be able to supply a list of coins to be used for making
change.
We want to rewrite the procedure cc so that its second ar
gument is a list of the values of the coins to use rather than
an integer specifying which coins to use. We could then
have lists that deﬁned each kind of currency:
(define uscoins (list 50 25 10 5 1))
(define ukcoins (list 100 50 20 10 5 2 1 0.5))
We could then call cc as follows:
(cc 100 uscoins)
292
140
To do this will require changing the program cc somewhat.
It will still have the same form, but it will access its second
argument diﬀerently, as follows:
(define (cc amount coinvalues)
(cond ((= amount 0) 1)
((or (< amount 0) (nomore? coinvalues)) 0)
(else
(+ (cc amount
(exceptfirstdenomination
coinvalues))
(cc ( amount
(firstdenomination
coinvalues))
coinvalues)))))
Deﬁne the procedures firstdenomination, exceptfirst
denomination, and nomore? in terms of primitive oper
ations on list structures. Does the order of the list coin
values aﬀect the answer produced by cc? Why or why not?
Exercise 2.20: e procedures +, *, and list take arbitrary
numbers of arguments. One way to deﬁne such procedures
is to use define with doedtail notation. In a procedure
deﬁnition, a parameter list that has a dot before the last pa
rameter name indicates that, when the procedure is called,
the initial parameters (if any) will have as values the initial
arguments, as usual, but the ﬁnal parameter’s value will be
a list of any remaining arguments. For instance, given the
deﬁnition
(define (f x y . z) ⟨body⟩)
141
the procedure f can be called with two or more arguments.
If we evaluate
(f 1 2 3 4 5 6)
then in the body of f, x will be 1, y will be 2, and z will be
the list (3 4 5 6). Given the deﬁnition
(define (g . w) ⟨body⟩)
the procedure g can be called with zero or more arguments.
If we evaluate
(g 1 2 3 4 5 6)
then in the body of g, w will be the list (1 2 3 4 5 6).11
Use this notation to write a procedure sameparity that
takes one or more integers and returns a list of all the ar
guments that have the same evenodd parity as the ﬁrst
argument. For example,
(sameparity 1 2 3 4 5 6 7)
(1 3 5 7)
(sameparity 2 3 4 5 6 7)
(2 4 6)
11To deﬁne f and g using lambda we would write
(define f (lambda (x y . z) ⟨body⟩))
(define g (lambda w ⟨body⟩))
142
Mapping over lists
One extremely useful operation is to apply some transformation to each
element in a list and generate the list of results. For instance, the follow
ing procedure scales each number in a list by a given factor:
(define (scalelist items factor)
(if (null? items)
nil
(cons (* (car items) factor)
(scalelist (cdr items)
factor))))
(scalelist (list 1 2 3 4 5) 10)
(10 20 30 40 50)
We can abstract this general idea and capture it as a common paern
expressed as a higherorder procedure, just as in Section 1.3. e higher
order procedure here is called map. map takes as arguments a procedure
of one argument and a list, and returns a list of the results produced by
applying the procedure to each element in the list:12
(define (map proc items)
(if (null? items)
12 Scheme standardly provides a map procedure that is more general than the one
described here. is more general map takes a procedure of n arguments, together with
n lists, and applies the procedure to all the ﬁrst elements of the lists, all the second
elements of the lists, and so on, returning a list of the results. For example:
(map + (list 1 2 3) (list 40 50 60) (list 700 800 900))
(741 852 963)
(map (lambda (x y) (+ x (* 2 y)))
(list 1 2 3)
(list 4 5 6))
(9 12 15)
143
nil
(cons (proc (car items))
(map proc (cdr items)))))
(map abs (list 10 2.5 11.6 17))
(10 2.5 11.6 17)
(map (lambda (x) (* x x)) (list 1 2 3 4))
(1 4 9 16)
Now we can give a new deﬁnition of scalelist in terms of map:
(define (scalelist items factor)
(map (lambda (x) (* x factor))
items))
map is an important construct, not only because it captures a common
paern, but because it establishes a higher level of abstraction in dealing
with lists. In the original deﬁnition of scalelist, the recursive struc
ture of the program draws aention to the elementbyelement process
ing of the list. Deﬁning scalelist in terms of map suppresses that level
of detail and emphasizes that scaling transforms a list of elements to a
list of results. e diﬀerence between the two deﬁnitions is not that the
computer is performing a diﬀerent process (it isn’t) but that we think
about the process diﬀerently. In eﬀect, map helps establish an abstrac
tion barrier that isolates the implementation of procedures that trans
form lists from the details of how the elements of the list are extracted
and combined. Like the barriers shown in Figure 2.1, this abstraction
gives us the ﬂexibility to change the lowlevel details of how sequences
are implemented, while preserving the conceptual framework of oper
ations that transform sequences to sequences. Section 2.2.3 expands on
this use of sequences as a framework for organizing programs.
Exercise 2.21: e procedure squarelist takes a list of
numbers as argument and returns a list of the squares of
144
those numbers.
(squarelist (list 1 2 3 4))
(1 4 9 16)
Here are two diﬀerent deﬁnitions of squarelist. Com
plete both of them by ﬁlling in the missing expressions:
(define (squarelist items)
(if (null? items)
nil
(cons ⟨??⟩ ⟨??⟩)))
(define (squarelist items)
(map ⟨??⟩ ⟨??⟩))
Exercise 2.22: Louis Reasoner tries to rewrite the ﬁrst square
list procedure of Exercise 2.21 so that it evolves an itera
tive process:
(define (squarelist items)
(define (iter things answer)
(if (null? things)
answer
(iter (cdr things)
(cons (square (car things))
answer))))
(iter items nil))
Unfortunately, deﬁning squarelist this way produces the
answer list in the reverse order of the one desired. Why?
Louis then tries to ﬁx his bug by interchanging the argu
ments to cons:
(define (squarelist items)
145
(define (iter things answer)
(if (null? things)
answer
(iter (cdr things)
(cons answer
(iter items nil))
(square (car things))))))
is doesn’t work either. Explain.
Exercise 2.23: e procedure foreach is similar to map. It
takes as arguments a procedure and a list of elements. How
ever, rather than forming a list of the results, foreach just
applies the procedure to each of the elements in turn, from
le to right. e values returned by applying the procedure
to the elements are not used at all—foreach is used with
procedures that perform an action, such as printing. For ex
ample,
(foreach (lambda (x)
(newline)
(display x))
(list 57 321 88))
57
321
88
e value returned by the call to foreach (not illustrated
above) can be something arbitrary, such as true. Give an
implementation of foreach.
146
Figure 2.5: Structure formed by (cons (list 1 2) (list
3 4)).
2.2.2 Hierarchical Structures
e representation of sequences in terms of lists generalizes naturally
to represent sequences whose elements may themselves be sequences.
For example, we can regard the object ((1 2) 3 4) constructed by
(cons (list 1 2) (list 3 4))
as a list of three items, the ﬁrst of which is itself a list, (1 2). Indeed, this
is suggested by the form in which the result is printed by the interpreter.
Figure 2.5 shows the representation of this structure in terms of pairs.
Another way to think of sequences whose elements are sequences
is as trees. e elements of the sequence are the branches of the tree, and
elements that are themselves sequences are subtrees. Figure 2.6 shows
the structure in Figure 2.5 viewed as a tree.
Recursion is a natural tool for dealing with tree structures, since we
can oen reduce operations on trees to operations on their branches,
which reduce in turn to operations on the branches of the branches, and
so on, until we reach the leaves of the tree. As an example, compare the
147
(1 2)4123(3 4)((1 2) 3 4)Figure 2.6: e list structure in Figure 2.5 viewed as a tree.
length procedure of Section 2.2.1 with the countleaves procedure,
which returns the total number of leaves of a tree:
(define x (cons (list 1 2) (list 3 4)))
(length x)
3
(countleaves x)
4
(list x x)
(((1 2) 3 4) ((1 2) 3 4))
(length (list x x))
2
(countleaves (list x x))
8
To implement countleaves, recall the recursive plan for computing
length:
• length of a list x is 1 plus length of the cdr of x.
• length of the empty list is 0.
countleaves is similar. e value for the empty list is the same:
• countleaves of the empty list is 0.
148
((1 2) 3 4)(1 2)3412But in the reduction step, where we strip oﬀ the car of the list, we must
take into account that the car may itself be a tree whose leaves we need
to count. us, the appropriate reduction step is
• countleaves of a tree x is countleaves of the car of x plus
countleaves of the cdr of x.
Finally, by taking cars we reach actual leaves, so we need another base
case:
• countleaves of a leaf is 1.
To aid in writing recursive procedures on trees, Scheme provides the
primitive predicate pair?, which tests whether its argument is a pair.
Here is the complete procedure:13
(define (countleaves x)
(cond ((null? x) 0)
((not (pair? x)) 1)
(else (+ (countleaves (car x))
(countleaves (cdr x))))))
Exercise 2.24: Suppose we evaluate the expression (list
1 (list 2 (list 3 4))). Give the result printed by the
interpreter, the corresponding boxandpointer structure,
and the interpretation of this as a tree (as in Figure 2.6).
Exercise 2.25: Give combinations of cars and cdrs that
will pick 7 from each of the following lists:
13e order of the ﬁrst two clauses in the cond maers, since the empty list satisﬁes
null? and also is not a pair.
149
(1 3 (5 7) 9)
((7))
(1 (2 (3 (4 (5 (6 7))))))
Exercise 2.26: Suppose we deﬁne x and y to be two lists:
(define x (list 1 2 3))
(define y (list 4 5 6))
What result is printed by the interpreter in response to eval
uating each of the following expressions:
(append x y)
(cons x y)
(list x y)
Exercise 2.27: Modify your reverse procedure of Exercise
2.18 to produce a deepreverse procedure that takes a list
as argument and returns as its value the list with its ele
ments reversed and with all sublists deepreversed as well.
For example,
(define x (list (list 1 2) (list 3 4)))
x
((1 2) (3 4))
(reverse x)
((3 4) (1 2))
(deepreverse x)
((4 3) (2 1))
Exercise 2.28: Write a procedure fringe that takes as argu
ment a tree (represented as a list) and returns a list whose
elements are all the leaves of the tree arranged in leto
right order. For example,
150
(define x (list (list 1 2) (list 3 4)))
(fringe x)
(1 2 3 4)
(fringe (list x x))
(1 2 3 4 1 2 3 4)
Exercise 2.29: A binary mobile consists of two branches,
a le branch and a right branch. Each branch is a rod of
a certain length, from which hangs either a weight or an
other binary mobile. We can represent a binary mobile us
ing compound data by constructing it from two branches
(for example, using list):
(define (makemobile left right)
(list left right))
A branch is constructed from a length (which must be a
number) together with a structure, which may be either a
number (representing a simple weight) or another mobile:
(define (makebranch length structure)
(list length structure))
a. Write the corresponding selectors leftbranch and
rightbranch, which return the branches of a mobile,
and branchlength and branchstructure, which re
turn the components of a branch.
b. Using your selectors, deﬁne a procedure totalweight
that returns the total weight of a mobile.
c. A mobile is said to be balanced if the torque applied by
its tople branch is equal to that applied by its top
151
right branch (that is, if the length of the le rod mul
tiplied by the weight hanging from that rod is equal
to the corresponding product for the right side) and if
each of the submobiles hanging oﬀ its branches is bal
anced. Design a predicate that tests whether a binary
mobile is balanced.
d. Suppose we change the representation of mobiles so
that the constructors are
(define (makemobile left right) (cons left right))
(define (makebranch length structure)
(cons length structure))
How much do you need to change your programs to
convert to the new representation?
Mapping over trees
Just as map is a powerful abstraction for dealing with sequences, map
together with recursion is a powerful abstraction for dealing with trees.
For instance, the scaletree procedure, analogous to scalelist of
Section 2.2.1, takes as arguments a numeric factor and a tree whose
leaves are numbers. It returns a tree of the same shape, where each
number is multiplied by the factor. e recursive plan for scaletree
is similar to the one for countleaves:
(define (scaletree tree factor)
(cond ((null? tree) nil)
((not (pair? tree)) (* tree factor))
(else (cons (scaletree (car tree) factor)
(scaletree (cdr tree) factor)))))
(scaletree (list 1 (list 2 (list 3 4) 5) (list 6 7)) 10)
(10 (20 (30 40) 50) (60 70))
152
Another way to implement scaletree is to regard the tree as a se
quence of subtrees and use map. We map over the sequence, scaling
each subtree in turn, and return the list of results. In the base case,
where the tree is a leaf, we simply multiply by the factor:
(define (scaletree tree factor)
(map (lambda (subtree)
(if (pair? subtree)
(scaletree subtree factor)
(* subtree factor)))
tree))
Many tree operations can be implemented by similar combinations of
sequence operations and recursion.
Exercise 2.30: Deﬁne a procedure squaretree analogous
to the squarelist procedure of Exercise 2.21. at is, square
tree should behave as follows:
(squaretree
(list 1
(list 2 (list 3 4) 5)
(list 6 7)))
(1 (4 (9 16) 25) (36 49))
Deﬁne squaretree both directly (i.e., without using any
higherorder procedures) and also by using map and recur
sion.
Exercise 2.31: Abstract your answer to Exercise 2.30 to
produce a procedure treemap with the property that square
tree could be deﬁned as
(define (squaretree tree) (treemap square tree))
153
Exercise 2.32: We can represent a set as a list of distinct
elements, and we can represent the set of all subsets of the
set as a list of lists. For example, if the set is (1 2 3), then
the set of all subsets is (() (3) (2) (2 3) (1) (1 3)
(1 2) (1 2 3)). Complete the following deﬁnition of a
procedure that generates the set of subsets of a set and give
a clear explanation of why it works:
(define (subsets s)
(if (null? s)
(list nil)
(let ((rest (subsets (cdr s))))
(append rest (map ⟨??⟩ rest)))))
2.2.3 Sequences as Conventional Interfaces
In working with compound data, we’ve stressed how data abstraction
permits us to design programs without becoming enmeshed in the de
tails of data representations, and how abstraction preserves for us the
ﬂexibility to experiment with alternative representations. In this sec
tion, we introduce another powerful design principle for working with
data structures—the use of conventional interfaces.
In Section 1.3 we saw how program abstractions, implemented as
higherorder procedures, can capture common paerns in programs
that deal with numerical data. Our ability to formulate analogous oper
ations for working with compound data depends crucially on the style
in which we manipulate our data structures. Consider, for example, the
following procedure, analogous to the countleaves procedure of Sec
tion 2.2.2, which takes a tree as argument and computes the sum of the
squares of the leaves that are odd:
154
(define (sumoddsquares tree)
(cond ((null? tree) 0)
((not (pair? tree))
(if (odd? tree) (square tree) 0))
(else (+ (sumoddsquares (car tree))
(sumoddsquares (cdr tree))))))
On the surface, this procedure is very diﬀerent from the following one,
which constructs a list of all the even Fibonacci numbers Fib(k), where
k is less than or equal to a given integer n:
(define (evenfibs n)
(define (next k)
(if (> k n)
nil
(let ((f (fib k)))
(if (even? f)
(cons f (next (+ k 1)))
(next (+ k 1))))))
(next 0))
Despite the fact that these two procedures are structurally very diﬀer
ent, a more abstract description of the two computations reveals a great
deal of similarity. e ﬁrst program
• enumerates the leaves of a tree;
• ﬁlters them, selecting the odd ones;
• squares each of the selected ones; and
• accumulates the results using +, starting with 0.
e second program
155
Figure 2.7: e signalﬂow plans for the procedures sum
oddsquares (top) and evenfibs (boom) reveal the com
monality between the two programs.
• enumerates the integers from 0 to n;
• computes the Fibonacci number for each integer;
• ﬁlters them, selecting the even ones; and
• accumulates the results using cons, starting with the empty list.
A signalprocessing engineer would ﬁnd it natural to conceptualize these
processes in terms of signals ﬂowing through a cascade of stages, each
of which implements part of the program plan, as shown in Figure 2.7.
In sumoddsquares, we begin with an enumerator, which generates a
“signal” consisting of the leaves of a given tree. is signal is passed
through a ﬁlter, which eliminates all but the odd elements. e result
ing signal is in turn passed through a map, which is a “transducer” that
applies the square procedure to each element. e output of the map
is then fed to an accumulator, which combines the elements using +,
starting from an initial 0. e plan for evenfibs is analogous.
Unfortunately, the two procedure deﬁnitions above fail to exhibit
this signalﬂow structure. For instance, if we examine the sumodd
156
enumerate:tree leavesfilter:odd?map:squareaccumulate:+, 0enumerate:integersmap:fibfilter:even?accumulate:cons, ()squares procedure, we ﬁnd that the enumeration is implemented partly
by the null? and pair? tests and partly by the treerecursive structure
of the procedure. Similarly, the accumulation is found partly in the tests
and partly in the addition used in the recursion. In general, there are no
distinct parts of either procedure that correspond to the elements in the
signalﬂow description. Our two procedures decompose the computa
tions in a diﬀerent way, spreading the enumeration over the program
and mingling it with the map, the ﬁlter, and the accumulation. If we
could organize our programs to make the signalﬂow structure manifest
in the procedures we write, this would increase the conceptual clarity
of the resulting code.
Sequence Operations
e key to organizing programs so as to more clearly reﬂect the signal
ﬂow structure is to concentrate on the “signals” that ﬂow from one stage
in the process to the next. If we represent these signals as lists, then we
can use list operations to implement the processing at each of the stages.
For instance, we can implement the mapping stages of the signalﬂow
diagrams using the map procedure from Section 2.2.1:
(map square (list 1 2 3 4 5))
(1 4 9 16 25)
Filtering a sequence to select only those elements that satisfy a given
predicate is accomplished by
(define (filter predicate sequence)
(cond ((null? sequence) nil)
((predicate (car sequence))
(cons (car sequence)
(filter predicate (cdr sequence))))
(else (filter predicate (cdr sequence)))))
157
For example,
(filter odd? (list 1 2 3 4 5))
(1 3 5)
Accumulations can be implemented by
(define (accumulate op initial sequence)
(if (null? sequence)
initial
(op (car sequence)
(accumulate op initial (cdr sequence)))))
(accumulate + 0 (list 1 2 3 4 5))
15
(accumulate * 1 (list 1 2 3 4 5))
120
(accumulate cons nil (list 1 2 3 4 5))
(1 2 3 4 5)
All that remains to implement signalﬂow diagrams is to enumerate the
sequence of elements to be processed. For evenfibs, we need to gen
erate the sequence of integers in a given range, which we can do as
follows:
(define (enumerateinterval low high)
(if (> low high)
nil
(cons low (enumerateinterval (+ low 1) high))))
(enumerateinterval 2 7)
(2 3 4 5 6 7)
To enumerate the leaves of a tree, we can use14
14is is, in fact, precisely the fringe procedure from Exercise 2.28. Here we’ve re
named it to emphasize that it is part of a family of general sequencemanipulation
procedures.
158
(define (enumeratetree tree)
(cond ((null? tree) nil)
((not (pair? tree)) (list tree))
(else (append (enumeratetree (car tree))
(enumeratetree (cdr tree))))))
(enumeratetree (list 1 (list 2 (list 3 4)) 5))
(1 2 3 4 5)
Now we can reformulate sumoddsquares and evenfibs as in the
signalﬂow diagrams. For sumoddsquares, we enumerate the sequence
of leaves of the tree, ﬁlter this to keep only the odd numbers in the se
quence, square each element, and sum the results:
(define (sumoddsquares tree)
(accumulate
+ 0 (map square (filter odd? (enumeratetree tree)))))
For evenfibs, we enumerate the integers from 0 to n, generate the Fi
bonacci number for each of these integers, ﬁlter the resulting sequence
to keep only the even elements, and accumulate the results into a list:
(define (evenfibs n)
(accumulate
cons
nil
(filter even? (map fib (enumerateinterval 0 n)))))
e value of expressing programs as sequence operations is that this
helps us make program designs that are modular, that is, designs that
are constructed by combining relatively independent pieces. We can en
courage modular design by providing a library of standard components
together with a conventional interface for connecting the components
in ﬂexible ways.
159
Modular construction is a powerful strategy for controlling com
plexity in engineering design. In real signalprocessing applications, for
example, designers regularly build systems by cascading elements se
lected from standardized families of ﬁlters and transducers. Similarly,
sequence operations provide a library of standard program elements
that we can mix and match. For instance, we can reuse pieces from the
sumoddsquares and evenfibs procedures in a program that con
structs a list of the squares of the ﬁrst n + 1 Fibonacci numbers:
(define (listfibsquares n)
(accumulate
cons
nil
(map square (map fib (enumerateinterval 0 n)))))
(listfibsquares 10)
(0 1 1 4 9 25 64 169 441 1156 3025)
We can rearrange the pieces and use them in computing the product of
the squares of the odd integers in a sequence:
(define (productofsquaresofoddelements sequence)
(accumulate * 1 (map square (filter odd? sequence))))
(productofsquaresofoddelements (list 1 2 3 4 5))
225
We can also formulate conventional dataprocessing applications in terms
of sequence operations. Suppose we have a sequence of personnel records
and we want to ﬁnd the salary of the highestpaid programmer. Assume
that we have a selector salary that returns the salary of a record, and a
predicate programmer? that tests if a record is for a programmer. en
we can write
(define (salaryofhighestpaidprogrammer records)
(accumulate max 0 (map salary (filter programmer? records))))
160
ese examples give just a hint of the vast range of operations that can
be expressed as sequence operations.15
Sequences, implemented here as lists, serve as a conventional in
terface that permits us to combine processing modules. Additionally,
when we uniformly represent structures as sequences, we have local
ized the datastructure dependencies in our programs to a small number
of sequence operations. By changing these, we can experiment with al
ternative representations of sequences, while leaving the overall design
of our programs intact. We will exploit this capability in Section 3.5,
when we generalize the sequenceprocessing paradigm to admit inﬁ
nite sequences.
Exercise 2.33: Fill in the missing expressions to complete
the following deﬁnitions of some basic listmanipulation
operations as accumulations:
(define (map p sequence)
(accumulate (lambda (x y) ⟨??⟩) nil sequence))
(define (append seq1 seq2)
(accumulate cons ⟨??⟩ ⟨??⟩))
(define (length sequence)
(accumulate ⟨??⟩ 0 sequence))
15Richard Waters (1979) developed a program that automatically analyzes traditional
Fortran programs, viewing them in terms of maps, ﬁlters, and accumulations. He found
that fully 90 percent of the code in the Fortran Scientiﬁc Subroutine Package ﬁts neatly
into this paradigm. One of the reasons for the success of Lisp as a programming lan
guage is that lists provide a standard medium for expressing ordered collections so that
they can be manipulated using higherorder operations. e programming language
APL owes much of its power and appeal to a similar choice. In APL all data are repre
sented as arrays, and there is a universal and convenient set of generic operators for all
sorts of array operations.
161
Exercise 2.34: Evaluating a polynomial in x at a given value
of x can be formulated as an accumulation. We evaluate the
polynomial
anxn + an(cid:0)1xn(cid:0)1 + (cid:1) (cid:1) (cid:1) + a1x + a0
using a wellknown algorithm called Horner’s rule, which
structures the computation as
(: : : (anx + an(cid:0)1)x + (cid:1) (cid:1) (cid:1) + a1)x + a0:
In other words, we start with an, multiply by x, add an(cid:0)1,
multiply by x, and so on, until we reach a0.16
Fill in the following template to produce a procedure that
evaluates a polynomial using Horner’s rule. Assume that
the coeﬃcients of the polynomial are arranged in a sequence,
from a0 through an.
(define (hornereval x coefficientsequence)
(accumulate (lambda (thiscoeff higherterms) ⟨??⟩)
0
coefficientsequence))
16According to Knuth 1981, this rule was formulated by W. G. Horner early in the
nineteenth century, but the method was actually used by Newton over a hundred years
earlier. Horner’s rule evaluates the polynomial using fewer additions and multipli
cations than does the straightforward method of ﬁrst computing anxn, then adding
an(cid:0)1xn(cid:0)1, and so on. In fact, it is possible to prove that any algorithm for evaluating
arbitrary polynomials must use at least as many additions and multiplications as does
Horner’s rule, and thus Horner’s rule is an optimal algorithm for polynomial evaluation.
is was proved (for the number of additions) by A. M. Ostrowski in a 1954 paper that
essentially founded the modern study of optimal algorithms. e analogous statement
for multiplications was proved by V. Y. Pan in 1966. e book by Borodin and Munro
(1975) provides an overview of these and other results about optimal algorithms.
162
For example, to compute 1+3x +5x 3 +x 5 at x = 2 you would
evaluate
(hornereval 2 (list 1 3 0 5 0 1))
Exercise 2.35: Redeﬁne countleaves from Section 2.2.2
as an accumulation:
(define (countleaves t)
(accumulate ⟨??⟩ ⟨??⟩ (map ⟨??⟩ ⟨??⟩)))
Exercise 2.36: e procedure accumulaten is similar to
accumulate except that it takes as its third argument a se
quence of sequences, which are all assumed to have the
same number of elements. It applies the designated accu
mulation procedure to combine all the ﬁrst elements of the
sequences, all the second elements of the sequences, and so
on, and returns a sequence of the results. For instance, if s
is a sequence containing four sequences, ((1 2 3) (4 5 6)
(7 8 9) (10 11 12)), then the value of (accumulaten +
0 s) should be the sequence (22 26 30). Fill in the missing
expressions in the following deﬁnition of accumulaten:
(define (accumulaten op init seqs)
(if (null? (car seqs))
nil
(cons (accumulate op init ⟨??⟩)
(accumulaten op init ⟨??⟩))))
Exercise 2.37: Suppose we represent vectors v = (vi ) as
sequences of numbers, and matrices m = (mij ) as sequences
163
of vectors (the rows of the matrix). For example, the matrix
0BBBBBBBB@ 1 2 3 4
4 5 6 6
6 7 8 9
1CCCCCCCCA
is represented as the sequence ((1 2 3 4) (4 5 6 6)
(6 7 8 9)). With this representation, we can use sequence
operations to concisely express the basic matrix and vector
operations. ese operations (which are described in any
book on matrix algebra) are the following:
(dotproduct v w) returns the sum Σiviwi ;
(matrix*vector m v) returns the vector t;
where ti = Σjmijvj ;
(matrix*matrix m n) returns the matrix p;
where pij = Σkmiknkj ;
(transpose m) returns the matrix n;
where nij = mji :
We can deﬁne the dot product as17
(define (dotproduct v w)
(accumulate + 0 (map * v w)))
Fill in the missing expressions in the following procedures
for computing the other matrix operations. (e procedure
accumulaten is deﬁned in Exercise 2.36.)
(define (matrix*vector m v)
(map ⟨??⟩ m))
17is deﬁnition uses the extended version of map described in Footnote 12.
164
(define (transpose mat)
(accumulaten ⟨??⟩ ⟨??⟩ mat))
(define (matrix*matrix m n)
(let ((cols (transpose n)))
(map ⟨??⟩ m)))
Exercise 2.38: e accumulate procedure is also known as
foldright, because it combines the ﬁrst element of the se
quence with the result of combining all the elements to the
right. ere is also a foldleft, which is similar to fold
right, except that it combines elements working in the op
posite direction:
(define (foldleft op initial sequence)
(define (iter result rest)
(if (null? rest)
result
(iter (op result (car rest))
(cdr rest))))
(iter initial sequence))
What are the values of
(foldright / 1 (list 1 2 3))
(foldleft / 1 (list 1 2 3))
(foldright list nil (list 1 2 3))
(foldleft list nil (list 1 2 3))
Give a property that op should satisfy to guarantee that
foldright and foldleft will produce the same values
for any sequence.
165
Exercise 2.39: Complete the following deﬁnitions of reverse
(Exercise 2.18) in terms of foldright and foldleft from
Exercise 2.38:
(define (reverse sequence)
(foldright (lambda (x y) ⟨??⟩) nil sequence))
(define (reverse sequence)
(foldleft (lambda (x y) ⟨??⟩) nil sequence))
Nested Mappings
We can extend the sequence paradigm to include many computations
that are commonly expressed using nested loops.18 Consider this prob
lem: Given a positive integer n, ﬁnd all ordered pairs of distinct positive
integers i and j, where 1 (cid:20) j < i (cid:20) n, such that i + j is prime. For
example, if n is 6, then the pairs are the following:
i
j
i + j
2
1
3
3
2
5
4
1
5
4
3
7
5
2
7
6
1
7
6
5
11
A natural way to organize this computation is to generate the sequence
of all ordered pairs of positive integers less than or equal to n, ﬁlter to
select those pairs whose sum is prime, and then, for each pair (i; j) that
passes through the ﬁlter, produce the triple (i; j;i + j).
Here is a way to generate the sequence of pairs: For each integer
i (cid:20) n, enumerate the integers j < i, and for each such i and j gener
ate the pair (i; j). In terms of sequence operations, we map along the
18is approach to nested mappings was shown to us by David Turner, whose lan
guages KRC and Miranda provide elegant formalisms for dealing with these constructs.
e examples in this section (see also Exercise 2.42) are adapted from Turner 1981. In
Section 3.5.3, we’ll see how this approach generalizes to inﬁnite sequences.
166
sequence (enumerateinterval 1 n). For each i in this sequence, we
map along the sequence (enumerateinterval 1 ( i 1)). For each
j in this laer sequence, we generate the pair (list i j). is gives
us a sequence of pairs for each i. Combining all the sequences for all
the i (by accumulating with append) produces the required sequence of
pairs:19
(accumulate
append nil (map (lambda (i)
(map (lambda (j) (list i j))
(enumerateinterval 1 ( i 1))))
(enumerateinterval 1 n)))
e combination of mapping and accumulating with append is so com
mon in this sort of program that we will isolate it as a separate proce
dure:
(define (flatmap proc seq)
(accumulate append nil (map proc seq)))
Now ﬁlter this sequence of pairs to ﬁnd those whose sum is prime. e
ﬁlter predicate is called for each element of the sequence; its argument is
a pair and it must extract the integers from the pair. us, the predicate
to apply to each element in the sequence is
(define (primesum? pair)
(prime? (+ (car pair) (cadr pair))))
Finally, generate the sequence of results by mapping over the ﬁltered
pairs using the following procedure, which constructs a triple consisting
of the two elements of the pair along with their sum:
19We’re representing a pair here as a list of two elements rather than as a Lisp pair.
us, the “pair” (i; j) is represented as (list i j), not (cons i j).
167
(define (makepairsum pair)
(list (car pair) (cadr pair) (+ (car pair) (cadr pair))))
Combining all these steps yields the complete procedure:
(define (primesumpairs n)
(map makepairsum
(filter primesum? (flatmap
(lambda (i)
(map (lambda (j) (list i j))
(enumerateinterval 1 ( i 1))))
(enumerateinterval 1 n)))))
Nested mappings are also useful for sequences other than those that
enumerate intervals. Suppose we wish to generate all the permutations
of a set S; that is, all the ways of ordering the items in the set. For in
stance, the permutations of {1; 2; 3} are {1; 2; 3}, {1; 3; 2}, {2; 1; 3}, {2; 3; 1},
{3; 1; 2}, and {3; 2; 1}. Here is a plan for generating the permutations of S:
For each item x in S, recursively generate the sequence of permutations
of S (cid:0) x,20 and adjoin x to the front of each one. is yields, for each x
in S, the sequence of permutations of S that begin with x. Combining
these sequences for all x gives all the permutations of S:21
(define (permutations s)
(if (null? s)
(list nil)
(flatmap (lambda (x)
; empty set?
; sequence containing empty set
(map (lambda (p) (cons x p))
(permutations (remove x s))))
s)))
20e set S (cid:0) x is the set of all elements of S, excluding x.
21Semicolons in Scheme code are used to introduce comments. Everything from the
semicolon to the end of the line is ignored by the interpreter. In this book we don’t use
many comments; we try to make our programs selfdocumenting by using descriptive
names.
168
Notice how this strategy reduces the problem of generating permuta
tions of S to the problem of generating the permutations of sets with
fewer elements than S. In the terminal case, we work our way down to
the empty list, which represents a set of no elements. For this, we gen
erate (list nil), which is a sequence with one item, namely the set
with no elements. e remove procedure used in permutations returns
all the items in a given sequence except for a given item. is can be
expressed as a simple ﬁlter:
(define (remove item sequence)
(filter (lambda (x) (not (= x item)))
sequence))
Exercise 2.40: Deﬁne a procedure uniquepairs that, given
an integer n, generates the sequence of pairs (i; j) with 1 (cid:20)
j < i (cid:20) n. Use uniquepairs to simplify the deﬁnition of
primesumpairs given above.
Exercise 2.41: Write a procedure to ﬁnd all ordered triples
of distinct positive integers i, j, and k less than or equal to
a given integer n that sum to a given integer s.
Exercise 2.42: e “eightqueens puzzle” asks how to place
eight queens on a chessboard so that no queen is in check
from any other (i.e., no two queens are in the same row, col
umn, or diagonal). One possible solution is shown in Figure
2.8. One way to solve the puzzle is to work across the board,
placing a queen in each column. Once we have placed k (cid:0) 1
queens, we must place the kth queen in a position where it
does not check any of the queens already on the board. We
can formulate this approach recursively: Assume that we
169
Figure 2.8: A solution to the eightqueens puzzle.
have already generated the sequence of all possible ways
to place k (cid:0) 1 queens in the ﬁrst k (cid:0) 1 columns of the board.
For each of these ways, generate an extended set of posi
tions by placing a queen in each row of the kth column.
Now ﬁlter these, keeping only the positions for which the
queen in the kth column is safe with respect to the other
queens. is produces the sequence of all ways to place k
queens in the ﬁrst k columns. By continuing this process,
we will produce not only one solution, but all solutions to
the puzzle.
We implement this solution as a procedure queens, which
returns a sequence of all solutions to the problem of plac
ing n queens on an n (cid:2) n chessboard. queens has an inter
nal procedure queencols that returns the sequence of all
ways to place queens in the ﬁrst k columns of the board.
170
(define (queens boardsize)
(define (queencols k)
(if (= k 0)
(list emptyboard)
(filter
(lambda (positions) (safe? k positions))
(flatmap
(lambda (restofqueens)
(map (lambda (newrow)
(adjoinposition
newrow k restofqueens))
(enumerateinterval 1 boardsize)))
(queencols ( k 1))))))
(queencols boardsize))
In this procedure restofqueens is a way to place k (cid:0) 1
queens in the ﬁrst k(cid:0)1 columns, and newrow is a proposed
row in which to place the queen for the kth column. Com
plete the program by implementing the representation for
sets of board positions, including the procedure adjoin
position, which adjoins a new rowcolumn position to a
set of positions, and emptyboard, which represents an empty
set of positions. You must also write the procedure safe?,
which determines for a set of positions, whether the queen
in the kth column is safe with respect to the others. (Note
that we need only check whether the new queen is safe—
the other queens are already guaranteed safe with respect
to each other.)
Exercise 2.43: Louis Reasoner is having a terrible time do
ing Exercise 2.42. His queens procedure seems to work, but
it runs extremely slowly. (Louis never does manage to wait
171
long enough for it to solve even the 6(cid:2) 6 case.) When Louis
asks Eva Lu Ator for help, she points out that he has inter
changed the order of the nested mappings in the flatmap,
writing it as
(flatmap
(lambda (newrow)
(map (lambda (restofqueens)
(adjoinposition newrow k restofqueens))
(queencols ( k 1))))
(enumerateinterval 1 boardsize))
Explain why this interchange makes the program run slowly.
Estimate how long it will take Louis’s program to solve the
eightqueens puzzle, assuming that the program in Exercise
2.42 solves the puzzle in time T .
2.2.4 Example: A Picture Language
is section presents a simple language for drawing pictures that il
lustrates the power of data abstraction and closure, and also exploits
higherorder procedures in an essential way. e language is designed
to make it easy to experiment with paerns such as the ones in Fig
ure 2.9, which are composed of repeated elements that are shied and
scaled.22 In this language, the data objects being combined are repre
sented as procedures rather than as list structure. Just as cons, which
satisﬁes the closure property, allowed us to easily build arbitrarily com
plicated list structure, the operations in this language, which also sat
22e picture language is based on the language Peter Henderson created to construct
images like M.C. Escher’s “Square Limit” woodcut (see Henderson 1982). e woodcut
incorporates a repeated scaled paern, similar to the arrangements drawn using the
squarelimit procedure in this section.
172
Figure 2.9: Designs generated with the picture language.
isfy the closure property, allow us to easily build arbitrarily complicated
paerns.
The picture language
When we began our study of programming in Section 1.1, we empha
sized the importance of describing a language by focusing on the lan
guage’s primitives, its means of combination, and its means of abstrac
tion. We’ll follow that framework here.
Part of the elegance of this picture language is that there is only one
kind of element, called a painter. A painter draws an image that is shied
and scaled to ﬁt within a designated parallelogramshaped frame. For
example, there’s a primitive painter we’ll call wave that makes a crude
line drawing, as shown in Figure 2.10. e actual shape of the drawing
depends on the frame—all four images in ﬁgure 2.10 are produced by the
173
Figure 2.10: Images produced by the wave painter, with
respect to four diﬀerent frames. e frames, shown with
doed lines, are not part of the images.
same wave painter, but with respect to four diﬀerent frames. Painters
can be more elaborate than this: e primitive painter called rogers
paints a picture of ’s founder, William Barton Rogers, as shown in
Figure 2.11.23 e four images in ﬁgure 2.11 are drawn with respect to
23William Barton Rogers (18041882) was the founder and ﬁrst president of .
A geologist and talented teacher, he taught at William and Mary College and at the
University of Virginia. In 1859 he moved to Boston, where he had more time for re
search, worked on a plan for establishing a “polytechnic institute,” and served as Mas
sachuses’s ﬁrst State Inspector of Gas Meters.
When was established in 1861, Rogers was elected its ﬁrst president. Rogers
espoused an ideal of “useful learning” that was diﬀerent from the university education
of the time, with its overemphasis on the classics, which, as he wrote, “stand in the way
of the broader, higher and more practical instruction and discipline of the natural and
social sciences.” is education was likewise to be diﬀerent from narrow tradeschool
174
the same four frames as the wave images in ﬁgure 2.10.
To combine images, we use various operations that construct new
painters from given painters. For example, the beside operation takes
two painters and produces a new, compound painter that draws the ﬁrst
education. In Rogers’s words:
e worldenforced distinction between the practical and the scientiﬁc
worker is uerly futile, and the whole experience of modern times has
demonstrated its uer worthlessness.
Rogers served as president of until 1870, when he resigned due to ill health.
In 1878 the second president of , John Runkle, resigned under the pressure of a
ﬁnancial crisis brought on by the Panic of 1873 and strain of ﬁghting oﬀ aempts by
Harvard to take over . Rogers returned to hold the oﬃce of president until 1881.
Rogers collapsed and died while addressing ’s graduating class at the commence
ment exercises of 1882. Runkle quoted Rogers’s last words in a memorial address de
livered that same year:
“As I stand here today and see what the Institute is, : : : I call to mind
the beginnings of science. I remember one hundred and ﬁy years ago
Stephen Hales published a pamphlet on the subject of illuminating gas,
in which he stated that his researches had demonstrated that 128 grains
of bituminous coal – ” “Bituminous coal,” these were his last words on
earth. Here he bent forward, as if consulting some notes on the table
before him, then slowly regaining an erect position, threw up his hands,
and was translated from the scene of his earthly labors and triumphs
to “the tomorrow of death,” where the mysteries of life are solved, and
the disembodied spirit ﬁnds unending satisfaction in contemplating the
new and still unfathomable mysteries of the inﬁnite future.
In the words of Francis A. Walker (’s third president):
All his life he had borne himself most faithfully and heroically, and he
died as so good a knight would surely have wished, in harness, at his
post, and in the very part and act of public duty.
175
Figure 2.11: Images of William Barton Rogers, founder and
ﬁrst president of , painted with respect to the same four
frames as in Figure 2.10 (original image from Wikimedia
Commons).
painter’s image in the le half of the frame and the second painter’s im
age in the right half of the frame. Similarly, below takes two painters and
produces a compound painter that draws the ﬁrst painter’s image below
the second painter’s image. Some operations transform a single painter
to produce a new painter. For example, flipvert takes a painter and
produces a painter that draws its image upsidedown, and fliphoriz
produces a painter that draws the original painter’s image letoright
reversed.
Figure 2.12 shows the drawing of a painter called wave4 that is built
up in two stages starting from wave:
(define wave2 (beside wave (flipvert wave)))
(define wave4 (below wave2 wave2))
176
Figure 2.12: Creating a complex ﬁgure, starting from the
wave painter of Figure 2.10.
In building up a complex image in this manner we are exploiting the
fact that painters are closed under the language’s means of combination.
e beside or below of two painters is itself a painter; therefore, we can
use it as an element in making more complex painters. As with building
up list structure using cons, the closure of our data under the means of
combination is crucial to the ability to create complex structures while
using only a few operations.
Once we can combine painters, we would like to be able to abstract
typical paerns of combining painters. We will implement the painter
operations as Scheme procedures. is means that we don’t need a spe
cial abstraction mechanism in the picture language: Since the means of
combination are ordinary Scheme procedures, we automatically have
the capability to do anything with painter operations that we can do
with procedures. For example, we can abstract the paern in wave4 as
(define (flippedpairs painter)
(let ((painter2 (beside painter (flipvert painter))))
(below painter2 painter2)))
and deﬁne wave4 as an instance of this paern:
(define wave4 (flippedpairs wave))
177
Figure 2.13: Recursive plans for rightsplit and cornersplit.
We can also deﬁne recursive operations. Here’s one that makes painters
split and branch towards the right as shown in Figure 2.13 and Figure
2.14:
(define (rightsplit painter n)
(if (= n 0)
painter
(let ((smaller (rightsplit painter ( n 1))))
(beside painter (below smaller smaller)))))
We can produce balanced paerns by branching upwards as well as
towards the right (see exercise Exercise 2.44 and ﬁgures Figure 2.13 and
Figure 2.14):
(define (cornersplit painter n)
(if (= n 0)
painter
178
rightsplitidentityrightsplitrightsplit nrightsplitcornersplitupsplitn1upsplitrightsplitidentityn1n1n1n1cornersplit nn1n1(let ((up (upsplit painter ( n 1)))
(right (rightsplit painter ( n 1))))
(let ((topleft (beside up up))
(bottomright (below right right))
(corner (cornersplit painter ( n 1))))
(beside (below painter topleft)
(below bottomright corner))))))
By placing four copies of a cornersplit appropriately, we obtain a
paern called squarelimit, whose application to wave and rogers is
shown in Figure 2.9:
(define (squarelimit painter n)
(let ((quarter (cornersplit painter n)))
(let ((half (beside (fliphoriz quarter) quarter)))
(below (flipvert half) half))))
Exercise 2.44: Deﬁne the procedure upsplit used by corner
split. It is similar to rightsplit, except that it switches
the roles of below and beside.
Higherorder operations
In addition to abstracting paerns of combining painters, we can work
at a higher level, abstracting paerns of combining painter operations.
at is, we can view the painter operations as elements to manipulate
and can write means of combination for these elements—procedures
that take painter operations as arguments and create new painter oper
ations.
For example, flippedpairs and squarelimit each arrange four
copies of a painter’s image in a square paern; they diﬀer only in how
179
Figure 2.14: e recursive operations rightsplit and
cornersplit applied to the painters wave and rogers.
Combining four cornersplit ﬁgures produces symmet
ric squarelimit designs as shown in Figure 2.9.
180
(rightsplit wave 4)(rightsplit rogers 4)(cornersplit wave 4)(cornersplit rogers 4)they orient the copies. One way to abstract this paern of painter com
bination is with the following procedure, which takes four oneargument
painter operations and produces a painter operation that transforms a
given painter with those four operations and arranges the results in a
square. tl, tr, bl, and br are the transformations to apply to the top
le copy, the top right copy, the boom le copy, and the boom right
copy, respectively.
(define (squareoffour tl tr bl br)
(lambda (painter)
(let ((top (beside (tl painter) (tr painter)))
(bottom (beside (bl painter) (br painter))))
(below bottom top))))
en flippedpairs can be deﬁned in terms of squareoffour as
follows:24
(define (flippedpairs painter)
(let ((combine4 (squareoffour identity flipvert
identity flipvert)))
(combine4 painter)))
and squarelimit can be expressed as25
(define (squarelimit painter n)
(let ((combine4 (squareoffour fliphoriz identity
rotate180 flipvert)))
24Equivalently, we could write
(define flippedpairs
(squareoffour identity flipvert identity flipvert))
25rotate180 rotates a painter by 180 degrees (see Exercise 2.50). Instead of ro
tate180 we could say (compose flipvert fliphoriz), using the compose pro
cedure from Exercise 1.42.
181
(combine4 (cornersplit painter n))))
Exercise 2.45: rightsplit and upsplit can be expressed
as instances of a general spliing operation. Deﬁne a pro
cedure split with the property that evaluating
(define rightsplit (split beside below))
(define upsplit (split below beside))
produces procedures rightsplit and upsplit with the
same behaviors as the ones already deﬁned.
Frames
Before we can show how to implement painters and their means of com
bination, we must ﬁrst consider frames. A frame can be described by
three vectors—an origin vector and two edge vectors. e origin vector
speciﬁes the oﬀset of the frame’s origin from some absolute origin in
the plane, and the edge vectors specify the oﬀsets of the frame’s cor
ners from its origin. If the edges are perpendicular, the frame will be
rectangular. Otherwise the frame will be a more general parallelogram.
Figure 2.15 shows a frame and its associated vectors. In accordance
with data abstraction, we need not be speciﬁc yet about how frames are
represented, other than to say that there is a constructor makeframe,
which takes three vectors and produces a frame, and three correspond
ing selectors originframe, edge1frame, and edge2frame (see Exer
cise 2.47).
We will use coordinates in the unit square (0 (cid:20) x ; y (cid:20) 1) to specify
images. With each frame, we associate a frame coordinate map, which
will be used to shi and scale images to ﬁt the frame. e map trans
forms the unit square into the frame by mapping the vector v = (x ; y)
182
Figure 2.15: A frame is described by three vectors — an
origin and two edges.
to the vector sum
Origin(Frame) + x (cid:1) Edge1(Frame) + y (cid:1) Edge2(Frame):
For example, (0, 0) is mapped to the origin of the frame, (1, 1) to the
vertex diagonally opposite the origin, and (0.5, 0.5) to the center of the
frame. We can create a frame’s coordinate map with the following pro
cedure:26
(define (framecoordmap frame)
(lambda (v)
(addvect
(originframe frame)
26framecoordmap uses the vector operations described in Exercise 2.46 below,
which we assume have been implemented using some representation for vectors. Be
cause of data abstraction, it doesn’t maer what this vector representation is, so long
as the vector operations behave correctly.
183
frameedge1vectorframeedge2vectorframeoriginvector(0, 0) point on display screen(addvect (scalevect (xcorvect v) (edge1frame frame))
(scalevect (ycorvect v) (edge2frame frame))))))
Observe that applying framecoordmap to a frame returns a procedure
that, given a vector, returns a vector. If the argument vector is in the unit
square, the result vector will be in the frame. For example,
((framecoordmap aframe) (makevect 0 0))
returns the same vector as
(originframe aframe)
Exercise 2.46: A twodimensional vector v running from
the origin to a point can be represented as a pair consisting
of an xcoordinate and a ycoordinate. Implement a data
abstraction for vectors by giving a constructor makevect
and corresponding selectors xcorvect and ycorvect. In
terms of your selectors and constructor, implement proce
dures addvect, subvect, and scalevect that perform
the operations vector addition, vector subtraction, and mul
tiplying a vector by a scalar:
(x1; y1) + (x2; y2) = (x1 + x2; y1 + y2);
(x1; y1) (cid:0) (x2; y2) = (x1 (cid:0) x2; y1 (cid:0) y2);
s (cid:1) (x ; y) = (sx ; sy):
Exercise 2.47: Here are two possible constructors for frames:
(define (makeframe origin edge1 edge2)
(list origin edge1 edge2))
(define (makeframe origin edge1 edge2)
(cons origin (cons edge1 edge2)))
For each constructor supply the appropriate selectors to
produce an implementation for frames.
184
Painters
A painter is represented as a procedure that, given a frame as argument,
draws a particular image shied and scaled to ﬁt the frame. at is to
say, if p is a painter and f is a frame, then we produce p’s image in f by
calling p with f as argument.
e details of how primitive painters are implemented depend on
the particular characteristics of the graphics system and the type of im
age to be drawn. For instance, suppose we have a procedure drawline
that draws a line on the screen between two speciﬁed points. en we
can create painters for line drawings, such as the wave painter in Figure
2.10, from lists of line segments as follows:27
(define (segments>painter segmentlist)
(lambda (frame)
(foreach
(lambda (segment)
(drawline
((framecoordmap frame)
(startsegment segment))
((framecoordmap frame)
(endsegment segment))))
segmentlist)))
e segments are given using coordinates with respect to the unit square.
For each segment in the list, the painter transforms the segment end
points with the frame coordinate map and draws a line between the
transformed points.
Representing painters as procedures erects a powerful abstraction
barrier in the picture language. We can create and intermix all sorts of
27segments>painter uses the representation for line segments described in Exer
cise 2.48 below. It also uses the foreach procedure described in Exercise 2.23.
185
primitive painters, based on a variety of graphics capabilities. e de
tails of their implementation do not maer. Any procedure can serve as
a painter, provided that it takes a frame as argument and draws some
thing scaled to ﬁt the frame.28
Exercise 2.48: A directed line segment in the plane can be
represented as a pair of vectors—the vector running from
the origin to the startpoint of the segment, and the vector
running from the origin to the endpoint of the segment.
Use your vector representation from Exercise 2.46 to de
ﬁne a representation for segments with a constructor make
segment and selectors startsegment and endsegment.
Exercise 2.49: Use segments>painter to deﬁne the fol
lowing primitive painters:
a. e painter that draws the outline of the designated
frame.
b. e painter that draws an “X” by connecting opposite
corners of the frame.
c. e painter that draws a diamond shape by connect
ing the midpoints of the sides of the frame.
d. e wave painter.
28For example, the rogers painter of Figure 2.11 was constructed from a graylevel
image. For each point in a given frame, the rogers painter determines the point in the
image that is mapped to it under the frame coordinate map, and shades it accordingly.
By allowing diﬀerent types of painters, we are capitalizing on the abstract data idea
discussed in Section 2.1.3, where we argued that a rationalnumber representation could
be anything at all that satisﬁes an appropriate condition. Here we’re using the fact
that a painter can be implemented in any way at all, so long as it draws something
in the designated frame. Section 2.1.3 also showed how pairs could be implemented as
procedures. Painters are our second example of a procedural representation for data.
186
Transforming and combining painters
An operation on painters (such as flipvert or beside) works by cre
ating a painter that invokes the original painters with respect to frames
derived from the argument frame. us, for example, flipvert doesn’t
have to know how a painter works in order to ﬂip it—it just has to know
how to turn a frame upside down: e ﬂipped painter just uses the orig
inal painter, but in the inverted frame.
Painter operations are based on the procedure transformpainter,
which takes as arguments a painter and information on how to trans
form a frame and produces a new painter. e transformed painter,
when called on a frame, transforms the frame and calls the original
painter on the transformed frame. e arguments to transformpainter
are points (represented as vectors) that specify the corners of the new
frame: When mapped into the frame, the ﬁrst point speciﬁes the new
frame’s origin and the other two specify the ends of its edge vectors.
us, arguments within the unit square specify a frame contained within
the original frame.
(define (transformpainter painter origin corner1 corner2)
(lambda (frame)
(let ((m (framecoordmap frame)))
(let ((neworigin (m origin)))
(painter (makeframe
neworigin
(subvect (m corner1) neworigin)
(subvect (m corner2) neworigin)))))))
Here’s how to ﬂip painter images vertically:
(define (flipvert painter)
(transformpainter painter
(makevect 0.0 1.0)
; new origin
187
; new end of edge1
(makevect 1.0 1.0)
(makevect 0.0 0.0))) ; new end of edge2
Using transformpainter, we can easily deﬁne new transformations.
For example, we can deﬁne a painter that shrinks its image to the upper
right quarter of the frame it is given:
(define (shrinktoupperright painter)
(transformpainter
painter (makevect 0.5 0.5)
(makevect 1.0 0.5) (makevect 0.5 1.0)))
Other transformations rotate images counterclockwise by 90 degrees29
(define (rotate90 painter)
(transformpainter painter
(makevect 1.0 0.0)
(makevect 1.0 1.0)
(makevect 0.0 0.0)))
or squash images towards the center of the frame:30
(define (squashinwards painter)
(transformpainter painter
(makevect 0.0 0.0)
(makevect 0.65 0.35)
(makevect 0.35 0.65)))
Frame transformation is also the key to deﬁning means of combining
two or more painters. e beside procedure, for example, takes two
painters, transforms them to paint in the le and right halves of an
argument frame respectively, and produces a new, compound painter.
29rotate90 is a pure rotation only for square frames, because it also stretches and
shrinks the image to ﬁt into the rotated frame.
30e diamondshaped images in Figure 2.10 and Figure 2.11 were created with
squashinwards applied to wave and rogers.
188
When the compound painter is given a frame, it calls the ﬁrst trans
formed painter to paint in the le half of the frame and calls the second
transformed painter to paint in the right half of the frame:
(define (beside painter1 painter2)
(let ((splitpoint (makevect 0.5 0.0)))
(let ((paintleft
(transformpainter
painter1
(makevect 0.0 0.0)
splitpoint
(makevect 0.0 1.0)))
(paintright
(transformpainter
painter2
splitpoint
(makevect 1.0 0.0)
(makevect 0.5 1.0))))
(lambda (frame)
(paintleft frame)
(paintright frame)))))
Observe how the painter data abstraction, and in particular the repre
sentation of painters as procedures, makes beside easy to implement.
e beside procedure need not know anything about the details of the
component painters other than that each painter will draw something
in its designated frame.
Exercise 2.50: Deﬁne the transformation fliphoriz, which
ﬂips painters horizontally, and transformations that rotate
painters counterclockwise by 180 degrees and 270 degrees.
Exercise 2.51: Deﬁne the below operation for painters. below
takes two painters as arguments. e resulting painter, given
189
a frame, draws with the ﬁrst painter in the boom of the
frame and with the second painter in the top. Deﬁne below
in two diﬀerent ways—ﬁrst by writing a procedure that is
analogous to the beside procedure given above, and again
in terms of beside and suitable rotation operations (from
Exercise 2.50).
Levels of language for robust design
e picture language exercises some of the critical ideas we’ve intro
duced about abstraction with procedures and data. e fundamental
data abstractions, painters, are implemented using procedural represen
tations, which enables the language to handle diﬀerent basic drawing
capabilities in a uniform way. e means of combination satisfy the
closure property, which permits us to easily build up complex designs.
Finally, all the tools for abstracting procedures are available to us for
abstracting means of combination for painters.
We have also obtained a glimpse of another crucial idea about lan
guages and program design. is is the approach of stratiﬁed design,
the notion that a complex system should be structured as a sequence
of levels that are described using a sequence of languages. Each level is
constructed by combining parts that are regarded as primitive at that
level, and the parts constructed at each level are used as primitives at
the next level. e language used at each level of a stratiﬁed design has
primitives, means of combination, and means of abstraction appropriate
to that level of detail.
Stratiﬁed design pervades the engineering of complex systems. For
example, in computer engineering, resistors and transistors are com
bined (and described using a language of analog circuits) to produce
parts such as andgates and orgates, which form the primitives of a
190
language for digitalcircuit design.31 ese parts are combined to build
processors, bus structures, and memory systems, which are in turn com
bined to form computers, using languages appropriate to computer ar
chitecture. Computers are combined to form distributed systems, using
languages appropriate for describing network interconnections, and so
on.
As a tiny example of stratiﬁcation, our picture language uses prim
itive elements (primitive painters) that are created using a language
that speciﬁes points and lines to provide the lists of line segments for
segments>painter, or the shading details for a painter like rogers.
e bulk of our description of the picture language focused on com
bining these primitives, using geometric combiners such as beside and
below. We also worked at a higher level, regarding beside and below
as primitives to be manipulated in a language whose operations, such
as squareoffour, capture common paerns of combining geometric
combiners.
Stratiﬁed design helps make programs robust, that is, it makes it
likely that small changes in a speciﬁcation will require correspondingly
small changes in the program. For instance, suppose we wanted to change
the image based on wave shown in Figure 2.9. We could work at the
lowest level to change the detailed appearance of the wave element;
we could work at the middle level to change the way cornersplit
replicates the wave; we could work at the highest level to change how
squarelimit arranges the four copies of the corner. In general, each
level of a stratiﬁed design provides a diﬀerent vocabulary for express
ing the characteristics of the system, and a diﬀerent kind of ability to
change it.
31Section 3.3.4 describes one such language.
191
Exercise 2.52: Make changes to the square limit of wave
shown in Figure 2.9 by working at each of the levels de
scribed above. In particular:
a. Add some segments to the primitive wave painter of
Exercise 2.49 (to add a smile, for example).
b. Change the paern constructed by cornersplit (for
example, by using only one copy of the upsplit and
rightsplit images instead of two).
c. Modify the version of squarelimit that uses square
offour so as to assemble the corners in a diﬀerent
paern. (For example, you might make the big Mr.
Rogers look outward from each corner of the square.)
2.3 Symbolic Data
All the compound data objects we have used so far were constructed ul
timately from numbers. In this section we extend the representational
capability of our language by introducing the ability to work with arbi
trary symbols as data.
2.3.1 otation
If we can form compound data using symbols, we can have lists such as
(a b c d)
(23 45 17)
((Norah 12) (Molly 9) (Anna 7) (Lauren 6) (Charlotte 4))
Lists containing symbols can look just like the expressions of our lan
guage:
192
(* (+ 23 45)
(+ x 9))
(define (fact n)
(if (= n 1) 1 (* n (fact ( n 1)))))
In order to manipulate symbols we need a new element in our language:
the ability to quote a data object. Suppose we want to construct the list
(a b). We can’t accomplish this with (list a b), because this expres
sion constructs a list of the values of a and b rather than the symbols
themselves. is issue is well known in the context of natural languages,
where words and sentences may be regarded either as semantic entities
or as character strings (syntactic entities). e common practice in nat
ural languages is to use quotation marks to indicate that a word or a
sentence is to be treated literally as a string of characters. For instance,
the ﬁrst leer of “John” is clearly “J.” If we tell somebody “say your
name aloud,” we expect to hear that person’s name. However, if we tell
somebody “say ‘your name’ aloud,” we expect to hear the words “your
name.” Note that we are forced to nest quotation marks to describe what
somebody else might say.32
We can follow this same practice to identify lists and symbols that
are to be treated as data objects rather than as expressions to be evalu
32Allowing quotation in a language wreaks havoc with the ability to reason about
the language in simple terms, because it destroys the notion that equals can be sub
stituted for equals. For example, three is one plus two, but the word “three” is not the
phrase “one plus two.” otation is powerful because it gives us a way to build expres
sions that manipulate other expressions (as we will see when we write an interpreter in
Chapter 4). But allowing statements in a language that talk about other statements in
that language makes it very diﬃcult to maintain any coherent principle of what “equals
can be substituted for equals” should mean. For example, if we know that the evening
star is the morning star, then from the statement “the evening star is Venus” we can
deduce “the morning star is Venus.” However, given that “John knows that the evening
star is Venus” we cannot infer that “John knows that the morning star is Venus.”
193
ated. However, our format for quoting diﬀers from that of natural lan
guages in that we place a quotation mark (traditionally, the single quote
symbol ') only at the beginning of the object to be quoted. We can get
away with this in Scheme syntax because we rely on blanks and paren
theses to delimit objects. us, the meaning of the single quote character
is to quote the next object.33
Now we can distinguish between symbols and their values:
(define a 1)
(define b 2)
(list a b)
(1 2)
(list 'a 'b)
(a b)
(list 'a b)
(a 2)
otation also allows us to type in compound objects, using the con
ventional printed representation for lists:34
33e single quote is diﬀerent from the double quote we have been using to enclose
character strings to be printed. Whereas the single quote can be used to denote lists or
symbols, the double quote is used only with character strings. In this book, the only
use for character strings is as items to be printed.
34Strictly, our use of the quotation mark violates the general rule that all compound
expressions in our language should be delimited by parentheses and look like lists. We
can recover this consistency by introducing a special form quote, which serves the
same purpose as the quotation mark. us, we would type (quote a) instead of 'a,
and we would type (quote (a b c)) instead of '(a b c). is is precisely how
the interpreter works. e quotation mark is just a singlecharacter abbreviation for
wrapping the next complete expression with quote to form (quote ⟨expression⟩).
is is important because it maintains the principle that any expression seen by the
interpreter can be manipulated as a data object. For instance, we could construct the
expression (car '(a b c)), which is the same as (car (quote (a b c))), by evaluating
(list 'car (list 'quote '(a b c))).
194
(car '(a b c))
a
(cdr '(a b c))
(b c)
In keeping with this, we can obtain the empty list by evaluating '(),
and thus dispense with the variable nil.
One additional primitive used in manipulating symbols is eq?, which
takes two symbols as arguments and tests whether they are the same.35
Using eq?, we can implement a useful procedure called memq. is takes
two arguments, a symbol and a list. If the symbol is not contained in the
list (i.e., is not eq? to any item in the list), then memq returns false. Other
wise, it returns the sublist of the list beginning with the ﬁrst occurrence
of the symbol:
(define (memq item x)
(cond ((null? x) false)
((eq? item (car x)) x)
(else (memq item (cdr x)))))
For example, the value of
(memq 'apple '(pear banana prune))
is false, whereas the value of
(memq 'apple '(x (apple sauce) y apple pear))
is (apple pear).
Exercise 2.53: What would the interpreter print in response
to evaluating each of the following expressions?
35We can consider two symbols to be “the same” if they consist of the same characters
in the same order. Such a deﬁnition skirts a deep issue that we are not yet ready to
address: the meaning of “sameness” in a programming language. We will return to this
in Chapter 3 (Section 3.1.3).
195
(list 'a 'b 'c)
(list (list 'george))
(cdr '((x1 x2) (y1 y2)))
(cadr '((x1 x2) (y1 y2)))
(pair? (car '(a short list)))
(memq 'red '((red shoes) (blue socks)))
(memq 'red '(red shoes blue socks))
Exercise 2.54: Two lists are said to be equal? if they con
tain equal elements arranged in the same order. For exam
ple,
(equal? '(this is a list) '(this is a list))
is true, but
(equal? '(this is a list) '(this (is a) list))
is false. To be more precise, we can deﬁne equal? recur
sively in terms of the basic eq? equality of symbols by say
ing that a and b are equal? if they are both symbols and
the symbols are eq?, or if they are both lists such that (car
a) is equal? to (car b) and (cdr a) is equal? to (cdr b).
Using this idea, implement equal? as a procedure.36
Exercise 2.55: Eva Lu Ator types to the interpreter the ex
pression
36In practice, programmers use equal? to compare lists that contain numbers as
well as symbols. Numbers are not considered to be symbols. e question of whether
two numerically equal numbers (as tested by =) are also eq? is highly implementation
dependent. A beer deﬁnition of equal? (such as the one that comes as a primitive in
Scheme) would also stipulate that if a and b are both numbers, then a and b are equal?
if they are numerically equal.
196
(car ''abracadabra)
To her surprise, the interpreter prints back quote. Explain.
2.3.2 Example: Symbolic Diﬀerentiation
As an illustration of symbol manipulation and a further illustration of
data abstraction, consider the design of a procedure that performs sym
bolic diﬀerentiation of algebraic expressions. We would like the proce
dure to take as arguments an algebraic expression and a variable and to
return the derivative of the expression with respect to the variable. For
example, if the arguments to the procedure are ax 2 + bx + c and x, the
procedure should return 2ax + b. Symbolic diﬀerentiation is of special
historical signiﬁcance in Lisp. It was one of the motivating examples
behind the development of a computer language for symbol manipula
tion. Furthermore, it marked the beginning of the line of research that
led to the development of powerful systems for symbolic mathematical
work, which are currently being used by a growing number of applied
mathematicians and physicists.
In developing the symbolicdiﬀerentiation program, we will follow
the same strategy of data abstraction that we followed in developing
the rationalnumber system of Section 2.1.1. at is, we will ﬁrst de
ﬁne a diﬀerentiation algorithm that operates on abstract objects such as
“sums,” “products,” and “variables” without worrying about how these
are to be represented. Only aerward will we address the representation
problem.
The diﬀerentiation program with abstract data
In order to keep things simple, we will consider a very simple symbolic
diﬀerentiation program that handles expressions that are built up using
197
only the operations of addition and multiplication with two arguments.
Diﬀerentiation of any such expression can be carried out by applying
the following reduction rules:
dc
dx
= 0;
for c a constant or a variable different from x ;
dx
dx
d (u + v )
dx
d (uv )
dx
= 1;
= du
dx
dv
dx
= u
+ v
+
dv
dx
du
dx
;
:
Observe that the laer two rules are recursive in nature. at is, to ob
tain the derivative of a sum we ﬁrst ﬁnd the derivatives of the terms and
add them. Each of the terms may in turn be an expression that needs
to be decomposed. Decomposing into smaller and smaller pieces will
eventually produce pieces that are either constants or variables, whose
derivatives will be either 0 or 1.
To embody these rules in a procedure we indulge in a lile wishful
thinking, as we did in designing the rationalnumber implementation.
If we had a means for representing algebraic expressions, we should
be able to tell whether an expression is a sum, a product, a constant,
or a variable. We should be able to extract the parts of an expression.
For a sum, for example we want to be able to extract the addend (ﬁrst
term) and the augend (second term). We should also be able to construct
expressions from parts. Let us assume that we already have procedures
to implement the following selectors, constructors, and predicates:
(variable? e)
(samevariable? v1 v2)
Is e a variable?
Are v1 and v2 the same variable?
198
(sum? e)
(addend e)
(augend e)
(makesum a1 a2)
(product? e)
(multiplier e)
(multiplicand e)
(makeproduct m1 m2)
Is e a sum?
Addend of the sum e.
Augend of the sum e.
Construct the sum of a1 and a2.
Is e a product?
Multiplier of the product e.
Multiplicand of the product e.
Construct the product of m1 and m2.
Using these, and the primitive predicate number?, which identiﬁes num
bers, we can express the diﬀerentiation rules as the following procedure:
(define (deriv exp var)
(cond ((number? exp) 0)
((variable? exp) (if (samevariable? exp var) 1 0))
((sum? exp) (makesum (deriv (addend exp) var)
(deriv (augend exp) var)))
((product? exp)
(makesum
(makeproduct (multiplier exp)
(deriv (multiplicand exp) var))
(makeproduct (deriv (multiplier exp) var)
(multiplicand exp))))
(else
(error "unknown expression type: DERIV" exp))))
is deriv procedure incorporates the complete diﬀerentiation algo
rithm. Since it is expressed in terms of abstract data, it will work no
maer how we choose to represent algebraic expressions, as long as we
design a proper set of selectors and constructors. is is the issue we
must address next.
199
Representing algebraic expressions
We can imagine many ways to use list structure to represent algebraic
expressions. For example, we could use lists of symbols that mirror
the usual algebraic notation, representing ax + b as the list (a * x +
b). However, one especially straightforward choice is to use the same
parenthesized preﬁx notation that Lisp uses for combinations; that is,
to represent ax + b as (+ (* a x) b). en our data representation for
the diﬀerentiation problem is as follows:
• e variables are symbols. ey are identiﬁed by the primitive
predicate symbol?:
(define (variable? x) (symbol? x))
• Two variables are the same if the symbols representing them are
eq?:
(define (samevariable? v1 v2)
(and (variable? v1) (variable? v2) (eq? v1 v2)))
• Sums and products are constructed as lists:
(define (makesum a1 a2) (list '+ a1 a2))
(define (makeproduct m1 m2) (list '* m1 m2))
• A sum is a list whose ﬁrst element is the symbol +:
(define (sum? x) (and (pair? x) (eq? (car x) '+)))
• e addend is the second item of the sum list:
(define (addend s) (cadr s))
200
• e augend is the third item of the sum list:
(define (augend s) (caddr s))
• A product is a list whose ﬁrst element is the symbol *:
(define (product? x) (and (pair? x) (eq? (car x) '*)))
• e multiplier is the second item of the product list:
(define (multiplier p) (cadr p))
• e multiplicand is the third item of the product list:
(define (multiplicand p) (caddr p))
us, we need only combine these with the algorithm as embodied by
deriv in order to have a working symbolicdiﬀerentiation program. Let
us look at some examples of its behavior:
(deriv '(+ x 3) 'x)
(+ 1 0)
(deriv '(* x y) 'x)
(+ (* x 0) (* 1 y))
(deriv '(* (* x y) (+ x 3)) 'x)
(+ (* (* x y) (+ 1 0))
(* (+ (* x 0) (* 1 y))
(+ x 3)))
e program produces answers that are correct; however, they are un
simpliﬁed. It is true that
d (xy )
dx
= x (cid:1) 0 + 1 (cid:1) y;
201
but we would like the program to know that x (cid:1) 0 = 0, 1 (cid:1) y = y, and
0 + y = y. e answer for the second example should have been simply
y. As the third example shows, this becomes a serious issue when the
expressions are complex.
Our diﬃculty is much like the one we encountered with the rational
number implementation: we haven’t reduced answers to simplest form.
To accomplish the rationalnumber reduction, we needed to change only
the constructors and the selectors of the implementation. We can adopt
a similar strategy here. We won’t change deriv at all. Instead, we will
change makesum so that if both summands are numbers, makesum will
add them and return their sum. Also, if one of the summands is 0, then
makesum will return the other summand.
(define (makesum a1 a2)
(cond ((=number? a1 0) a2)
((=number? a2 0) a1)
((and (number? a1) (number? a2))
(+ a1 a2))
(else (list '+ a1 a2))))
is uses the procedure =number?, which checks whether an expression
is equal to a given number:
(define (=number? exp num) (and (number? exp) (= exp num)))
Similarly, we will change makeproduct to build in the rules that 0 times
anything is 0 and 1 times anything is the thing itself:
(define (makeproduct m1 m2)
(cond ((or (=number? m1 0) (=number? m2 0)) 0)
((=number? m1 1) m2)
((=number? m2 1) m1)
((and (number? m1) (number? m2)) (* m1 m2))
(else (list '* m1 m2))))
202
Here is how this version works on our three examples:
(deriv '(+ x 3) 'x)
1
(deriv '(* x y) 'x)
y
(deriv '(* (* x y) (+ x 3)) 'x)
(+ (* x y) (* y (+ x 3)))
Although this is quite an improvement, the third example shows that
there is still a long way to go before we get a program that puts ex
pressions into a form that we might agree is “simplest.” e problem
of algebraic simpliﬁcation is complex because, among other reasons, a
form that may be simplest for one purpose may not be for another.
Exercise 2.56: Show how to extend the basic diﬀerentiator
to handle more kinds of expressions. For instance, imple
ment the diﬀerentiation rule
d (un )
dx
= nun(cid:0)1 du
dx
by adding a new clause to the deriv program and deﬁning
appropriate procedures exponentiation?, base, exponent,
and makeexponentiation. (You may use the symbol **
to denote exponentiation.) Build in the rules that anything
raised to the power 0 is 1 and anything raised to the power
1 is the thing itself.
Exercise 2.57: Extend the diﬀerentiation program to han
dle sums and products of arbitrary numbers of (two or more)
terms. en the last example above could be expressed as
(deriv '(* x y (+ x 3)) 'x)
203
Try to do this by changing only the representation for sums
and products, without changing the deriv procedure at all.
For example, the addend of a sum would be the ﬁrst term,
and the augend would be the sum of the rest of the terms.
Exercise 2.58: Suppose we want to modify the diﬀerentia
tion program so that it works with ordinary mathematical
notation, in which + and * are inﬁx rather than preﬁx opera
tors. Since the diﬀerentiation program is deﬁned in terms of
abstract data, we can modify it to work with diﬀerent repre
sentations of expressions solely by changing the predicates,
selectors, and constructors that deﬁne the representation of
the algebraic expressions on which the diﬀerentiator is to
operate.
a. Show how to do this in order to diﬀerentiate algebraic
expressions presented in inﬁx form, such as (x + (3
* (x + (y + 2)))). To simplify the task, assume that
+ and * always take two arguments and that expres
sions are fully parenthesized.
b. e problem becomes substantially harder if we allow
standard algebraic notation, such as (x + 3 * (x +
y + 2)), which drops unnecessary parentheses and
assumes that multiplication is done before addition.
Can you design appropriate predicates, selectors, and
constructors for this notation such that our derivative
program still works?
204
2.3.3 Example: Representing Sets
In the previous examples we built representations for two kinds of com
pound data objects: rational numbers and algebraic expressions. In one
of these examples we had the choice of simplifying (reducing) the ex
pressions at either construction time or selection time, but other than
that the choice of a representation for these structures in terms of lists
was straightforward. When we turn to the representation of sets, the
choice of a representation is not so obvious. Indeed, there are a num
ber of possible representations, and they diﬀer signiﬁcantly from one
another in several ways.
Informally, a set is simply a collection of distinct objects. To give
a more precise deﬁnition we can employ the method of data abstrac
tion. at is, we deﬁne “set” by specifying the operations that are to be
used on sets. ese are unionset, intersectionset, elementof
set?, and adjoinset. elementofset? is a predicate that determines
whether a given element is a member of a set. adjoinset takes an ob
ject and a set as arguments and returns a set that contains the elements
of the original set and also the adjoined element. unionset computes
the union of two sets, which is the set containing each element that
appears in either argument. intersectionset computes the intersec
tion of two sets, which is the set containing only elements that appear
in both arguments. From the viewpoint of data abstraction, we are free
to design any representation that implements these operations in a way
consistent with the interpretations given above.37
37If we want to be more formal, we can specify “consistent with the interpretations
given above” to mean that the operations satisfy a collection of rules such as these:
(cid:15) For any set S and any object x, (elementofset? x (adjoinset x S)) is true
(informally: “Adjoining an object to a set produces a set that contains the object”).
(cid:15) For any sets S and T and any object x, (elementofset? x (unionset S T)) is
205
Sets as unordered lists
One way to represent a set is as a list of its elements in which no el
ement appears more than once. e empty set is represented by the
empty list. In this representation, elementofset? is similar to the
procedure memq of Section 2.3.1. It uses equal? instead of eq? so that
the set elements need not be symbols:
(define (elementofset? x set)
(cond ((null? set) false)
((equal? x (car set)) true)
(else (elementofset? x (cdr set)))))
Using this, we can write adjoinset. If the object to be adjoined is al
ready in the set, we just return the set. Otherwise, we use cons to add
the object to the list that represents the set:
(define (adjoinset x set)
(if (elementofset? x set)
set
(cons x set)))
For intersectionset we can use a recursive strategy. If we know how
to form the intersection of set2 and the cdr of set1, we only need to
decide whether to include the car of set1 in this. But this depends on
whether (car set1) is also in set2. Here is the resulting procedure:
(define (intersectionset set1 set2)
(cond ((or (null? set1) (null? set2)) '())
((elementofset? (car set1) set2)
(cons (car set1) (intersectionset (cdr set1) set2)))
(else (intersectionset (cdr set1) set2))))
equal to (or (elementofset? x S) (elementofset? x T)) (informally: “e
elements of (union S T) are the elements that are in S or in T”).
(cid:15) For any object x, (elementofset? x '()) is false (informally: “No object is an
element of the empty set”).
206
In designing a representation, one of the issues we should be concerned
with is eﬃciency. Consider the number of steps required by our set
operations. Since they all use elementofset?, the speed of this oper
ation has a major impact on the eﬃciency of the set implementation as
a whole. Now, in order to check whether an object is a member of a set,
elementofset? may have to scan the entire set. (In the worst case,
the object turns out not to be in the set.) Hence, if the set has n elements,
elementofset? might take up to n steps. us, the number of steps
required grows as Θ(n). e number of steps required by adjoinset,
which uses this operation, also grows as Θ(n). For intersectionset,
which does an elementofset? check for each element of set1, the
number of steps required grows as the product of the sizes of the sets
involved, or Θ(n2) for two sets of size n. e same will be true of union
set.
Exercise 2.59: Implement the unionset operation for the
unorderedlist representation of sets.
Exercise 2.60: We speciﬁed that a set would be represented
as a list with no duplicates. Now suppose we allow dupli
cates. For instance, the set {1; 2; 3} could be represented as
the list (2 3 2 1 3 2 2). Design procedures element
ofset?, adjoinset, unionset, and intersectionset
that operate on this representation. How does the eﬃciency
of each compare with the corresponding procedure for the
nonduplicate representation? Are there applications for which
you would use this representation in preference to the non
duplicate one?
207
Sets as ordered lists
One way to speed up our set operations is to change the representation
so that the set elements are listed in increasing order. To do this, we
need some way to compare two objects so that we can say which is
bigger. For example, we could compare symbols lexicographically, or
we could agree on some method for assigning a unique number to an
object and then compare the elements by comparing the corresponding
numbers. To keep our discussion simple, we will consider only the case
where the set elements are numbers, so that we can compare elements
using > and <. We will represent a set of numbers by listing its elements
in increasing order. Whereas our ﬁrst representation above allowed us
to represent the set {1; 3; 6; 10} by listing the elements in any order, our
new representation allows only the list (1 3 6 10).
One advantage of ordering shows up in elementofset?: In check
ing for the presence of an item, we no longer have to scan the entire set.
If we reach a set element that is larger than the item we are looking for,
then we know that the item is not in the set:
(define (elementofset? x set)
(cond ((null? set) false)
((= x (car set)) true)
((< x (car set)) false)
(else (elementofset? x (cdr set)))))
How many steps does this save? In the worst case, the item we are
looking for may be the largest one in the set, so the number of steps
is the same as for the unordered representation. On the other hand, if
we search for items of many diﬀerent sizes we can expect that some
times we will be able to stop searching at a point near the beginning of
the list and that other times we will still need to examine most of the
list. On the average we should expect to have to examine about half of
208
the items in the set. us, the average number of steps required will be
about n=2. is is still Θ(n) growth, but it does save us, on the average,
a factor of 2 in number of steps over the previous implementation.
We obtain a more impressive speedup with intersectionset. In
the unordered representation this operation required Θ(n2) steps, be
cause we performed a complete scan of set2 for each element of set1.
But with the ordered representation, we can use a more clever method.
Begin by comparing the initial elements, x1 and x2, of the two sets. If
x1 equals x2, then that gives an element of the intersection, and the rest
of the intersection is the intersection of the cdrs of the two sets. Sup
pose, however, that x1 is less than x2. Since x2 is the smallest element
in set2, we can immediately conclude that x1 cannot appear anywhere
in set2 and hence is not in the intersection. Hence, the intersection is
equal to the intersection of set2 with the cdr of set1. Similarly, if x2
is less than x1, then the intersection is given by the intersection of set1
with the cdr of set2. Here is the procedure:
(define (intersectionset set1 set2)
(if (or (null? set1) (null? set2))
'()
(let ((x1 (car set1)) (x2 (car set2)))
(cond ((= x1 x2)
(cons x1 (intersectionset (cdr set1)
(cdr set2))))
((< x1 x2)
(intersectionset (cdr set1) set2))
((< x2 x1)
(intersectionset set1 (cdr set2)))))))
To estimate the number of steps required by this process, observe that
at each step we reduce the intersection problem to computing inter
sections of smaller sets—removing the ﬁrst element from set1 or set2
209
or both. us, the number of steps required is at most the sum of the
sizes of set1 and set2, rather than the product of the sizes as with the
unordered representation. is is Θ(n) growth rather than Θ(n2)—a con
siderable speedup, even for sets of moderate size.
Exercise 2.61: Give an implementation of adjoinset us
ing the ordered representation. By analogy with element
ofset? show how to take advantage of the ordering to
produce a procedure that requires on the average about half
as many steps as with the unordered representation.
Exercise 2.62: Give a Θ(n) implementation of unionset
for sets represented as ordered lists.
Sets as binary trees
We can do beer than the orderedlist representation by arranging the
set elements in the form of a tree. Each node of the tree holds one ele
ment of the set, called the “entry” at that node, and a link to each of two
other (possibly empty) nodes. e “le” link points to elements smaller
than the one at the node, and the “right” link to elements greater than
the one at the node. Figure 2.16 shows some trees that represent the set
{1; 3; 5; 7; 9; 11}. e same set may be represented by a tree in a number
of diﬀerent ways. e only thing we require for a valid representation
is that all elements in the le subtree be smaller than the node entry
and that all elements in the right subtree be larger.
e advantage of the tree representation is this: Suppose we want to
check whether a number x is contained in a set. We begin by comparing
x with the entry in the top node. If x is less than this, we know that we
need only search the le subtree; if x is greater, we need only search
the right subtree. Now, if the tree is “balanced,” each of these subtrees
210
Figure 2.16: Various binary trees that represent the set
{1; 3; 5; 7; 9; 11}.
will be about half the size of the original. us, in one step we have
reduced the problem of searching a tree of size n to searching a tree
of size n=2. Since the size of the tree is halved at each step, we should
expect that the number of steps needed to search a tree of size n grows
as Θ(logn).38 For large sets, this will be a signiﬁcant speedup over the
previous representations.
We can represent trees by using lists. Each node will be a list of three
items: the entry at the node, the le subtree, and the right subtree. A le
or a right subtree of the empty list will indicate that there is no subtree
connected there. We can describe this representation by the following
procedures:39
38Halving the size of the problem at each step is the distinguishing characteristic of
logarithmic growth, as we saw with the fastexponentiation algorithm of Section 1.2.4
and the halfinterval search method of Section 1.3.3.
39We are representing sets in terms of trees, and trees in terms of lists—in eﬀect, a
data abstraction built upon a data abstraction. We can regard the procedures entry,
leftbranch, rightbranch, and maketree as a way of isolating the abstraction of a
“binary tree” from the particular way we might wish to represent such a tree in terms
of list structure.
211
735391793111591711115(define (entry tree) (car tree))
(define (leftbranch tree) (cadr tree))
(define (rightbranch tree) (caddr tree))
(define (maketree entry left right)
(list entry left right))
Now we can write the elementofset? procedure using the strategy
described above:
(define (elementofset? x set)
(cond ((null? set) false)
((= x (entry set)) true)
((< x (entry set))
(elementofset? x (leftbranch set)))
((> x (entry set))
(elementofset? x (rightbranch set)))))
Adjoining an item to a set is implemented similarly and also requires
Θ(logn) steps. To adjoin an item x, we compare x with the node en
try to determine whether x should be added to the right or to the le
branch, and having adjoined x to the appropriate branch we piece this
newly constructed branch together with the original entry and the other
branch. If x is equal to the entry, we just return the node. If we are asked
to adjoin x to an empty tree, we generate a tree that has x as the entry
and empty right and le branches. Here is the procedure:
(define (adjoinset x set)
(cond ((null? set) (maketree x '() '()))
((= x (entry set)) set)
((< x (entry set))
(maketree (entry set)
(adjoinset x (leftbranch set))
(rightbranch set)))
((> x (entry set))
212
(maketree (entry set) (leftbranch set)
(adjoinset x (rightbranch set))))))
e above claim that searching the tree can be performed in a logarith
mic number of steps rests on the assumption that the tree is “balanced,”
i.e., that the le and the right subtree of every tree have approximately
the same number of elements, so that each subtree contains about half
the elements of its parent. But how can we be certain that the trees we
construct will be balanced? Even if we start with a balanced tree, adding
elements with adjoinset may produce an unbalanced result. Since the
position of a newly adjoined element depends on how the element com
pares with the items already in the set, we can expect that if we add ele
ments “randomly” the tree will tend to be balanced on the average. But
this is not a guarantee. For example, if we start with an empty set and
adjoin the numbers 1 through 7 in sequence we end up with the highly
unbalanced tree shown in Figure 2.17. In this tree all the le subtrees
are empty, so it has no advantage over a simple ordered list. One way to
solve this problem is to deﬁne an operation that transforms an arbitrary
tree into a balanced tree with the same elements. en we can perform
this transformation aer every few adjoinset operations to keep our
set in balance. ere are also other ways to solve this problem, most of
which involve designing new data structures for which searching and
insertion both can be done in Θ(logn) steps.40
Exercise 2.63: Each of the following two procedures con
verts a binary tree to a list.
(define (tree>list1 tree)
(if (null? tree)
40Examples of such structures include Btrees and redblack trees. ere is a large
literature on data structures devoted to this problem. See Cormen et al. 1990.
213
Figure 2.17: Unbalanced tree produced by adjoining 1
through 7 in sequence.
'()
(append (tree>list1 (leftbranch tree))
(cons (entry tree)
(tree>list1
(rightbranch tree))))))
(define (tree>list2 tree)
(define (copytolist tree resultlist)
(if (null? tree)
resultlist
(copytolist (leftbranch tree)
(cons (entry tree)
(copytolist
(copytolist tree '()))
(rightbranch tree)
resultlist)))))
a. Do the two procedures produce the same result for
every tree? If not, how do the results diﬀer? What lists
214
1234567do the two procedures produce for the trees in Figure
2.16?
b. Do the two procedures have the same order of growth
in the number of steps required to convert a balanced
tree with n elements to a list? If not, which one grows
more slowly?
Exercise 2.64: e following procedure list>tree con
verts an ordered list to a balanced binary tree. e helper
procedure partialtree takes as arguments an integer n
and list of at least n elements and constructs a balanced
tree containing the ﬁrst n elements of the list. e result re
turned by partialtree is a pair (formed with cons) whose
car is the constructed tree and whose cdr is the list of ele
ments not included in the tree.
(define (list>tree elements)
(car (partialtree elements (length elements))))
(define (partialtree elts n)
(if (= n 0)
(cons '() elts)
(let ((leftsize (quotient ( n 1) 2)))
(let ((leftresult
(partialtree elts leftsize)))
(let ((lefttree (car leftresult))
(nonleftelts (cdr leftresult))
(rightsize ( n (+ leftsize 1))))
(let ((thisentry (car nonleftelts))
(rightresult
(partialtree
(cdr nonleftelts)
rightsize)))
215
(let ((righttree (car rightresult))
(remainingelts
(cdr rightresult)))
(cons (maketree thisentry
lefttree
righttree)
remainingelts))))))))
a. Write a short paragraph explaining as clearly as you
can how partialtree works. Draw the tree produced
by list>tree for the list (1 3 5 7 9 11).
b. What is the order of growth in the number of steps re
quired by list>tree to convert a list of n elements?
Exercise 2.65: Use the results of Exercise 2.63 and Exer
cise 2.64 to give Θ(n) implementations of unionset and
intersectionset for sets implemented as (balanced) bi
nary trees.41
Sets and information retrieval
We have examined options for using lists to represent sets and have
seen how the choice of representation for a data object can have a large
impact on the performance of the programs that use the data. Another
reason for concentrating on sets is that the techniques discussed here
appear again and again in applications involving information retrieval.
Consider a data base containing a large number of individual records,
such as the personnel ﬁles for a company or the transactions in an ac
counting system. A typical datamanagement system spends a large
41Exercise 2.63 through Exercise 2.65 are due to Paul Hilﬁnger.
216
amount of time accessing or modifying the data in the records and
therefore requires an eﬃcient method for accessing records. is is done
by identifying a part of each record to serve as an identifying key. A
key can be anything that uniquely identiﬁes the record. For a personnel
ﬁle, it might be an employee’s number. For an accounting system, it
might be a transaction number. Whatever the key is, when we deﬁne the
record as a data structure we should include a key selector procedure
that retrieves the key associated with a given record.
Now we represent the data base as a set of records. To locate the
record with a given key we use a procedure lookup, which takes as
arguments a key and a data base and which returns the record that has
that key, or false if there is no such record. lookup is implemented in
almost the same way as elementofset?. For example, if the set of
records is implemented as an unordered list, we could use
(define (lookup givenkey setofrecords)
(cond ((null? setofrecords) false)
((equal? givenkey (key (car setofrecords)))
(car setofrecords))
(else (lookup givenkey (cdr setofrecords)))))
Of course, there are beer ways to represent large sets than as un
ordered lists. Informationretrieval systems in which records have to be
“randomly accessed” are typically implemented by a treebased method,
such as the binarytree representation discussed previously. In design
ing such a system the methodology of data abstraction can be a great
help. e designer can create an initial implementation using a sim
ple, straightforward representation such as unordered lists. is will be
unsuitable for the eventual system, but it can be useful in providing a
“quick and dirty” data base with which to test the rest of the system.
Later on, the data representation can be modiﬁed to be more sophisti
217
cated. If the data base is accessed in terms of abstract selectors and con
structors, this change in representation will not require any changes to
the rest of the system.
Exercise 2.66: Implement the lookup procedure for the case
where the set of records is structured as a binary tree, or
dered by the numerical values of the keys.
2.3.4 Example: Huﬀman Encoding Trees
is section provides practice in the use of list structure and data ab
straction to manipulate sets and trees. e application is to methods for
representing data as sequences of ones and zeros (bits). For example,
the standard code used to represent text in computers encodes
each character as a sequence of seven bits. Using seven bits allows us
to distinguish 27, or 128, possible diﬀerent characters. In general, if we
want to distinguish n diﬀerent symbols, we will need to use log2n bits
per symbol. If all our messages are made up of the eight symbols A, B,
C, D, E, F, G, and H, we can choose a code with three bits per character,
for example
A 000
B 001
C 010
D 011
E 100
F 101
G 110
H 111
With this code, the message
BACADAEAFABBAAAGAH
is encoded as the string of 54 bits
001000010000011000100000101000001001000000000110000111
218
Codes such as and the AthroughH code above are known as
ﬁxedlength codes, because they represent each symbol in the message
with the same number of bits. It is sometimes advantageous to use variable
length codes, in which diﬀerent symbols may be represented by diﬀer
ent numbers of bits. For example, Morse code does not use the same
number of dots and dashes for each leer of the alphabet. In particular,
E, the most frequent leer, is represented by a single dot. In general, if
our messages are such that some symbols appear very frequently and
some very rarely, we can encode data more eﬃciently (i.e., using fewer
bits per message) if we assign shorter codes to the frequent symbols.
Consider the following alternative code for the leers A through H:
A 0
B 100
C 1010
D 1011
E 1100
F 1101
G 1110
H 1111
With this code, the same message as above is encoded as the string
100010100101101100011010100100000111001111
is string contains 42 bits, so it saves more than 20% in space in com
parison with the ﬁxedlength code shown above.
One of the diﬃculties of using a variablelength code is knowing
when you have reached the end of a symbol in reading a sequence of
zeros and ones. Morse code solves this problem by using a special sep
arator code (in this case, a pause) aer the sequence of dots and dashes
for each leer. Another solution is to design the code in such a way that
no complete code for any symbol is the beginning (or preﬁx) of the code
for another symbol. Such a code is called a preﬁx code. In the example
above, A is encoded by 0 and B is encoded by 100, so no other symbol
can have a code that begins with 0 or with 100.
219
In general, we can aain signiﬁcant savings if we use variablelength
preﬁx codes that take advantage of the relative frequencies of the sym
bols in the messages to be encoded. One particular scheme for doing
this is called the Huﬀman encoding method, aer its discoverer, David
Huﬀman. A Huﬀman code can be represented as a binary tree whose
leaves are the symbols that are encoded. At each nonleaf node of the
tree there is a set containing all the symbols in the leaves that lie below
the node. In addition, each symbol at a leaf is assigned a weight (which
is its relative frequency), and each nonleaf node contains a weight that
is the sum of all the weights of the leaves lying below it. e weights
are not used in the encoding or the decoding process. We will see below
how they are used to help construct the tree.
Figure 2.18 shows the Huﬀman tree for the AthroughH code given
above. e weights at the leaves indicate that the tree was designed for
messages in which A appears with relative frequency 8, B with relative
frequency 3, and the other leers each with relative frequency 1.
Given a Huﬀman tree, we can ﬁnd the encoding of any symbol by
starting at the root and moving down until we reach the leaf that holds
the symbol. Each time we move down a le branch we add a 0 to the
code, and each time we move down a right branch we add a 1. (We
decide which branch to follow by testing to see which branch either
is the leaf node for the symbol or contains the symbol in its set.) For
example, starting from the root of the tree in Figure 2.18, we arrive at
the leaf for D by following a right branch, then a le branch, then a right
branch, then a right branch; hence, the code for D is 1011.
To decode a bit sequence using a Huﬀman tree, we begin at the root
and use the successive zeros and ones of the bit sequence to determine
whether to move down the le or the right branch. Each time we come
to a leaf, we have generated a new symbol in the message, at which
220
Figure 2.18: A Huﬀman encoding tree.
point we start over from the root of the tree to ﬁnd the next symbol.
For example, suppose we are given the tree above and the sequence
10001010. Starting at the root, we move down the right branch, (since
the ﬁrst bit of the string is 1), then down the le branch (since the second
bit is 0), then down the le branch (since the third bit is also 0). is
brings us to the leaf for B, so the ﬁrst symbol of the decoded message is
B. Now we start again at the root, and we make a le move because the
next bit in the string is 0. is brings us to the leaf for A. en we start
again at the root with the rest of the string 1010, so we move right, le,
right, le and reach C. us, the entire message is BAC.
Generating Huﬀman trees
Given an “alphabet” of symbols and their relative frequencies, how do
we construct the “best” code? (In other words, which tree will encode
messages with the fewest bits?) Huﬀman gave an algorithm for doing
221
{A B C D E F G H} 17{B C D E F G H} 9A 8{B C D} 5{C D} 2D 1C 1B 3{E F G H} 4{G H} 2{E F} 2E 1F 1H 1G 1this and showed that the resulting code is indeed the best variable
length code for messages where the relative frequency of the symbols
matches the frequencies with which the code was constructed. We will
not prove this optimality of Huﬀman codes here, but we will show how
Huﬀman trees are constructed.42
e algorithm for generating a Huﬀman tree is very simple. e idea
is to arrange the tree so that the symbols with the lowest frequency
appear farthest away from the root. Begin with the set of leaf nodes,
containing symbols and their frequencies, as determined by the initial
data from which the code is to be constructed. Now ﬁnd two leaves with
the lowest weights and merge them to produce a node that has these
two nodes as its le and right branches. e weight of the new node is
the sum of the two weights. Remove the two leaves from the original
set and replace them by this new node. Now continue this process. At
each step, merge two nodes with the smallest weights, removing them
from the set and replacing them with a node that has these two as its
le and right branches. e process stops when there is only one node
le, which is the root of the entire tree. Here is how the Huﬀman tree
of Figure 2.18 was generated:
Initial leaves {(A 8) (B 3) (C 1) (D 1) (E 1) (F 1) (G 1) (H 1)}
Merge {(A 8) (B 3) ({C D} 2) (E 1) (F 1) (G 1) (H 1)}
Merge {(A 8) (B 3) ({C D} 2) ({E F} 2) (G 1) (H 1)}
Merge {(A 8) (B 3) ({C D} 2) ({E F} 2) ({G H} 2)}
Merge {(A 8) (B 3) ({C D} 2) ({E F G H} 4)}
Merge {(A 8) ({B C D} 5) ({E F G H} 4)}
Merge {(A 8) ({B C D E F G H} 9)}
Final merge
{({A B C D E F G H} 17)}
42See Hamming 1980 for a discussion of the mathematical properties of Huﬀman
codes.
222
e algorithm does not always specify a unique tree, because there may
not be unique smallestweight nodes at each step. Also, the choice of the
order in which the two nodes are merged (i.e., which will be the right
branch and which will be the le branch) is arbitrary.
Representing Huﬀman trees
In the exercises below we will work with a system that uses Huﬀman
trees to encode and decode messages and generates Huﬀman trees ac
cording to the algorithm outlined above. We will begin by discussing
how trees are represented.
Leaves of the tree are represented by a list consisting of the symbol
leaf, the symbol at the leaf, and the weight:
(define (makeleaf symbol weight) (list 'leaf symbol weight))
(define (leaf? object) (eq? (car object) 'leaf))
(define (symbolleaf x) (cadr x))
(define (weightleaf x) (caddr x))
A general tree will be a list of a le branch, a right branch, a set of
symbols, and a weight. e set of symbols will be simply a list of the
symbols, rather than some more sophisticated set representation. When
we make a tree by merging two nodes, we obtain the weight of the
tree as the sum of the weights of the nodes, and the set of symbols as
the union of the sets of symbols for the nodes. Since our symbol sets
are represented as lists, we can form the union by using the append
procedure we deﬁned in Section 2.2.1:
(define (makecodetree left right)
(list left
right
(append (symbols left) (symbols right))
(+ (weight left) (weight right))))
223
If we make a tree in this way, we have the following selectors:
(define (leftbranch tree) (car
tree))
(define (rightbranch tree) (cadr tree))
(define (symbols tree)
(if (leaf? tree)
(list (symbolleaf tree))
(caddr tree)))
(define (weight tree)
(if (leaf? tree)
(weightleaf tree)
(cadddr tree)))
e procedures symbols and weight must do something slightly diﬀer
ent depending on whether they are called with a leaf or a general tree.
ese are simple examples of generic procedures (procedures that can
handle more than one kind of data), which we will have much more to
say about in Section 2.4 and Section 2.5.
The decoding procedure
e following procedure implements the decoding algorithm. It takes
as arguments a list of zeros and ones, together with a Huﬀman tree.
(define (decode bits tree)
(define (decode1 bits currentbranch)
(if (null? bits)
'()
(let ((nextbranch
(choosebranch (car bits) currentbranch)))
(if (leaf? nextbranch)
(cons (symbolleaf nextbranch)
(decode1 (cdr bits) tree))
(decode1 (cdr bits) nextbranch)))))
(decode1 bits tree))
224
(define (choosebranch bit branch)
(cond ((= bit 0) (leftbranch branch))
((= bit 1) (rightbranch branch))
(else (error "bad bit: CHOOSEBRANCH" bit))))
e procedure decode1 takes two arguments: the list of remaining bits
and the current position in the tree. It keeps moving “down” the tree,
choosing a le or a right branch according to whether the next bit in the
list is a zero or a one. (is is done with the procedure choosebranch.)
When it reaches a leaf, it returns the symbol at that leaf as the next
symbol in the message by consing it onto the result of decoding the
rest of the message, starting at the root of the tree. Note the error check
in the ﬁnal clause of choosebranch, which complains if the procedure
ﬁnds something other than a zero or a one in the input data.
Sets of weighted elements
In our representation of trees, each nonleaf node contains a set of sym
bols, which we have represented as a simple list. However, the tree
generating algorithm discussed above requires that we also work with
sets of leaves and trees, successively merging the two smallest items.
Since we will be required to repeatedly ﬁnd the smallest item in a set, it
is convenient to use an ordered representation for this kind of set.
We will represent a set of leaves and trees as a list of elements, ar
ranged in increasing order of weight. e following adjoinset pro
cedure for constructing sets is similar to the one described in Exercise
2.61; however, items are compared by their weights, and the element
being added to the set is never already in it.
(define (adjoinset x set)
(cond ((null? set) (list x))
((< (weight x) (weight (car set))) (cons x set))
225
(else (cons (car set)
(adjoinset x (cdr set))))))
e following procedure takes a list of symbolfrequency pairs such as
((A 4) (B 2) (C 1) (D 1)) and constructs an initial ordered set of
leaves, ready to be merged according to the Huﬀman algorithm:
(define (makeleafset pairs)
(if (null? pairs)
'()
(let ((pair (car pairs)))
(adjoinset (makeleaf (car pair)
(cadr pair))
; symbol
; frequency
(makeleafset (cdr pairs))))))
Exercise 2.67: Deﬁne an encoding tree and a sample mes
sage:
(define sampletree
(makecodetree (makeleaf 'A 4)
(makecodetree
(makeleaf 'B 2)
(makecodetree
(makeleaf 'D 1)
(makeleaf 'C 1)))))
(define samplemessage '(0 1 1 0 0 1 0 1 0 1 1 1 0))
Use the decode procedure to decode the message, and give
the result.
Exercise 2.68: e encode procedure takes as arguments a
message and a tree and produces the list of bits that gives
the encoded message.
226
(define (encode message tree)
(if (null? message)
'()
(append (encodesymbol (car message) tree)
(encode (cdr message) tree))))
encodesymbol is a procedure, which you must write, that
returns the list of bits that encodes a given symbol accord
ing to a given tree. You should design encodesymbol so
that it signals an error if the symbol is not in the tree at all.
Test your procedure by encoding the result you obtained in
Exercise 2.67 with the sample tree and seeing whether it is
the same as the original sample message.
Exercise 2.69: e following procedure takes as its argu
ment a list of symbolfrequency pairs (where no symbol
appears in more than one pair) and generates a Huﬀman
encoding tree according to the Huﬀman algorithm.
(define (generatehuffmantree pairs)
(successivemerge (makeleafset pairs)))
makeleafset is the procedure given above that trans
forms the list of pairs into an ordered set of leaves. successive
merge is the procedure you must write, using makecode
tree to successively merge the smallestweight elements
of the set until there is only one element le, which is the
desired Huﬀman tree. (is procedure is slightly tricky, but
not really complicated. If you ﬁnd yourself designing a com
plex procedure, then you are almost certainly doing some
thing wrong. You can take signiﬁcant advantage of the fact
that we are using an ordered set representation.)
227
Exercise 2.70: e following eightsymbol alphabet with
associated relative frequencies was designed to eﬃciently
encode the lyrics of 1950s rock songs. (Note that the “sym
bols” of an “alphabet” need not be individual leers.)
A
2
BOOM 1
GET 2
JOB 2
SHA 3
NA 16
WAH 1
YIP 9
Use generatehuffmantree (Exercise 2.69) to generate a
corresponding Huﬀman tree, and use encode (Exercise 2.68)
to encode the following message:
Get a job
Sha na na na na na na na na
Get a job
Sha na na na na na na na na
Wah yip yip yip yip yip yip yip yip yip
Sha boom
How many bits are required for the encoding? What is the
smallest number of bits that would be needed to encode this
song if we used a ﬁxedlength code for the eightsymbol
alphabet?
Exercise 2.71: Suppose we have a Huﬀman tree for an al
phabet of n symbols, and that the relative frequencies of
the symbols are 1; 2; 4; : : : ; 2n(cid:0)1. Sketch the tree for n = 5;
for n = 10. In such a tree (for general n) how many bits
are required to encode the most frequent symbol? e least
frequent symbol?
228
Exercise 2.72: Consider the encoding procedure that you
designed in Exercise 2.68. What is the order of growth in
the number of steps needed to encode a symbol? Be sure
to include the number of steps needed to search the sym
bol list at each node encountered. To answer this question
in general is diﬃcult. Consider the special case where the
relative frequencies of the n symbols are as described in Ex
ercise 2.71, and give the order of growth (as a function of n)
of the number of steps needed to encode the most frequent
and least frequent symbols in the alphabet.
2.4 Multiple Representations for Abstract Data
We have introduced data abstraction, a methodology for structuring
systems in such a way that much of a program can be speciﬁed indepen
dent of the choices involved in implementing the data objects that the
program manipulates. For example, we saw in Section 2.1.1 how to sep
arate the task of designing a program that uses rational numbers from
the task of implementing rational numbers in terms of the computer
language’s primitive mechanisms for constructing compound data. e
key idea was to erect an abstraction barrier—in this case, the selec
tors and constructors for rational numbers (makerat, numer, denom)—
that isolates the way rational numbers are used from their underlying
representation in terms of list structure. A similar abstraction barrier
isolates the details of the procedures that perform rational arithmetic
(addrat, subrat, mulrat, and divrat) from the “higherlevel” pro
cedures that use rational numbers. e resulting program has the struc
ture shown in Figure 2.1.
ese dataabstraction barriers are powerful tools for controlling
229
complexity. By isolating the underlying representations of data objects,
we can divide the task of designing a large program into smaller tasks
that can be performed separately. But this kind of data abstraction is not
yet powerful enough, because it may not always make sense to speak
of “the underlying representation” for a data object.
For one thing, there might be more than one useful representation
for a data object, and we might like to design systems that can deal with
multiple representations. To take a simple example, complex numbers
may be represented in two almost equivalent ways: in rectangular form
(real and imaginary parts) and in polar form (magnitude and angle).
Sometimes rectangular form is more appropriate and sometimes polar
form is more appropriate. Indeed, it is perfectly plausible to imagine a
system in which complex numbers are represented in both ways, and
in which the procedures for manipulating complex numbers work with
either representation.
More importantly, programming systems are oen designed by many
people working over extended periods of time, subject to requirements
that change over time. In such an environment, it is simply not possi
ble for everyone to agree in advance on choices of data representation.
So in addition to the dataabstraction barriers that isolate representa
tion from use, we need abstraction barriers that isolate diﬀerent de
sign choices from each other and permit diﬀerent choices to coexist in
a single program. Furthermore, since large programs are oen created
by combining preexisting modules that were designed in isolation, we
need conventions that permit programmers to incorporate modules into
larger systems additively, that is, without having to redesign or reimple
ment these modules.
In this section, we will learn how to cope with data that may be
represented in diﬀerent ways by diﬀerent parts of a program. is re
230
quires constructing generic procedures—procedures that can operate on
data that may be represented in more than one way. Our main technique
for building generic procedures will be to work in terms of data objects
that have type tags, that is, data objects that include explicit information
about how they are to be processed. We will also discuss datadirected
programming, a powerful and convenient implementation strategy for
additively assembling systems with generic operations.
We begin with the simple complexnumber example. We will see
how type tags and datadirected style enable us to design separate rect
angular and polar representations for complex numbers while main
taining the notion of an abstract “complexnumber” data object. We will
accomplish this by deﬁning arithmetic procedures for complex numbers
(addcomplex, subcomplex, mulcomplex, and divcomplex) in terms
of generic selectors that access parts of a complex number independent
of how the number is represented. e resulting complexnumber sys
tem, as shown in Figure 2.19, contains two diﬀerent kinds of abstrac
tion barriers. e “horizontal” abstraction barriers play the same role
as the ones in Figure 2.1. ey isolate “higherlevel” operations from
“lowerlevel” representations. In addition, there is a “vertical” barrier
that gives us the ability to separately design and install alternative rep
resentations.
In Section 2.5 we will show how to use type tags and datadirected
style to develop a generic arithmetic package. is provides procedures
(add, mul, and so on) that can be used to manipulate all sorts of “num
bers” and can be easily extended when a new kind of number is needed.
In Section 2.5.3, we’ll show how to use generic arithmetic in a system
that performs symbolic algebra.
231
Figure 2.19: Dataabstraction barriers in the complex
number system.
2.4.1 Representations for Complex Numbers
We will develop a system that performs arithmetic operations on com
plex numbers as a simple but unrealistic example of a program that uses
generic operations. We begin by discussing two plausible representa
tions for complex numbers as ordered pairs: rectangular form (real part
and imaginary part) and polar form (magnitude and angle).43 Section
2.4.2 will show how both representations can be made to coexist in a
single system through the use of type tags and generic operations.
Like rational numbers, complex numbers are naturally represented
as ordered pairs. e set of complex numbers can be thought of as a
twodimensional space with two orthogonal axes, the “real” axis and the
43In actual computational systems, rectangular form is preferable to polar form most
of the time because of roundoﬀ errors in conversion between rectangular and polar
form. is is why the complexnumber example is unrealistic. Nevertheless, it provides
a clear illustration of the design of a system using generic operations and a good intro
duction to the more substantial systems to be developed later in this chapter.
232
addcomplex subcomplex mulcomplex divcomplexPrograms that use complex numbersComplexarithmetic packageRectangularrepresentationPolarrepresentationList structure and primitive machine arithmeticFigure 2.20: Complex numbers as points in the plane.
“imaginary” axis. (See Figure 2.20.) From this point of view, the complex
number z = x +iy (where i2 = (cid:0)1) can be thought of as the point in the
plane whose real coordinate is x and whose imaginary coordinate is y.
Addition of complex numbers reduces in this representation to addition
of coordinates:
Realpart(z1 + z2) = Realpart(z1) + Realpart(z2);
Imaginarypart(z1 + z2) = Imaginarypart(z1) + Imaginarypart(z2):
When multiplying complex numbers, it is more natural to think in
terms of representing a complex number in polar form, as a magnitude
and an angle (r and A in Figure 2.20). e product of two complex num
bers is the vector obtained by stretching one complex number by the
length of the other and then rotating it through the angle of the other:
Magnitude(z1 (cid:1) z2) = Magnitude(z1) (cid:1) Magnitude(z2);
Angle(z1 (cid:1) z2) = Angle(z1) + Angle(z2):
us, there are two diﬀerent representations for complex numbers, which
233
ImaginaryRealz = x + iy = reiAAyxrare appropriate for diﬀerent operations. Yet, from the viewpoint of some
one writing a program that uses complex numbers, the principle of data
abstraction suggests that all the operations for manipulating complex
numbers should be available regardless of which representation is used
by the computer. For example, it is oen useful to be able to ﬁnd the
magnitude of a complex number that is speciﬁed by rectangular coor
dinates. Similarly, it is oen useful to be able to determine the real part
of a complex number that is speciﬁed by polar coordinates.
To design such a system, we can follow the same dataabstraction
strategy we followed in designing the rationalnumber package in Sec
tion 2.1.1. Assume that the operations on complex numbers are imple
mented in terms of four selectors: realpart, imagpart, magnitude
and angle. Also assume that we have two procedures for construct
ing complex numbers: makefromrealimag returns a complex num
ber with speciﬁed real and imaginary parts, and makefrommagang
returns a complex number with speciﬁed magnitude and angle. ese
procedures have the property that, for any complex number z, both
(makefromrealimag (realpart z) (imagpart z))
and
(makefrommagang (magnitude z) (angle z))
produce complex numbers that are equal to z.
Using these constructors and selectors, we can implement arith
metic on complex numbers using the “abstract data” speciﬁed by the
constructors and selectors, just as we did for rational numbers in Sec
tion 2.1.1. As shown in the formulas above, we can add and subtract
complex numbers in terms of real and imaginary parts while multiply
ing and dividing complex numbers in terms of magnitudes and angles:
234
(define (addcomplex z1 z2)
(makefromrealimag (+ (realpart z1) (realpart z2))
(+ (imagpart z1) (imagpart z2))))
(define (subcomplex z1 z2)
(makefromrealimag ( (realpart z1) (realpart z2))
( (imagpart z1) (imagpart z2))))
(define (mulcomplex z1 z2)
(makefrommagang (* (magnitude z1) (magnitude z2))
(+ (angle z1) (angle z2))))
(define (divcomplex z1 z2)
(makefrommagang (/ (magnitude z1) (magnitude z2))
( (angle z1) (angle z2))))
To complete the complexnumber package, we must choose a represen
tation and we must implement the constructors and selectors in terms
of primitive numbers and primitive list structure. ere are two obvi
ous ways to do this: We can represent a complex number in “rectangular
form” as a pair (real part, imaginary part) or in “polar form” as a pair
(magnitude, angle). Which shall we choose?
In order to make the diﬀerent choices concrete, imagine that there
are two programmers, Ben Bitdiddle and Alyssa P. Hacker, who are
independently designing representations for the complexnumber sys
tem. Ben chooses to represent complex numbers in rectangular form.
With this choice, selecting the real and imaginary parts of a complex
number is straightforward, as is constructing a complex number with
given real and imaginary parts. To ﬁnd the magnitude and the angle, or
to construct a complex number with a given magnitude and angle, he
uses the trigonometric relations
√
x = r cos A;
y = r sin A;
x 2 + y2;
r =
A = arctan(y; x);
which relate the real and imaginary parts (x ; y) to the magnitude and the
235
angle (r; A).44 Ben’s representation is therefore given by the following
selectors and constructors:
(define (realpart z) (car z))
(define (imagpart z) (cdr z))
(define (magnitude z)
(sqrt (+ (square (realpart z))
(square (imagpart z)))))
(define (angle z)
(atan (imagpart z) (realpart z)))
(define (makefromrealimag x y) (cons x y))
(define (makefrommagang r a)
(cons (* r (cos a)) (* r (sin a))))
Alyssa, in contrast, chooses to represent complex numbers in polar form.
For her, selecting the magnitude and angle is straightforward, but she
has to use the trigonometric relations to obtain the real and imaginary
parts. Alyssa’s representation is:
(define (realpart z) (* (magnitude z) (cos (angle z))))
(define (imagpart z) (* (magnitude z) (sin (angle z))))
(define (magnitude z) (car z))
(define (angle z) (cdr z))
(define (makefromrealimag x y)
(cons (sqrt (+ (square x) (square y)))
(atan y x)))
(define (makefrommagang r a) (cons r a))
e discipline of data abstraction ensures that the same implementation
of addcomplex, subcomplex, mulcomplex, and divcomplex will work
with either Ben’s representation or Alyssa’s representation.
44e arctangent function referred to here, computed by Scheme’s atan procedure,
is deﬁned so as to take two arguments y and x and to return the angle whose tangent
is y=x. e signs of the arguments determine the quadrant of the angle.
236
2.4.2 Tagged data
One way to view data abstraction is as an application of the “princi
ple of least commitment.” In implementing the complexnumber system
in Section 2.4.1, we can use either Ben’s rectangular representation or
Alyssa’s polar representation. e abstraction barrier formed by the se
lectors and constructors permits us to defer to the last possible moment
the choice of a concrete representation for our data objects and thus
retain maximum ﬂexibility in our system design.
e principle of least commitment can be carried to even further
extremes. If we desire, we can maintain the ambiguity of representation
even aer we have designed the selectors and constructors, and elect
to use both Ben’s representation and Alyssa’s representation. If both
representations are included in a single system, however, we will need
some way to distinguish data in polar form from data in rectangular
form. Otherwise, if we were asked, for instance, to ﬁnd the magnitude
of the pair (3, 4), we wouldn’t know whether to answer 5 (interpreting
the number in rectangular form) or 3 (interpreting the number in polar
form). A straightforward way to accomplish this distinction is to include
a type tag—the symbol rectangular or polar—as part of each complex
number. en when we need to manipulate a complex number we can
use the tag to decide which selector to apply.
In order to manipulate tagged data, we will assume that we have
procedures typetag and contents that extract from a data object the
tag and the actual contents (the polar or rectangular coordinates, in the
case of a complex number). We will also postulate a procedure attach
tag that takes a tag and contents and produces a tagged data object. A
straightforward way to implement this is to use ordinary list structure:
(define (attachtag typetag contents)
(cons typetag contents))
237
(define (typetag datum)
(if (pair? datum)
(car datum)
(error "Bad tagged datum: TYPETAG" datum)))
(define (contents datum)
(if (pair? datum)
(cdr datum)
(error "Bad tagged datum: CONTENTS" datum)))
Using these procedures, we can deﬁne predicates rectangular? and
polar?, which recognize rectangular and polar numbers, respectively:
(define (rectangular? z)
(eq? (typetag z) 'rectangular))
(define (polar? z) (eq? (typetag z) 'polar))
With type tags, Ben and Alyssa can now modify their code so that their
two diﬀerent representations can coexist in the same system. When
ever Ben constructs a complex number, he tags it as rectangular. When
ever Alyssa constructs a complex number, she tags it as polar. In addi
tion, Ben and Alyssa must make sure that the names of their proce
dures do not conﬂict. One way to do this is for Ben to append the suﬃx
rectangular to the name of each of his representation procedures and
for Alyssa to append polar to the names of hers. Here is Ben’s revised
rectangular representation from Section 2.4.1:
(define (realpartrectangular z) (car z))
(define (imagpartrectangular z) (cdr z))
(define (magnituderectangular z)
(sqrt (+ (square (realpartrectangular z))
(square (imagpartrectangular z)))))
(define (anglerectangular z)
(atan (imagpartrectangular z)
(realpartrectangular z)))
238
(define (makefromrealimagrectangular x y)
(attachtag 'rectangular (cons x y)))
(define (makefrommagangrectangular r a)
(attachtag 'rectangular
(cons (* r (cos a)) (* r (sin a)))))
and here is Alyssa’s revised polar representation:
(define (realpartpolar z)
(* (magnitudepolar z) (cos (anglepolar z))))
(define (imagpartpolar z)
(* (magnitudepolar z) (sin (anglepolar z))))
(define (magnitudepolar z) (car z))
(define (anglepolar z) (cdr z))
(define (makefromrealimagpolar x y)
(attachtag 'polar
(cons (sqrt (+ (square x) (square y)))
(atan y x))))
(define (makefrommagangpolar r a)
(attachtag 'polar (cons r a)))
Each generic selector is implemented as a procedure that checks the tag
of its argument and calls the appropriate procedure for handling data
of that type. For example, to obtain the real part of a complex number,
realpart examines the tag to determine whether to use Ben’s real
partrectangular or Alyssa’s realpartpolar. In either case, we use
contents to extract the bare, untagged datum and send this to the rect
angular or polar procedure as required:
(define (realpart z)
(cond ((rectangular? z)
(realpartrectangular (contents z)))
((polar? z)
(realpartpolar (contents z)))
(else (error "Unknown type: REALPART" z))))
239
(define (imagpart z)
(cond ((rectangular? z)
(imagpartrectangular (contents z)))
((polar? z)
(imagpartpolar (contents z)))
(else (error "Unknown type: IMAGPART" z))))
(define (magnitude z)
(cond ((rectangular? z)
(magnituderectangular (contents z)))
((polar? z)
(magnitudepolar (contents z)))
(else (error "Unknown type: MAGNITUDE" z))))
(define (angle z)
(cond ((rectangular? z)
(anglerectangular (contents z)))
((polar? z)
(anglepolar (contents z)))
(else (error "Unknown type: ANGLE" z))))
To implement the complexnumber arithmetic operations, we can use
the same procedures addcomplex, subcomplex, mulcomplex, and div
complex from Section 2.4.1, because the selectors they call are generic,
and so will work with either representation. For example, the procedure
addcomplex is still
(define (addcomplex z1 z2)
(makefromrealimag (+ (realpart z1) (realpart z2))
(+ (imagpart z1) (imagpart z2))))
Finally, we must choose whether to construct complex numbers using
Ben’s representation or Alyssa’s representation. One reasonable choice
is to construct rectangular numbers whenever we have real and imag
inary parts and to construct polar numbers whenever we have magni
tudes and angles:
240
Figure 2.21: Structure of the generic complexarithmetic system.
(define (makefromrealimag x y)
(makefromrealimagrectangular x y))
(define (makefrommagang r a)
(makefrommagangpolar r a))
e resulting complexnumber system has the structure shown in Fig
ure 2.21. e system has been decomposed into three relatively inde
pendent parts: the complexnumberarithmetic operations, Alyssa’s po
lar implementation, and Ben’s rectangular implementation. e polar
and rectangular implementations could have been wrien by Ben and
Alyssa working separately, and both of these can be used as underly
ing representations by a third programmer implementing the complex
arithmetic procedures in terms of the abstract constructor/selector in
terface.
Since each data object is tagged with its type, the selectors operate
on the data in a generic manner. at is, each selector is deﬁned to have
a behavior that depends upon the particular type of data it is applied to.
241
addcomplex subcomplex mulcomplex divcomplexPrograms that use complex numbersComplexarithmetic packageRectangularrepresentationPolarrepresentationList structure and primitive machine arithmeticrealpartimagpartmagnitudeangleNotice the general mechanism for interfacing the separate representa
tions: Within a given representation implementation (say, Alyssa’s po
lar package) a complex number is an untyped pair (magnitude, angle).
When a generic selector operates on a number of polar type, it strips oﬀ
the tag and passes the contents on to Alyssa’s code. Conversely, when
Alyssa constructs a number for general use, she tags it with a type so
that it can be appropriately recognized by the higherlevel procedures.
is discipline of stripping oﬀ and aaching tags as data objects are
passed from level to level can be an important organizational strategy,
as we shall see in Section 2.5.
2.4.3 DataDirected Programming and Additivity
e general strategy of checking the type of a datum and calling an
appropriate procedure is called dispatching on type. is is a powerful
strategy for obtaining modularity in system design. On the other hand,
implementing the dispatch as in Section 2.4.2 has two signiﬁcant weak
nesses. One weakness is that the generic interface procedures (real
part, imagpart, magnitude, and angle) must know about all the dif
ferent representations. For instance, suppose we wanted to incorporate
a new representation for complex numbers into our complexnumber
system. We would need to identify this new representation with a type,
and then add a clause to each of the generic interface procedures to
check for the new type and apply the appropriate selector for that rep
resentation.
Another weakness of the technique is that even though the indi
vidual representations can be designed separately, we must guarantee
that no two procedures in the entire system have the same name. is
is why Ben and Alyssa had to change the names of their original proce
dures from Section 2.4.1.
242
e issue underlying both of these weaknesses is that the technique
for implementing generic interfaces is not additive. e person imple
menting the generic selector procedures must modify those procedures
each time a new representation is installed, and the people interfacing
the individual representations must modify their code to avoid name
conﬂicts. In each of these cases, the changes that must be made to the
code are straightforward, but they must be made nonetheless, and this
is a source of inconvenience and error. is is not much of a problem
for the complexnumber system as it stands, but suppose there were
not two but hundreds of diﬀerent representations for complex numbers.
And suppose that there were many generic selectors to be maintained
in the abstractdata interface. Suppose, in fact, that no one program
mer knew all the interface procedures or all the representations. e
problem is real and must be addressed in such programs as largescale
databasemanagement systems.
What we need is a means for modularizing the system design even
further. is is provided by the programming technique known as data
directed programming. To understand how datadirected programming
works, begin with the observation that whenever we deal with a set of
generic operations that are common to a set of diﬀerent types we are,
in eﬀect, dealing with a twodimensional table that contains the possi
ble operations on one axis and the possible types on the other axis. e
entries in the table are the procedures that implement each operation
for each type of argument presented. In the complexnumber system
developed in the previous section, the correspondence between opera
tion name, data type, and actual procedure was spread out among the
various conditional clauses in the generic interface procedures. But the
same information could have been organized in a table, as shown in
Figure 2.22.
243
Figure 2.22: Table of operations for the complexnumber system.
Datadirected programming is the technique of designing programs
to work with such a table directly. Previously, we implemented the
mechanism that interfaces the complexarithmetic code with the two
representation packages as a set of procedures that each perform an
explicit dispatch on type. Here we will implement the interface as a sin
gle procedure that looks up the combination of the operation name and
argument type in the table to ﬁnd the correct procedure to apply, and
then applies it to the contents of the argument. If we do this, then to
add a new representation package to the system we need not change
any existing procedures; we need only add new entries to the table.
To implement this plan, assume that we have two procedures, put
and get, for manipulating the operationandtype table:
• (put ⟨op⟩ ⟨type⟩ ⟨item⟩) installs the ⟨item⟩ in the table, indexed
by the ⟨op⟩ and the ⟨type⟩.
• (get ⟨op⟩ ⟨type⟩) looks up the ⟨op⟩, ⟨type⟩ entry in the table and
returns the item found there. If no item is found, get returns false.
For now, we can assume that put and get are included in our language.
In Chapter 3 (Section 3.3.3) we will see how to implement these and
244
realpartimagpartmagnitudeanglerealpartpolarimagpartpolarmagnitudepolaranglepolarrealpartrectangularimagpartrectangularmagnituderectangularanglerectangularTypesPolarRectangularOperationsother operations for manipulating tables.
Here is how datadirected programming can be used in the complex
number system. Ben, who developed the rectangular representation,
implements his code just as he did originally. He deﬁnes a collection
of procedures, or a package, and interfaces these to the rest of the sys
tem by adding entries to the table that tell the system how to operate
on rectangular numbers. is is accomplished by calling the following
procedure:
(define (installrectangularpackage)
;; internal procedures
(define (realpart z) (car z))
(define (imagpart z) (cdr z))
(define (makefromrealimag x y) (cons x y))
(define (magnitude z)
(sqrt (+ (square (realpart z))
(square (imagpart z)))))
(define (angle z)
(atan (imagpart z) (realpart z)))
(define (makefrommagang r a)
(cons (* r (cos a)) (* r (sin a))))
;; interface to the rest of the system
(define (tag x) (attachtag 'rectangular x))
(put 'realpart '(rectangular) realpart)
(put 'imagpart '(rectangular) imagpart)
(put 'magnitude '(rectangular) magnitude)
(put 'angle '(rectangular) angle)
(put 'makefromrealimag 'rectangular
(lambda (x y) (tag (makefromrealimag x y))))
(put 'makefrommagang 'rectangular
(lambda (r a) (tag (makefrommagang r a))))
'done)
245
Notice that the internal procedures here are the same procedures from
Section 2.4.1 that Ben wrote when he was working in isolation. No
changes are necessary in order to interface them to the rest of the sys
tem. Moreover, since these procedure deﬁnitions are internal to the in
stallation procedure, Ben needn’t worry about name conﬂicts with other
procedures outside the rectangular package. To interface these to the
rest of the system, Ben installs his realpart procedure under the op
eration name realpart and the type (rectangular), and similarly for
the other selectors.45 e interface also deﬁnes the constructors to be
used by the external system.46 ese are identical to Ben’s internally
deﬁned constructors, except that they aach the tag.
Alyssa’s polar package is analogous:
(define (installpolarpackage)
;; internal procedures
(define (magnitude z) (car z))
(define (angle z) (cdr z))
(define (makefrommagang r a) (cons r a))
(define (realpart z) (* (magnitude z) (cos (angle z))))
(define (imagpart z) (* (magnitude z) (sin (angle z))))
(define (makefromrealimag x y)
(cons (sqrt (+ (square x) (square y)))
(atan y x)))
;; interface to the rest of the system
(define (tag x) (attachtag 'polar x))
(put 'realpart '(polar) realpart)
(put 'imagpart '(polar) imagpart)
(put 'magnitude '(polar) magnitude)
45We use the list (rectangular) rather than the symbol rectangular to allow for
the possibility of operations with multiple arguments, not all of the same type.
46e type the constructors are installed under needn’t be a list because a constructor
is always used to make an object of one particular type.
246
(put 'angle '(polar) angle)
(put 'makefromrealimag 'polar
(lambda (x y) (tag (makefromrealimag x y))))
(put 'makefrommagang 'polar
(lambda (r a) (tag (makefrommagang r a))))
'done)
Even though Ben and Alyssa both still use their original procedures
deﬁned with the same names as each other’s (e.g., realpart), these
deﬁnitions are now internal to diﬀerent procedures (see Section 1.1.8),
so there is no name conﬂict.
e complexarithmetic selectors access the table by means of a
general “operation” procedure called applygeneric, which applies a
generic operation to some arguments. applygeneric looks in the ta
ble under the name of the operation and the types of the arguments and
applies the resulting procedure if one is present:47
(define (applygeneric op . args)
(let ((typetags (map typetag args)))
(let ((proc (get op typetags)))
(if proc
(apply proc (map contents args))
(error
47applygeneric uses the doedtail notation described in Exercise 2.20, because dif
ferent generic operations may take diﬀerent numbers of arguments. In applygeneric,
op has as its value the ﬁrst argument to applygeneric and args has as its value a list
of the remaining arguments.
applygeneric also uses the primitive procedure apply, which takes two arguments,
a procedure and a list. apply applies the procedure, using the elements in the list as
arguments. For example,
(apply + (list 1 2 3 4))
returns 10.
247
"No method for these types: APPLYGENERIC"
(list op typetags))))))
Using applygeneric, we can deﬁne our generic selectors as follows:
(define (realpart z) (applygeneric 'realpart z))
(define (imagpart z) (applygeneric 'imagpart z))
(define (magnitude z) (applygeneric 'magnitude z))
(define (angle z) (applygeneric 'angle z))
Observe that these do not change at all if a new representation is added
to the system.
We can also extract from the table the constructors to be used by the
programs external to the packages in making complex numbers from
real and imaginary parts and from magnitudes and angles. As in Section
2.4.2, we construct rectangular numbers whenever we have real and
imaginary parts, and polar numbers whenever we have magnitudes and
angles:
(define (makefromrealimag x y)
((get 'makefromrealimag 'rectangular) x y))
(define (makefrommagang r a)
((get 'makefrommagang 'polar) r a))
Exercise 2.73: Section 2.3.2 described a program that per
forms symbolic diﬀerentiation:
(define (deriv exp var)
(cond ((number? exp) 0)
((variable? exp)
(if (samevariable? exp var) 1 0))
((sum? exp)
(makesum (deriv (addend exp) var)
(deriv (augend exp) var)))
248
((product? exp)
(makesum (makeproduct
(multiplier exp)
(deriv (multiplicand exp) var))
(makeproduct
(deriv (multiplier exp) var)
(multiplicand exp))))
⟨more rules can be added here⟩
(else (error "unknown expression type:
DERIV" exp))))
We can regard this program as performing a dispatch on
the type of the expression to be diﬀerentiated. In this situ
ation the “type tag” of the datum is the algebraic operator
symbol (such as +) and the operation being performed is
deriv. We can transform this program into datadirected
style by rewriting the basic derivative procedure as
(define (deriv exp var)
(cond ((number? exp) 0)
((variable? exp) (if (samevariable? exp var) 1 0))
(else ((get 'deriv (operator exp))
(operands exp) var))))
(define (operator exp) (car exp))
(define (operands exp) (cdr exp))
a. Explain what was done above. Why can’t we assim
ilate the predicates number? and variable? into the
datadirected dispatch?
b. Write the procedures for derivatives of sums and prod
ucts, and the auxiliary code required to install them in
the table used by the program above.
249
c. Choose any additional diﬀerentiation rule that you
like, such as the one for exponents (Exercise 2.56), and
install it in this datadirected system.
d. In this simple algebraic manipulator the type of an
expression is the algebraic operator that binds it to
gether. Suppose, however, we indexed the procedures
in the opposite way, so that the dispatch line in deriv
looked like
((get (operator exp) 'deriv) (operands exp) var)
What corresponding changes to the derivative system
are required?
Exercise 2.74: Insatiable Enterprises, Inc., is a highly de
centralized conglomerate company consisting of a large num
ber of independent divisions located all over the world. e
company’s computer facilities have just been interconnected
by means of a clever networkinterfacing scheme that makes
the entire network appear to any user to be a single com
puter. Insatiable’s president, in her ﬁrst aempt to exploit
the ability of the network to extract administrative infor
mation from division ﬁles, is dismayed to discover that, al
though all the division ﬁles have been implemented as data
structures in Scheme, the particular data structure used varies
from division to division. A meeting of division managers
is hastily called to search for a strategy to integrate the ﬁles
that will satisfy headquarters’ needs while preserving the
existing autonomy of the divisions.
Show how such a strategy can be implemented with data
directed programming. As an example, suppose that each
250
division’s personnel records consist of a single ﬁle, which
contains a set of records keyed on employees’ names. e
structure of the set varies from division to division. Fur
thermore, each employee’s record is itself a set (structured
diﬀerently from division to division) that contains informa
tion keyed under identiﬁers such as address and salary.
In particular:
a. Implement for headquarters a getrecord procedure
that retrieves a speciﬁed employee’s record from a
speciﬁed personnel ﬁle. e procedure should be ap
plicable to any division’s ﬁle. Explain how the individ
ual divisions’ ﬁles should be structured. In particular,
what type information must be supplied?
b. Implement for headquarters a getsalary procedure
that returns the salary information from a given em
ployee’s record from any division’s personnel ﬁle. How
should the record be structured in order to make this
operation work?
c. Implement for headquarters a findemployeerecord
procedure. is should search all the divisions’ ﬁles
for the record of a given employee and return the record.
Assume that this procedure takes as arguments an
employee’s name and a list of all the divisions’ ﬁles.
d. When Insatiable takes over a new company, what changes
must be made in order to incorporate the new person
nel information into the central system?
251
Message passing
e key idea of datadirected programming is to handle generic opera
tions in programs by dealing explicitly with operationandtype tables,
such as the table in Figure 2.22. e style of programming we used in
Section 2.4.2 organized the required dispatching on type by having each
operation take care of its own dispatching. In eﬀect, this decomposes the
operationandtype table into rows, with each generic operation proce
dure representing a row of the table.
An alternative implementation strategy is to decompose the table
into columns and, instead of using “intelligent operations” that dispatch
on data types, to work with “intelligent data objects” that dispatch on
operation names. We can do this by arranging things so that a data
object, such as a rectangular number, is represented as a procedure that
takes as input the required operation name and performs the operation
indicated. In such a discipline, makefromrealimag could be wrien
as
(define (makefromrealimag x y)
(define (dispatch op)
(cond ((eq? op 'realpart) x)
((eq? op 'imagpart) y)
((eq? op 'magnitude) (sqrt (+ (square x) (square y))))
((eq? op 'angle) (atan y x))
(else (error "Unknown op: MAKEFROMREALIMAG" op))))
dispatch)
e corresponding applygeneric procedure, which applies a generic
operation to an argument, now simply feeds the operation’s name to
the data object and lets the object do the work:48
48One limitation of this organization is it permits only generic procedures of one
argument.
252
(define (applygeneric op arg) (arg op))
Note that the value returned by makefromrealimag is a procedure—
the internal dispatch procedure. is is the procedure that is invoked
when applygeneric requests an operation to be performed.
is style of programming is called message passing. e name comes
from the image that a data object is an entity that receives the requested
operation name as a “message.” We have already seen an example of
message passing in Section 2.1.3, where we saw how cons, car, and cdr
could be deﬁned with no data objects but only procedures. Here we see
that message passing is not a mathematical trick but a useful technique
for organizing systems with generic operations. In the remainder of this
chapter we will continue to use datadirected programming, rather than
message passing, to discuss generic arithmetic operations. In Chapter 3
we will return to message passing, and we will see that it can be a pow
erful tool for structuring simulation programs.
Exercise 2.75: Implement the constructor makefrommag
ang in messagepassing style. is procedure should be anal
ogous to the makefromrealimag procedure given above.
Exercise 2.76: As a large system with generic operations
evolves, new types of data objects or new operations may
be needed. For each of the three strategies—generic opera
tions with explicit dispatch, datadirected style, and message
passingstyle—describe the changes that must be made to a
system in order to add new types or new operations. Which
organization would be most appropriate for a system in
which new types must oen be added? Which would be
most appropriate for a system in which new operations
must oen be added?
253
2.5 Systems with Generic Operations
In the previous section, we saw how to design systems in which data
objects can be represented in more than one way. e key idea is to
link the code that speciﬁes the data operations to the several represen
tations by means of generic interface procedures. Now we will see how
to use this same idea not only to deﬁne operations that are generic over
diﬀerent representations but also to deﬁne operations that are generic
over diﬀerent kinds of arguments. We have already seen several dif
ferent packages of arithmetic operations: the primitive arithmetic (+, ,
*, /) built into our language, the rationalnumber arithmetic (addrat,
subrat, mulrat, divrat) of Section 2.1.1, and the complexnumber
arithmetic that we implemented in Section 2.4.3. We will now use data
directed techniques to construct a package of arithmetic operations that
incorporates all the arithmetic packages we have already constructed.
Figure 2.23 shows the structure of the system we shall build. Notice
the abstraction barriers. From the perspective of someone using “num
bers,” there is a single procedure add that operates on whatever num
bers are supplied. add is part of a generic interface that allows the sep
arate ordinaryarithmetic, rationalarithmetic, and complexarithmetic
packages to be accessed uniformly by programs that use numbers. Any
individual arithmetic package (such as the complex package) may it
self be accessed through generic procedures (such as addcomplex) that
combine packages designed for diﬀerent representations (such as rect
angular and polar). Moreover, the structure of the system is additive, so
that one can design the individual arithmetic packages separately and
combine them to produce a generic arithmetic system.
254
Figure 2.23: Generic arithmetic system.
2.5.1 Generic Arithmetic Operations
e task of designing generic arithmetic operations is analogous to that
of designing the generic complexnumber operations. We would like,
for instance, to have a generic addition procedure add that acts like or
dinary primitive addition + on ordinary numbers, like addrat on ra
tional numbers, and like addcomplex on complex numbers. We can
implement add, and the other generic arithmetic operations, by follow
ing the same strategy we used in Section 2.4.3 to implement the generic
selectors for complex numbers. We will aach a type tag to each kind of
number and cause the generic procedure to dispatch to an appropriate
package according to the data type of its arguments.
e generic arithmetic procedures are deﬁned as follows:
(define (add x y) (applygeneric 'add x y))
255
add sub mul divaddcomplexmulcomplexsubcomplexdivcomplexPrograms that use numbersGeneric arithmetic packageComplex arithmeticRectangularPolarsubratdivrataddratmulratRationalarithmeticOrdinaryarithmeticList structure and primitive machine arithmetic+  */(define (sub x y) (applygeneric 'sub x y))
(define (mul x y) (applygeneric 'mul x y))
(define (div x y) (applygeneric 'div x y))
We begin by installing a package for handling ordinary numbers, that
is, the primitive numbers of our language. We will tag these with the
symbol schemenumber. e arithmetic operations in this package are
the primitive arithmetic procedures (so there is no need to deﬁne extra
procedures to handle the untagged numbers). Since these operations
each take two arguments, they are installed in the table keyed by the
list (schemenumber schemenumber):
(define (installschemenumberpackage)
(define (tag x) (attachtag 'schemenumber x))
(put 'add '(schemenumber schemenumber)
(lambda (x y) (tag (+ x y))))
(put 'sub '(schemenumber schemenumber)
(lambda (x y) (tag ( x y))))
(put 'mul '(schemenumber schemenumber)
(lambda (x y) (tag (* x y))))
(put 'div '(schemenumber schemenumber)
(lambda (x y) (tag (/ x y))))
(put 'make 'schemenumber (lambda (x) (tag x)))
'done)
Users of the Schemenumber package will create (tagged) ordinary num
bers by means of the procedure:
(define (makeschemenumber n)
((get 'make 'schemenumber) n))
Now that the framework of the generic arithmetic system is in place,
we can readily include new kinds of numbers. Here is a package that
performs rational arithmetic. Notice that, as a beneﬁt of additivity, we
256
can use without modiﬁcation the rationalnumber code from Section
2.1.1 as the internal procedures in the package:
(define (installrationalpackage)
;; internal procedures
(define (numer x) (car x))
(define (denom x) (cdr x))
(define (makerat n d)
(let ((g (gcd n d)))
(cons (/ n g) (/ d g))))
(define (addrat x y)
(makerat (+ (* (numer x) (denom y))
(* (numer y) (denom x)))
(* (denom x) (denom y))))
(define (subrat x y)
(makerat ( (* (numer x) (denom y))
(* (numer y) (denom x)))
(* (denom x) (denom y))))
(define (mulrat x y)
(makerat (* (numer x) (numer y))
(* (denom x) (denom y))))
(define (divrat x y)
(makerat (* (numer x) (denom y))
(* (denom x) (numer y))))
;; interface to rest of the system
(define (tag x) (attachtag 'rational x))
(put 'add '(rational rational)
(lambda (x y) (tag (addrat x y))))
(put 'sub '(rational rational)
(lambda (x y) (tag (subrat x y))))
(put 'mul '(rational rational)
(lambda (x y) (tag (mulrat x y))))
(put 'div '(rational rational)
(lambda (x y) (tag (divrat x y))))
257
(put 'make 'rational
(lambda (n d) (tag (makerat n d))))
'done)
(define (makerational n d)
((get 'make 'rational) n d))
We can install a similar package to handle complex numbers, using the
tag complex. In creating the package, we extract from the table the op
erations makefromrealimag and makefrommagang that were de
ﬁned by the rectangular and polar packages. Additivity permits us to
use, as the internal operations, the same addcomplex, subcomplex,
mulcomplex, and divcomplex procedures from Section 2.4.1.
(define (installcomplexpackage)
;; imported procedures from rectangular and polar packages
(define (makefromrealimag x y)
((get 'makefromrealimag 'rectangular) x y))
(define (makefrommagang r a)
((get 'makefrommagang 'polar) r a))
;; internal procedures
(define (addcomplex z1 z2)
(makefromrealimag (+ (realpart z1) (realpart z2))
(+ (imagpart z1) (imagpart z2))))
(define (subcomplex z1 z2)
(makefromrealimag ( (realpart z1) (realpart z2))
( (imagpart z1) (imagpart z2))))
(define (mulcomplex z1 z2)
(makefrommagang (* (magnitude z1) (magnitude z2))
(+ (angle z1) (angle z2))))
(define (divcomplex z1 z2)
(makefrommagang (/ (magnitude z1) (magnitude z2))
( (angle z1) (angle z2))))
;; interface to rest of the system
(define (tag z) (attachtag 'complex z))
258
(put 'add '(complex complex)
(lambda (z1 z2) (tag (addcomplex z1 z2))))
(put 'sub '(complex complex)
(lambda (z1 z2) (tag (subcomplex z1 z2))))
(put 'mul '(complex complex)
(lambda (z1 z2) (tag (mulcomplex z1 z2))))
(put 'div '(complex complex)
(lambda (z1 z2) (tag (divcomplex z1 z2))))
(put 'makefromrealimag 'complex
(lambda (x y) (tag (makefromrealimag x y))))
(put 'makefrommagang 'complex
(lambda (r a) (tag (makefrommagang r a))))
'done)
Programs outside the complexnumber package can construct complex
numbers either from real and imaginary parts or from magnitudes and
angles. Notice how the underlying procedures, originally deﬁned in the
rectangular and polar packages, are exported to the complex package,
and exported from there to the outside world.
(define (makecomplexfromrealimag x y)
((get 'makefromrealimag 'complex) x y))
(define (makecomplexfrommagang r a)
((get 'makefrommagang 'complex) r a))
What we have here is a twolevel tag system. A typical complex num
ber, such as 3 + 4i in rectangular form, would be represented as shown
in Figure 2.24. e outer tag (complex) is used to direct the number to
the complex package. Once within the complex package, the next tag
(rectangular) is used to direct the number to the rectangular package.
In a large and complicated system there might be many levels, each in
terfaced with the next by means of generic operations. As a data object
is passed “downward,” the outer tag that is used to direct it to the ap
259
Figure 2.24: Representation of 3 + 4i in rectangular form.
propriate package is stripped oﬀ (by applying contents) and the next
level of tag (if any) becomes visible to be used for further dispatching.
In the above packages, we used addrat, addcomplex, and the other
arithmetic procedures exactly as originally wrien. Once these deﬁni
tions are internal to diﬀerent installation procedures, however, they no
longer need names that are distinct from each other: we could simply
name them add, sub, mul, and div in both packages.
Exercise 2.77: Louis Reasoner tries to evaluate the expres
sion (magnitude z) where z is the object shown in Figure
2.24. To his surprise, instead of the answer 5 he gets an error
message from applygeneric, saying there is no method
for the operation magnitude on the types (complex). He
shows this interaction to Alyssa P. Hacker, who says “e
problem is that the complexnumber selectors were never
deﬁned for complex numbers, just for polar and rectangular
numbers. All you have to do to make this work is add the
following to the complex package:”
(put 'realpart '(complex) realpart)
(put 'imagpart '(complex) imagpart)
(put 'magnitude '(complex) magnitude)
(put 'angle '(complex) angle)
260
34complexrectangularDescribe in detail why this works. As an example, trace
through all the procedures called in evaluating the expres
sion (magnitude z) where z is the object shown in Figure
2.24. In particular, how many times is applygeneric in
voked? What procedure is dispatched to in each case?
Exercise 2.78: e internal procedures in the schemenumber
package are essentially nothing more than calls to the prim
itive procedures +, , etc. It was not possible to use the prim
itives of the language directly because our typetag system
requires that each data object have a type aached to it. In
fact, however, all Lisp implementations do have a type sys
tem, which they use internally. Primitive predicates such
as symbol? and number? determine whether data objects
have particular types. Modify the deﬁnitions of typetag,
contents, and attachtag from Section 2.4.2 so that our
generic system takes advantage of Scheme’s internal type
system. at is to say, the system should work as before ex
cept that ordinary numbers should be represented simply
as Scheme numbers rather than as pairs whose car is the
symbol schemenumber.
Exercise 2.79: Deﬁne a generic equality predicate equ? that
tests the equality of two numbers, and install it in the generic
arithmetic package. is operation should work for ordi
nary numbers, rational numbers, and complex numbers.
Exercise 2.80: Deﬁne a generic predicate =zero? that tests
if its argument is zero, and install it in the generic arith
metic package. is operation should work for ordinary
numbers, rational numbers, and complex numbers.
261
2.5.2 Combining Data of Diﬀerent Types
We have seen how to deﬁne a uniﬁed arithmetic system that encom
passes ordinary numbers, complex numbers, rational numbers, and any
other type of number we might decide to invent, but we have ignored an
important issue. e operations we have deﬁned so far treat the diﬀer
ent data types as being completely independent. us, there are separate
packages for adding, say, two ordinary numbers, or two complex num
bers. What we have not yet considered is the fact that it is meaningful to
deﬁne operations that cross the type boundaries, such as the addition of
a complex number to an ordinary number. We have gone to great pains
to introduce barriers between parts of our programs so that they can be
developed and understood separately. We would like to introduce the
crosstype operations in some carefully controlled way, so that we can
support them without seriously violating our module boundaries.
One way to handle crosstype operations is to design a diﬀerent pro
cedure for each possible combination of types for which the operation
is valid. For example, we could extend the complexnumber package so
that it provides a procedure for adding complex numbers to ordinary
numbers and installs this in the table using the tag (complex scheme
number):49
;; to be included in the complex package
(define (addcomplextoschemenum z x)
(makefromrealimag (+ (realpart z) x) (imagpart z)))
(put 'add '(complex schemenumber)
(lambda (z x) (tag (addcomplextoschemenum z x))))
is technique works, but it is cumbersome. With such a system, the
cost of introducing a new type is not just the construction of the pack
49We also have to supply an almost identical procedure to handle the types (scheme
number complex).
262
age of procedures for that type but also the construction and installa
tion of the procedures that implement the crosstype operations. is
can easily be much more code than is needed to deﬁne the operations
on the type itself. e method also undermines our ability to combine
separate packages additively, or at least to limit the extent to which the
implementors of the individual packages need to take account of other
packages. For instance, in the example above, it seems reasonable that
handling mixed operations on complex numbers and ordinary numbers
should be the responsibility of the complexnumber package. Combin
ing rational numbers and complex numbers, however, might be done by
the complex package, by the rational package, or by some third package
that uses operations extracted from these two packages. Formulating
coherent policies on the division of responsibility among packages can
be an overwhelming task in designing systems with many packages and
many crosstype operations.
Coercion
In the general situation of completely unrelated operations acting on
completely unrelated types, implementing explicit crosstype operations,
cumbersome though it may be, is the best that one can hope for. For
tunately, we can usually do beer by taking advantage of additional
structure that may be latent in our type system. Oen the diﬀerent data
types are not completely independent, and there may be ways by which
objects of one type may be viewed as being of another type. is process
is called coercion. For example, if we are asked to arithmetically combine
an ordinary number with a complex number, we can view the ordinary
number as a complex number whose imaginary part is zero. is trans
forms the problem to that of combining two complex numbers, which
can be handled in the ordinary way by the complexarithmetic package.
263
In general, we can implement this idea by designing coercion pro
cedures that transform an object of one type into an equivalent object
of another type. Here is a typical coercion procedure, which transforms
a given ordinary number to a complex number with that real part and
zero imaginary part:
(define (schemenumber>complex n)
(makecomplexfromrealimag (contents n) 0))
We install these coercion procedures in a special coercion table, indexed
under the names of the two types:
(putcoercion 'schemenumber
'complex
schemenumber>complex)
(We assume that there are putcoercion and getcoercion procedures
available for manipulating this table.) Generally some of the slots in the
table will be empty, because it is not generally possible to coerce an ar
bitrary data object of each type into all other types. For example, there
is no way to coerce an arbitrary complex number to an ordinary num
ber, so there will be no general complex>schemenumber procedure
included in the table.
Once the coercion table has been set up, we can handle coercion
in a uniform manner by modifying the applygeneric procedure of
Section 2.4.3. When asked to apply an operation, we ﬁrst check whether
the operation is deﬁned for the arguments’ types, just as before. If so,
we dispatch to the procedure found in the operationandtype table.
Otherwise, we try coercion. For simplicity, we consider only the case
where there are two arguments.50 We check the coercion table to see
if objects of the ﬁrst type can be coerced to the second type. If so, we
50See Exercise 2.82 for generalizations.
264
coerce the ﬁrst argument and try the operation again. If objects of the
ﬁrst type cannot in general be coerced to the second type, we try the
coercion the other way around to see if there is a way to coerce the
second argument to the type of the ﬁrst argument. Finally, if there is no
known way to coerce either type to the other type, we give up. Here is
the procedure:
(define (applygeneric op . args)
(let ((typetags (map typetag args)))
(let ((proc (get op typetags)))
(if proc
(apply proc (map contents args))
(if (= (length args) 2)
(let ((type1 (car typetags))
(type2 (cadr typetags))
(a1 (car args))
(a2 (cadr args)))
(let ((t1>t2 (getcoercion type1 type2))
(t2>t1 (getcoercion type2 type1)))
(cond (t1>t2
(applygeneric op (t1>t2 a1) a2))
(t2>t1
(applygeneric op a1 (t2>t1 a2)))
(else (error "No method for these types"
(list op typetags))))))
(error "No method for these types"
(list op typetags)))))))
is coercion scheme has many advantages over the method of deﬁning
explicit crosstype operations, as outlined above. Although we still need
to write coercion procedures to relate the types (possibly n2 procedures
for a system with n types), we need to write only one procedure for
each pair of types rather than a diﬀerent procedure for each collection
265
of types and each generic operation.51 What we are counting on here
is the fact that the appropriate transformation between types depends
only on the types themselves, not on the operation to be applied.
On the other hand, there may be applications for which our coer
cion scheme is not general enough. Even when neither of the objects to
be combined can be converted to the type of the other it may still be
possible to perform the operation by converting both objects to a third
type. In order to deal with such complexity and still preserve modular
ity in our programs, it is usually necessary to build systems that take
advantage of still further structure in the relations among types, as we
discuss next.
Hierarchies of types
e coercion scheme presented above relied on the existence of natural
relations between pairs of types. Oen there is more “global” structure
in how the diﬀerent types relate to each other. For instance, suppose
we are building a generic arithmetic system to handle integers, rational
numbers, real numbers, and complex numbers. In such a system, it is
quite natural to regard an integer as a special kind of rational number,
which is in turn a special kind of real number, which is in turn a special
kind of complex number. What we actually have is a socalled hierarchy
of types, in which, for example, integers are a subtype of rational num
51If we are clever, we can usually get by with fewer than n2 coercion procedures.
For instance, if we know how to convert from type 1 to type 2 and from type 2 to
type 3, then we can use this knowledge to convert from type 1 to type 3. is can
greatly decrease the number of coercion procedures we need to supply explicitly when
we add a new type to the system. If we are willing to build the required amount of
sophistication into our system, we can have it search the “graph” of relations among
types and automatically generate those coercion procedures that can be inferred from
the ones that are supplied explicitly.
266
Figure 2.25: A tower of types.
bers (i.e., any operation that can be applied to a rational number can
automatically be applied to an integer). Conversely, we say that ratio
nal numbers form a supertype of integers. e particular hierarchy we
have here is of a very simple kind, in which each type has at most one
supertype and at most one subtype. Such a structure, called a tower, is
illustrated in Figure 2.25.
If we have a tower structure, then we can greatly simplify the prob
lem of adding a new type to the hierarchy, for we need only specify
how the new type is embedded in the next supertype above it and how
it is the supertype of the type below it. For example, if we want to add
an integer to a complex number, we need not explicitly deﬁne a special
coercion procedure integer>complex. Instead, we deﬁne how an inte
ger can be transformed into a rational number, how a rational number is
transformed into a real number, and how a real number is transformed
into a complex number. We then allow the system to transform the in
teger into a complex number through these steps and then add the two
complex numbers.
We can redesign our applygeneric procedure in the following
way: For each type, we need to supply a raise procedure, which “raises”
267
complexrealrationalintegerobjects of that type one level in the tower. en when the system is re
quired to operate on objects of diﬀerent types it can successively raise
the lower types until all the objects are at the same level in the tower.
(Exercise 2.83 and Exercise 2.84 concern the details of implementing
such a strategy.)
Another advantage of a tower is that we can easily implement the
notion that every type “inherits” all operations deﬁned on a supertype.
For instance, if we do not supply a special procedure for ﬁnding the real
part of an integer, we should nevertheless expect that realpart will
be deﬁned for integers by virtue of the fact that integers are a subtype
of complex numbers. In a tower, we can arrange for this to happen in a
uniform way by modifying applygeneric. If the required operation is
not directly deﬁned for the type of the object given, we raise the object
to its supertype and try again. We thus crawl up the tower, transforming
our argument as we go, until we either ﬁnd a level at which the desired
operation can be performed or hit the top (in which case we give up).
Yet another advantage of a tower over a more general hierarchy is
that it gives us a simple way to “lower” a data object to the simplest
representation. For example, if we add 2 + 3i to 4 (cid:0) 3i, it would be nice
to obtain the answer as the integer 6 rather than as the complex num
ber 6 + 0i. Exercise 2.85 discusses a way to implement such a lowering
operation. (e trick is that we need a general way to distinguish those
objects that can be lowered, such as 6 + 0i, from those that cannot, such
as 6 + 2i.)
Inadequacies of hierarchies
If the data types in our system can be naturally arranged in a tower,
this greatly simpliﬁes the problems of dealing with generic operations
on diﬀerent types, as we have seen. Unfortunately, this is usually not the
case. Figure 2.26 illustrates a more complex arrangement of mixed types,
268
Figure 2.26: Relations among types of geometric ﬁgures.
this one showing relations among diﬀerent types of geometric ﬁgures.
We see that, in general, a type may have more than one subtype. Tri
angles and quadrilaterals, for instance, are both subtypes of polygons.
In addition, a type may have more than one supertype. For example,
an isosceles right triangle may be regarded either as an isosceles trian
gle or as a right triangle. is multiplesupertypes issue is particularly
thorny, since it means that there is no unique way to “raise” a type in the
hierarchy. Finding the “correct” supertype in which to apply an opera
tion to an object may involve considerable searching through the entire
type network on the part of a procedure such as applygeneric. Since
there generally are multiple subtypes for a type, there is a similar prob
lem in coercing a value “down” the type hierarchy. Dealing with large
numbers of interrelated types while still preserving modularity in the
269
polygonquadrilateralkitetrapezoidparallelogramrectanglerhombussquaretriangleisoscelestrianglerighttriangleisoscelesright triangleequilateraltriangledesign of large systems is very diﬃcult, and is an area of much current
research.52
Exercise 2.81: Louis Reasoner has noticed that applygeneric
may try to coerce the arguments to each other’s type even
if they already have the same type. erefore, he reasons,
we need to put procedures in the coercion table to coerce
arguments of each type to their own type. For example, in
addition to the schemenumber>complex coercion shown
above, he would do:
(define (schemenumber>schemenumber n) n)
(define (complex>complex z) z)
(putcoercion 'schemenumber
'schemenumber
schemenumber>schemenumber)
(putcoercion 'complex 'complex complex>complex)
52is statement, which also appears in the ﬁrst edition of this book, is just as true
now as it was when we wrote it twelve years ago. Developing a useful, general frame
work for expressing the relations among diﬀerent types of entities (what philosophers
call “ontology”) seems intractably diﬃcult. e main diﬀerence between the confu
sion that existed ten years ago and the confusion that exists now is that now a va
riety of inadequate ontological theories have been embodied in a plethora of corre
spondingly inadequate programming languages. For example, much of the complexity
of objectoriented programming languages—and the subtle and confusing diﬀerences
among contemporary objectoriented languages—centers on the treatment of generic
operations on interrelated types. Our own discussion of computational objects in Chap
ter 3 avoids these issues entirely. Readers familiar with objectoriented programming
will notice that we have much to say in chapter 3 about local state, but we do not even
mention “classes” or “inheritance.” In fact, we suspect that these problems cannot be ad
equately addressed in terms of computerlanguage design alone, without also drawing
on work in knowledge representation and automated reasoning.
270
a. With Louis’s coercion procedures installed, what hap
pens if applygeneric is called with two arguments
of type schemenumber or two arguments of type complex
for an operation that is not found in the table for those
types? For example, assume that we’ve deﬁned a generic
exponentiation operation:
(define (exp x y) (applygeneric 'exp x y))
and have put a procedure for exponentiation in the
Schemenumber package but not in any other pack
age:
;; following added to Schemenumber package
(put 'exp '(schemenumber schemenumber)
(lambda (x y) (tag (expt x y))))
; using primitive expt
What happens if we call exp with two complex num
bers as arguments?
b. Is Louis correct that something had to be done about
coercion with arguments of the same type, or does
applygeneric work correctly as is?
c. Modify applygeneric so that it doesn’t try coercion
if the two arguments have the same type.
Exercise 2.82: Show how to generalize applygeneric to
handle coercion in the general case of multiple arguments.
One strategy is to aempt to coerce all the arguments to
the type of the ﬁrst argument, then to the type of the sec
ond argument, and so on. Give an example of a situation
271
where this strategy (and likewise the twoargument ver
sion given above) is not suﬃciently general. (Hint: Con
sider the case where there are some suitable mixedtype
operations present in the table that will not be tried.)
Exercise 2.83: Suppose you are designing a generic arith
metic system for dealing with the tower of types shown in
Figure 2.25: integer, rational, real, complex. For each type
(except complex), design a procedure that raises objects of
that type one level in the tower. Show how to install a
generic raise operation that will work for each type (ex
cept complex).
Exercise 2.84: Using the raise operation of Exercise 2.83,
modify the applygeneric procedure so that it coerces its
arguments to have the same type by the method of succes
sive raising, as discussed in this section. You will need to
devise a way to test which of two types is higher in the
tower. Do this in a manner that is “compatible” with the
rest of the system and will not lead to problems in adding
new levels to the tower.
Exercise 2.85: is section mentioned a method for “sim
plifying” a data object by lowering it in the tower of types
as far as possible. Design a procedure drop that accom
plishes this for the tower described in Exercise 2.83. e
key is to decide, in some general way, whether an object
can be lowered. For example, the complex number 1:5 + 0i
can be lowered as far as real, the complex number 1 + 0i
can be lowered as far as integer, and the complex number
272
2 + 3i cannot be lowered at all. Here is a plan for determin
ing whether an object can be lowered: Begin by deﬁning
a generic operation project that “pushes” an object down
in the tower. For example, projecting a complex number
would involve throwing away the imaginary part. en a
number can be dropped if, when we project it and raise
the result back to the type we started with, we end up with
something equal to what we started with. Show how to im
plement this idea in detail, by writing a drop procedure that
drops an object as far as possible. You will need to design
the various projection operations53 and install project as a
generic operation in the system. You will also need to make
use of a generic equality predicate, such as described in
Exercise 2.79. Finally, use drop to rewrite applygeneric
from Exercise 2.84 so that it “simpliﬁes” its answers.
Exercise 2.86: Suppose we want to handle complex num
bers whose real parts, imaginary parts, magnitudes, and an
gles can be either ordinary numbers, rational numbers, or
other numbers we might wish to add to the system. De
scribe and implement the changes to the system needed to
accommodate this. You will have to deﬁne operations such
as sine and cosine that are generic over ordinary numbers
and rational numbers.
53A real number can be projected to an integer using the round primitive, which
returns the closest integer to its argument.
273
2.5.3 Example: Symbolic Algebra
e manipulation of symbolic algebraic expressions is a complex pro
cess that illustrates many of the hardest problems that occur in the de
sign of largescale systems. An algebraic expression, in general, can
be viewed as a hierarchical structure, a tree of operators applied to
operands. We can construct algebraic expressions by starting with a
set of primitive objects, such as constants and variables, and combining
these by means of algebraic operators, such as addition and multipli
cation. As in other languages, we form abstractions that enable us to
refer to compound objects in simple terms. Typical abstractions in sym
bolic algebra are ideas such as linear combination, polynomial, rational
function, or trigonometric function. We can regard these as compound
“types,” which are oen useful for directing the processing of expres
sions. For example, we could describe the expression
x 2 sin(y2 + 1) + x cos 2y + cos(y3 (cid:0) 2y2)
as a polynomial in x with coeﬃcients that are trigonometric functions
of polynomials in y whose coeﬃcients are integers.
We will not aempt to develop a complete algebraicmanipulation
system here. Such systems are exceedingly complex programs, embody
ing deep algebraic knowledge and elegant algorithms. What we will do
is look at a simple but important part of algebraic manipulation: the
arithmetic of polynomials. We will illustrate the kinds of decisions the
designer of such a system faces, and how to apply the ideas of abstract
data and generic operations to help organize this eﬀort.
Arithmetic on polynomials
Our ﬁrst task in designing a system for performing arithmetic on poly
nomials is to decide just what a polynomial is. Polynomials are normally
274
deﬁned relative to certain variables (the indeterminates of the polyno
mial). For simplicity, we will restrict ourselves to polynomials having
just one indeterminate (univariate polynomials).54 We will deﬁne a poly
nomial to be a sum of terms, each of which is either a coeﬃcient, a
power of the indeterminate, or a product of a coeﬃcient and a power
of the indeterminate. A coeﬃcient is deﬁned as an algebraic expression
that is not dependent upon the indeterminate of the polynomial. For
example,
5x 2 + 3x + 7
is a simple polynomial in x, and
(y2 + 1)x 3 + (2y)x + 1
is a polynomial in x whose coeﬃcients are polynomials in y.
Already we are skirting some thorny issues. Is the ﬁrst of these poly
nomials the same as the polynomial 5y2 + 3y + 7, or not? A reasonable
answer might be “yes, if we are considering a polynomial purely as a
mathematical function, but no, if we are considering a polynomial to
be a syntactic form.” e second polynomial is algebraically equivalent
to a polynomial in y whose coeﬃcients are polynomials in x. Should
our system recognize this, or not? Furthermore, there are other ways to
represent a polynomial—for example, as a product of factors, or (for a
univariate polynomial) as the set of roots, or as a listing of the values of
the polynomial at a speciﬁed set of points.55 We can ﬁnesse these ques
54On the other hand, we will allow polynomials whose coeﬃcients are themselves
polynomials in other variables. is will give us essentially the same representational
power as a full multivariate system, although it does lead to coercion problems, as
discussed below.
55For univariate polynomials, giving the value of a polynomial at a given set of points
can be a particularly good representation. is makes polynomial arithmetic extremely
275
tions by deciding that in our algebraicmanipulation system a “polyno
mial” will be a particular syntactic form, not its underlying mathemat
ical meaning.
Now we must consider how to go about doing arithmetic on polyno
mials. In this simple system, we will consider only addition and multi
plication. Moreover, we will insist that two polynomials to be combined
must have the same indeterminate.
We will approach the design of our system by following the familiar
discipline of data abstraction. We will represent polynomials using a
data structure called a poly, which consists of a variable and a collection
of terms. We assume that we have selectors variable and termlist
that extract those parts from a poly and a constructor makepoly that
assembles a poly from a given variable and a term list. A variable will be
just a symbol, so we can use the samevariable? procedure of Section
2.3.2 to compare variables. e following procedures deﬁne addition and
multiplication of polys:
(define (addpoly p1 p2)
(if (samevariable? (variable p1) (variable p2))
(makepoly (variable p1)
(addterms (termlist p1) (termlist p2)))
(error "Polys not in same var: ADDPOLY" (list p1 p2))))
(define (mulpoly p1 p2)
(if (samevariable? (variable p1) (variable p2))
(makepoly (variable p1)
(multerms (termlist p1) (termlist p2)))
(error "Polys not in same var: MULPOLY" (list p1 p2))))
simple. To obtain, for example, the sum of two polynomials represented in this way,
we need only add the values of the polynomials at corresponding points. To transform
back to a more familiar representation, we can use the Lagrange interpolation formula,
which shows how to recover the coeﬃcients of a polynomial of degree n given the
values of the polynomial at n + 1 points.
276
To incorporate polynomials into our generic arithmetic system, we need
to supply them with type tags. We’ll use the tag polynomial, and install
appropriate operations on tagged polynomials in the operation table.
We’ll embed all our code in an installation procedure for the polynomial
package, similar to the ones in Section 2.5.1:
(define (installpolynomialpackage)
;; internal procedures
;; representation of poly
(define (makepoly variable termlist) (cons variable termlist))
(define (variable p) (car p))
(define (termlist p) (cdr p))
⟨procedures samevariable? and variable? from section 2.3.2⟩
;; representation of terms and term lists
⟨procedures adjointerm : : : coeff from text below⟩
(define (addpoly p1 p2) : : :)
⟨procedures used by addpoly⟩
(define (mulpoly p1 p2) : : :)
⟨procedures used by mulpoly⟩
;; interface to rest of the system
(define (tag p) (attachtag 'polynomial p))
(put 'add '(polynomial polynomial)
(lambda (p1 p2) (tag (addpoly p1 p2))))
(put 'mul '(polynomial polynomial)
(lambda (p1 p2) (tag (mulpoly p1 p2))))
(put 'make 'polynomial
(lambda (var terms) (tag (makepoly var terms))))
'done)
Polynomial addition is performed termwise. Terms of the same order
(i.e., with the same power of the indeterminate) must be combined. is
is done by forming a new term of the same order whose coeﬃcient is the
sum of the coeﬃcients of the addends. Terms in one addend for which
277
there are no terms of the same order in the other addend are simply
accumulated into the sum polynomial being constructed.
In order to manipulate term lists, we will assume that we have a
constructor theemptytermlist that returns an empty term list and
a constructor adjointerm that adjoins a new term to a term list. We
will also assume that we have a predicate emptytermlist? that tells if a
given term list is empty, a selector firstterm that extracts the highest
order term from a term list, and a selector restterms that returns all
but the highestorder term. To manipulate terms, we will suppose that
we have a constructor maketerm that constructs a term with given or
der and coeﬃcient, and selectors order and coeff that return, respec
tively, the order and the coeﬃcient of the term. ese operations allow
us to consider both terms and term lists as data abstractions, whose
concrete representations we can worry about separately.
Here is the procedure that constructs the term list for the sum of
two polynomials:56
(define (addterms L1 L2)
(cond ((emptytermlist? L1) L2)
((emptytermlist? L2) L1)
(else
(let ((t1 (firstterm L1))
(t2 (firstterm L2)))
(cond ((> (order t1) (order t2))
(adjointerm
t1 (addterms (restterms L1) L2)))
((< (order t1) (order t2))
56is operation is very much like the ordered unionset operation we developed
in Exercise 2.62. In fact, if we think of the terms of the polynomial as a set ordered
according to the power of the indeterminate, then the program that produces the term
list for a sum is almost identical to unionset.
278
(adjointerm
t2 (addterms L1 (restterms L2))))
(else
(adjointerm
(maketerm (order t1)
(add (coeff t1) (coeff t2)))
(addterms (restterms L1)
(restterms L2)))))))))
e most important point to note here is that we used the generic ad
dition procedure add to add together the coeﬃcients of the terms being
combined. is has powerful consequences, as we will see below.
In order to multiply two term lists, we multiply each term of the
ﬁrst list by all the terms of the other list, repeatedly using multerm
byallterms, which multiplies a given term by all terms in a given
term list. e resulting term lists (one for each term of the ﬁrst list) are
accumulated into a sum. Multiplying two terms forms a term whose
order is the sum of the orders of the factors and whose coeﬃcient is the
product of the coeﬃcients of the factors:
(define (multerms L1 L2)
(if (emptytermlist? L1)
(theemptytermlist)
(addterms (multermbyallterms (firstterm L1) L2)
(multerms (restterms L1) L2))))
(define (multermbyallterms t1 L)
(if (emptytermlist? L)
(theemptytermlist)
(let ((t2 (firstterm L)))
(adjointerm
(maketerm (+ (order t1) (order t2))
(mul (coeff t1) (coeff t2)))
(multermbyallterms t1 (restterms L))))))
279
is is really all there is to polynomial addition and multiplication. No
tice that, since we operate on terms using the generic procedures add
and mul, our polynomial package is automatically able to handle any
type of coeﬃcient that is known about by the generic arithmetic pack
age. If we include a coercion mechanism such as one of those discussed
in Section 2.5.2, then we also are automatically able to handle operations
on polynomials of diﬀerent coeﬃcient types, such as
[
]
[3x 2 + (2 + 3i)x + 7] (cid:1)
x 4 +
x 2 + (5 + 3i)
:
2
3
Because we installed the polynomial addition and multiplication proce
dures addpoly and mulpoly in the generic arithmetic system as the
add and mul operations for type polynomial, our system is also auto
matically able to handle polynomial operations such as
[
]
(y + 1)x 2 + (y2 + 1)x + (y (cid:0) 1)
(cid:1)
[
]
(y (cid:0) 2)x + (y3 + 7)
:
e reason is that when the system tries to combine coeﬃcients, it will
dispatch through add and mul. Since the coeﬃcients are themselves
polynomials (in y), these will be combined using addpoly and mul
poly. e result is a kind of “datadirected recursion” in which, for ex
ample, a call to mulpoly will result in recursive calls to mulpoly in
order to multiply the coeﬃcients. If the coeﬃcients of the coeﬃcients
were themselves polynomials (as might be used to represent polynomi
als in three variables), the data direction would ensure that the system
would follow through another level of recursive calls, and so on through
as many levels as the structure of the data dictates.57
57To make this work completely smoothly, we should also add to our generic arith
metic system the ability to coerce a “number” to a polynomial by regarding it as a
280
Representing term lists
Finally, we must confront the job of implementing a good representa
tion for term lists. A term list is, in eﬀect, a set of coeﬃcients keyed
by the order of the term. Hence, any of the methods for representing
sets, as discussed in Section 2.3.3, can be applied to this task. On the
other hand, our procedures addterms and multerms always access
term lists sequentially from highest to lowest order. us, we will use
some kind of ordered list representation.
How should we structure the list that represents a term list? One
consideration is the “density” of the polynomials we intend to manip
ulate. A polynomial is said to be dense if it has nonzero coeﬃcients in
terms of most orders. If it has many zero terms it is said to be sparse. For
example,
x 5 + 2x 4 + 3x 2 (cid:0) 2x (cid:0) 5
A :
is a dense polynomial, whereas
B :
x 100 + 2x 2 + 1
is sparse.
e term lists of dense polynomials are most eﬃciently represented
as lists of the coeﬃcients. For example, A above would be nicely rep
resented as (1 2 0 3 2 5). e order of a term in this representa
tion is the length of the sublist beginning with that term’s coeﬃcient,
polynomial of degree zero whose coeﬃcient is the number. is is necessary if we are
going to perform operations such as
[x 2 + (y + 1)x + 5] + [x 2 + 2x + 1];
which requires adding the coeﬃcient y + 1 to the coeﬃcient 2.
281
decremented by 1.58 is would be a terrible representation for a sparse
polynomial such as B: ere would be a giant list of zeros punctuated
by a few lonely nonzero terms. A more reasonable representation of the
term list of a sparse polynomial is as a list of the nonzero terms, where
each term is a list containing the order of the term and the coeﬃcient
for that order. In such a scheme, polynomial B is eﬃciently represented
as ((100 1) (2 2) (0 1)). As most polynomial manipulations are
performed on sparse polynomials, we will use this method. We will as
sume that term lists are represented as lists of terms, arranged from
highestorder to lowestorder term. Once we have made this decision,
implementing the selectors and constructors for terms and term lists is
straightforward:59
(define (adjointerm term termlist)
(if (=zero? (coeff term))
termlist
(cons term termlist)))
(define (theemptytermlist) '())
(define (firstterm termlist) (car termlist))
(define (restterms termlist) (cdr termlist))
(define (emptytermlist? termlist) (null? termlist))
(define (maketerm order coeff) (list order coeff))
58In these polynomial examples, we assume that we have implemented the generic
arithmetic system using the type mechanism suggested in Exercise 2.78. us, coeﬃ
cients that are ordinary numbers will be represented as the numbers themselves rather
than as pairs whose car is the symbol schemenumber.
59Although we are assuming that term lists are ordered, we have implemented ad
jointerm to simply cons the new term onto the existing term list. We can get away
with this so long as we guarantee that the procedures (such as addterms) that use ad
jointerm always call it with a higherorder term than appears in the list. If we did not
want to make such a guarantee, we could have implemented adjointerm to be simi
lar to the adjoinset constructor for the orderedlist representation of sets (Exercise
2.61).
282
(define (order term) (car term))
(define (coeff term) (cadr term))
where =zero? is as deﬁned in Exercise 2.80. (See also Exercise 2.87 be
low.)
Users of the polynomial package will create (tagged) polynomials
by means of the procedure:
(define (makepolynomial var terms)
((get 'make 'polynomial) var terms))
Exercise 2.87: Install =zero? for polynomials in the generic
arithmetic package. is will allow adjointerm to work
for polynomials with coeﬃcients that are themselves poly
nomials.
Exercise 2.88: Extend the polynomial system to include
subtraction of polynomials. (Hint: You may ﬁnd it helpful
to deﬁne a generic negation operation.)
Exercise 2.89: Deﬁne procedures that implement the term
list representation described above as appropriate for dense
polynomials.
Exercise 2.90: Suppose we want to have a polynomial sys
tem that is eﬃcient for both sparse and dense polynomials.
One way to do this is to allow both kinds of termlist repre
sentations in our system. e situation is analogous to the
complexnumber example of Section 2.4, where we allowed
both rectangular and polar representations. To do this we
must distinguish diﬀerent types of term lists and make the
operations on term lists generic. Redesign the polynomial
283
system to implement this generalization. is is a major ef
fort, not a local change.
Exercise 2.91: A univariate polynomial can be divided by
another one to produce a polynomial quotient and a poly
nomial remainder. For example,
x 5 (cid:0) 1
x 2 (cid:0) 1
= x 3 + x ; remainder x (cid:0) 1:
Division can be performed via long division. at is, divide
the highestorder term of the dividend by the highestorder
term of the divisor. e result is the ﬁrst term of the quo
tient. Next, multiply the result by the divisor, subtract that
from the dividend, and produce the rest of the answer by re
cursively dividing the diﬀerence by the divisor. Stop when
the order of the divisor exceeds the order of the dividend
and declare the dividend to be the remainder. Also, if the
dividend ever becomes zero, return zero as both quotient
and remainder.
We can design a divpoly procedure on the model of add
poly and mulpoly. e procedure checks to see if the two
polys have the same variable. If so, divpoly strips oﬀ the
variable and passes the problem to divterms, which per
forms the division operation on term lists. divpoly ﬁnally
reaaches the variable to the result supplied by divterms.
It is convenient to design divterms to compute both the
quotient and the remainder of a division. divterms can
take two term lists as arguments and return a list of the
quotient term list and the remainder term list.
284
Complete the following deﬁnition of divterms by ﬁlling
in the missing expressions. Use this to implement divpoly,
which takes two polys as arguments and returns a list of the
quotient and remainder polys.
(define (divterms L1 L2)
(if (emptytermlist? L1)
(list (theemptytermlist) (theemptytermlist))
(let ((t1 (firstterm L1))
(t2 (firstterm L2)))
(if (> (order t2) (order t1))
(list (theemptytermlist) L1)
(let ((newc (div (coeff t1) (coeff t2)))
(newo ( (order t1) (order t2))))
(let ((restofresult
⟨form complete result⟩ ))))))
⟨compute rest of result recursively⟩ ))
Hierarchies of types in symbolic algebra
Our polynomial system illustrates how objects of one type (polynomi
als) may in fact be complex objects that have objects of many diﬀerent
types as parts. is poses no real diﬃculty in deﬁning generic opera
tions. We need only install appropriate generic operations for perform
ing the necessary manipulations of the parts of the compound types.
In fact, we saw that polynomials form a kind of “recursive data abstrac
tion,” in that parts of a polynomial may themselves be polynomials. Our
generic operations and our datadirected programming style can handle
this complication without much trouble.
On the other hand, polynomial algebra is a system for which the
data types cannot be naturally arranged in a tower. For instance, it is
possible to have polynomials in x whose coeﬃcients are polynomials
in y. It is also possible to have polynomials in y whose coeﬃcients are
285
polynomials in x. Neither of these types is “above” the other in any
natural way, yet it is oen necessary to add together elements from
each set. ere are several ways to do this. One possibility is to convert
one polynomial to the type of the other by expanding and rearrang
ing terms so that both polynomials have the same principal variable.
One can impose a towerlike structure on this by ordering the variables
and thus always converting any polynomial to a “canonical form” with
the highestpriority variable dominant and the lowerpriority variables
buried in the coeﬃcients. is strategy works fairly well, except that
the conversion may expand a polynomial unnecessarily, making it hard
to read and perhaps less eﬃcient to work with. e tower strategy is
certainly not natural for this domain or for any domain where the user
can invent new types dynamically using old types in various combining
forms, such as trigonometric functions, power series, and integrals.
It should not be surprising that controlling coercion is a serious
problem in the design of largescale algebraicmanipulation systems.
Much of the complexity of such systems is concerned with relationships
among diverse types. Indeed, it is fair to say that we do not yet com
pletely understand coercion. In fact, we do not yet completely under
stand the concept of a data type. Nevertheless, what we know provides
us with powerful structuring and modularity principles to support the
design of large systems.
Exercise 2.92: By imposing an ordering on variables, ex
tend the polynomial package so that addition and multipli
cation of polynomials works for polynomials in diﬀerent
variables. (is is not easy!)
286
Extended exercise: Rational functions
We can extend our generic arithmetic system to include rational func
tions. ese are “fractions” whose numerator and denominator are poly
nomials, such as
x + 1
x 3 (cid:0) 1
:
e system should be able to add, subtract, multiply, and divide rational
functions, and to perform such computations as
x + 1
x 3 (cid:0) 1
+
x
x 2 (cid:0) 1
=
x 3 + 2x 2 + 3x + 1
x 4 + x 3 (cid:0) x (cid:0) 1
:
(Here the sum has been simpliﬁed by removing common factors. Ordi
nary “cross multiplication” would have produced a fourthdegree poly
nomial over a ﬁhdegree polynomial.)
If we modify our rationalarithmetic package so that it uses generic
operations, then it will do what we want, except for the problem of
reducing fractions to lowest terms.
Exercise 2.93: Modify the rationalarithmetic package to
use generic operations, but change makerat so that it does
not aempt to reduce fractions to lowest terms. Test your
system by calling makerational on two polynomials to
produce a rational function:
(define p1 (makepolynomial 'x '((2 1) (0 1))))
(define p2 (makepolynomial 'x '((3 1) (0 1))))
(define rf (makerational p2 p1))
Now add rf to itself, using add. You will observe that this
addition procedure does not reduce fractions to lowest terms.
287
We can reduce polynomial fractions to lowest terms using the same idea
we used with integers: modifying makerat to divide both the numera
tor and the denominator by their greatest common divisor. e notion
of “greatest common divisor” makes sense for polynomials. In fact, we
can compute the of two polynomials using essentially the same
Euclid’s Algorithm that works for integers.60 e integer version is
(define (gcd a b)
(if (= b 0)
a
(gcd b (remainder a b))))
Using this, we could make the obvious modiﬁcation to deﬁne a
operation that works on term lists:
(define (gcdterms a b)
(if (emptytermlist? b)
a
(gcdterms b (remainderterms a b))))
where remainderterms picks out the remainder component of the list
returned by the termlist division operation divterms that was imple
mented in Exercise 2.91.
60e fact that Euclid’s Algorithm works for polynomials is formalized in algebra
by saying that polynomials form a kind of algebraic domain called a Euclidean ring. A
Euclidean ring is a domain that admits addition, subtraction, and commutative mul
tiplication, together with a way of assigning to each element x of the ring a positive
integer “measure” m(x) with the properties that m(xy) (cid:21) m(x) for any nonzero x and
y and that, given any x and y, there exists a q such that y = qx + r and either r = 0
or m(r) < m(x). From an abstract point of view, this is what is needed to prove that
Euclid’s Algorithm works. For the domain of integers, the measure m of an integer is
the absolute value of the integer itself. For the domain of polynomials, the measure of
a polynomial is its degree.
288
Exercise 2.94: Using divterms, implement the procedure
remainderterms and use this to deﬁne gcdterms as above.
Now write a procedure gcdpoly that computes the poly
nomial of two polys. (e procedure should signal an
error if the two polys are not in the same variable.) Install in
the system a generic operation greatestcommondivisor
that reduces to gcdpoly for polynomials and to ordinary
gcd for ordinary numbers. As a test, try
(define p1 (makepolynomial
'x '((4 1) (3 1) (2 2) (1 2))))
(define p2 (makepolynomial 'x '((3 1) (1 1))))
(greatestcommondivisor p1 p2)
and check your result by hand.
Exercise 2.95: Deﬁne P1, P2, and P3 to be the polynomials
x 2 (cid:0) 2x + 1;
11x 2 + 7;
13x + 5:
P1 :
P2 :
P3 :
Now deﬁne Q1 to be the product of P1 and P2 and Q2 to
be the product of P1 and P3, and use greatestcommon
divisor (Exercise 2.94) to compute the of Q1 and Q2.
Note that the answer is not the same as P1. is example in
troduces noninteger operations into the computation, caus
ing diﬃculties with the algorithm.61 To understand
61In an implementation like Scheme, this produces a polynomial that is indeed
a divisor of Q1 and Q2, but with rational coeﬃcients. In many other Scheme systems,
in which division of integers can produce limitedprecision decimal numbers, we may
fail to get a valid divisor.
289
what is happening, try tracing gcdterms while comput
ing the or try performing the division by hand.
We can solve the problem exhibited in Exercise 2.95 if we use the follow
ing modiﬁcation of the algorithm (which really works only in the
case of polynomials with integer coeﬃcients). Before performing any
polynomial division in the computation, we multiply the dividend
by an integer constant factor, chosen to guarantee that no fractions will
arise during the division process. Our answer will thus diﬀer from the
actual by an integer constant factor, but this does not maer in the
case of reducing rational functions to lowest terms; the will be used
to divide both the numerator and denominator, so the integer constant
factor will cancel out.
More precisely, if P and Q are polynomials, let O1 be the order of P
(i.e., the order of the largest term of P) and let O2 be the order of Q. Let c
be the leading coeﬃcient of Q. en it can be shown that, if we multiply
P by the integerizing factor c1+O1(cid:0)O2, the resulting polynomial can be
divided by Q by using the divterms algorithm without introducing any
fractions. e operation of multiplying the dividend by this constant
and then dividing is sometimes called the pseudodivision of P by Q. e
remainder of the division is called the pseudoremainder.
Exercise 2.96:
a. Implement the procedure pseudoremainderterms, which
is just like remainderterms except that it multiplies
the dividend by the integerizing factor described above
before calling divterms. Modify gcdterms to use
pseudoremainderterms, and verify that greatest
commondivisor now produces an answer with inte
ger coeﬃcients on the example in Exercise 2.95.
290
b. e now has integer coeﬃcients, but they are
larger than those of P1. Modify gcdterms so that it
removes common factors from the coeﬃcients of the
answer by dividing all the coeﬃcients by their (inte
ger) greatest common divisor.
us, here is how to reduce a rational function to lowest terms:
• Compute the of the numerator and denominator, using the
version of gcdterms from Exercise 2.96.
• When you obtain the , multiply both numerator and denomi
nator by the same integerizing factor before dividing through by
the , so that division by the will not introduce any nonin
teger coeﬃcients. As the factor you can use the leading coeﬃcient
of the raised to the power 1 + O1 (cid:0) O2, where O2 is the order
of the and O1 is the maximum of the orders of the numerator
and denominator. is will ensure that dividing the numerator
and denominator by the will not introduce any fractions.
• e result of this operation will be a numerator and denominator
with integer coeﬃcients. e coeﬃcients will normally be very
large because of all of the integerizing factors, so the last step is to
remove the redundant factors by computing the (integer) greatest
common divisor of all the coeﬃcients of the numerator and the
denominator and dividing through by this factor.
Exercise 2.97:
a. Implement this algorithm as a procedure reduceterms
that takes two term lists n and d as arguments and re
291
turns a list nn, dd, which are n and d reduced to low
est terms via the algorithm given above. Also write a
procedure reducepoly, analogous to addpoly, that
checks to see if the two polys have the same variable.
If so, reducepoly strips oﬀ the variable and passes
the problem to reduceterms, then reaaches the vari
able to the two term lists supplied by reduceterms.
b. Deﬁne a procedure analogous to reduceterms that
does what the original makerat did for integers:
(define (reduceintegers n d)
(let ((g (gcd n d)))
(list (/ n g) (/ d g))))
and deﬁne reduce as a generic operation that calls
applygeneric to dispatch to either reducepoly (for
polynomial arguments) or reduceintegers (for scheme
number arguments). You can now easily make the rational
arithmetic package reduce fractions to lowest terms
by having makerat call reduce before combining the
given numerator and denominator to form a ratio
nal number. e system now handles rational expres
sions in either integers or polynomials. To test your
program, try the example at the beginning of this ex
tended exercise:
p1 (makepolynomial 'x '((1 1) (0
1))))
p2 (makepolynomial 'x '((3 1) (0 1))))
p3 (makepolynomial 'x '((1 1))))
p4 (makepolynomial 'x '((2 1) (0 1))))
(define
(define
(define
(define
(define rf1 (makerational p1 p2))
(define rf2 (makerational p3 p4))
292
(add rf1 rf2)
See if you get the correct answer, correctly reduced to
lowest terms.
e computation is at the heart of any system that does opera
tions on rational functions. e algorithm used above, although mathe
matically straightforward, is extremely slow. e slowness is due partly
to the large number of division operations and partly to the enormous
size of the intermediate coeﬃcients generated by the pseudodivisions.
One of the active areas in the development of algebraicmanipulation
systems is the design of beer algorithms for computing polynomial
s.62
62One extremely eﬃcient and elegant method for computing polynomial s was
discovered by Richard Zippel (1979). e method is a probabilistic algorithm, as is the
fast test for primality that we discussed in Chapter 1. Zippel’s book (Zippel 1993) de
scribes this method, together with other ways to compute polynomial s.
293
Modularity, Objects, and State
Mεταβάλλον ὰναπαύεται
(Even while it changes, it stands still.)
—Heraclitus
Plus ça change, plus c’est la même chose.
—Alphonse Karr
T introduced the basic elements from which
programs are made. We saw how primitive procedures and primi
tive data are combined to construct compound entities, and we learned
that abstraction is vital in helping us to cope with the complexity of
large systems. But these tools are not suﬃcient for designing programs.
Eﬀective program synthesis also requires organizational principles that
can guide us in formulating the overall design of a program. In partic
ular, we need strategies to help us structure large systems so that they
294
will be modular, that is, so that they can be divided “naturally” into co
herent parts that can be separately developed and maintained.
One powerful design strategy, which is particularly appropriate to
the construction of programs for modeling physical systems, is to base
the structure of our programs on the structure of the system being mod
eled. For each object in the system, we construct a corresponding com
putational object. For each system action, we deﬁne a symbolic opera
tion in our computational model. Our hope in using this strategy is that
extending the model to accommodate new objects or new actions will
require no strategic changes to the program, only the addition of the
new symbolic analogs of those objects or actions. If we have been suc
cessful in our system organization, then to add a new feature or debug
an old one we will have to work on only a localized part of the system.
To a large extent, then, the way we organize a large program is dic
tated by our perception of the system to be modeled. In this chapter we
will investigate two prominent organizational strategies arising from
two rather diﬀerent “world views” of the structure of systems. e ﬁrst
organizational strategy concentrates on objects, viewing a large system
as a collection of distinct objects whose behaviors may change over
time. An alternative organizational strategy concentrates on the streams
of information that ﬂow in the system, much as an electrical engineer
views a signalprocessing system.
Both the objectbased approach and the streamprocessing approach
raise signiﬁcant linguistic issues in programming. With objects, we must
be concerned with how a computational object can change and yet main
tain its identity. is will force us to abandon our old substitution model
of computation (Section 1.1.5) in favor of a more mechanistic but less
theoretically tractable environment model of computation. e diﬃcul
ties of dealing with objects, change, and identity are a fundamental con
295
sequence of the need to grapple with time in our computational models.
ese diﬃculties become even greater when we allow the possibility of
concurrent execution of programs. e stream approach can be most
fully exploited when we decouple simulated time in our model from the
order of the events that take place in the computer during evaluation.
We will accomplish this using a technique known as delayed evaluation.
3.1 Assignment and Local State
We ordinarily view the world as populated by independent objects, each
of which has a state that changes over time. An object is said to “have
state” if its behavior is inﬂuenced by its history. A bank account, for
example, has state in that the answer to the question “Can I withdraw
$100?” depends upon the history of deposit and withdrawal transac
tions. We can characterize an object’s state by one or more state vari
ables, which among them maintain enough information about history
to determine the object’s current behavior. In a simple banking system,
we could characterize the state of an account by a current balance rather
than by remembering the entire history of account transactions.
In a system composed of many objects, the objects are rarely com
pletely independent. Each may inﬂuence the states of others through
interactions, which serve to couple the state variables of one object to
those of other objects. Indeed, the view that a system is composed of
separate objects is most useful when the state variables of the system
can be grouped into closely coupled subsystems that are only loosely
coupled to other subsystems.
is view of a system can be a powerful framework for organizing
computational models of the system. For such a model to be modular, it
should be decomposed into computational objects that model the actual
296
objects in the system. Each computational object must have its own lo
cal state variables describing the actual object’s state. Since the states of
objects in the system being modeled change over time, the state vari
ables of the corresponding computational objects must also change. If
we choose to model the ﬂow of time in the system by the elapsed time
in the computer, then we must have a way to construct computational
objects whose behaviors change as our programs run. In particular, if
we wish to model state variables by ordinary symbolic names in the
programming language, then the language must provide an assignment
operator to enable us to change the value associated with a name.
3.1.1 Local State Variables
To illustrate what we mean by having a computational object with time
varying state, let us model the situation of withdrawing money from a
bank account. We will do this using a procedure withdraw, which takes
as argument an amount to be withdrawn. If there is enough money in
the account to accommodate the withdrawal, then withdraw should re
turn the balance remaining aer the withdrawal. Otherwise, withdraw
should return the message Insuﬃcient funds. For example, if we begin
with $100 in the account, we should obtain the following sequence of
responses using withdraw:
(withdraw 25)
75
(withdraw 25)
50
(withdraw 60)
"Insufficient funds"
(withdraw 15)
35
297
Observe that the expression (withdraw 25), evaluated twice, yields
diﬀerent values. is is a new kind of behavior for a procedure. Until
now, all our procedures could be viewed as speciﬁcations for comput
ing mathematical functions. A call to a procedure computed the value of
the function applied to the given arguments, and two calls to the same
procedure with the same arguments always produced the same result.1
To implement withdraw, we can use a variable balance to indicate
the balance of money in the account and deﬁne withdraw as a procedure
that accesses balance. e withdraw procedure checks to see if balance
is at least as large as the requested amount. If so, withdraw decrements
balance by amount and returns the new value of balance. Otherwise,
withdraw returns the Insuﬃcient funds message. Here are the deﬁnitions
of balance and withdraw:
(define balance 100)
(define (withdraw amount)
(if (>= balance amount)
(begin (set! balance ( balance amount))
balance)
"Insufficient funds"))
Decrementing balance is accomplished by the expression
(set! balance ( balance amount))
is uses the set! special form, whose syntax is
(set! ⟨name⟩ ⟨newvalue⟩)
1Actually, this is not quite true. One exception was the randomnumber generator
in Section 1.2.6. Another exception involved the operation/type tables we introduced in
Section 2.4.3, where the values of two calls to get with the same arguments depended
on intervening calls to put. On the other hand, until we introduce assignment, we have
no way to create such procedures ourselves.
298
Here⟨name⟩ is a symbol and⟨newvalue⟩ is any expression. set! changes
⟨name⟩ so that its value is the result obtained by evaluating ⟨newvalue⟩.
In the case at hand, we are changing balance so that its new value will
be the result of subtracting amount from the previous value of balance.2
withdraw also uses the begin special form to cause two expressions
to be evaluated in the case where the if test is true: ﬁrst decrementing
balance and then returning the value of balance. In general, evaluating
the expression
(begin ⟨exp1⟩ ⟨exp2⟩ : : : ⟨expk⟩)
causes the expressions ⟨exp1⟩ through ⟨expk⟩ to be evaluated in se
quence and the value of the ﬁnal expression ⟨expk⟩ to be returned as
the value of the entire begin form.3
Although withdraw works as desired, the variable balance presents
a problem. As speciﬁed above, balance is a name deﬁned in the global
environment and is freely accessible to be examined or modiﬁed by any
procedure. It would be much beer if we could somehow make balance
internal to withdraw, so that withdraw would be the only procedure
that could access balance directly and any other procedure could access
balance only indirectly (through calls to withdraw). is would more
accurately model the notion that balance is a local state variable used
2e value of a set! expression is implementationdependent. set! should be used
only for its eﬀect, not for its value.
e name set! reﬂects a naming convention used in Scheme: Operations that change
the values of variables (or that change data structures, as we will see in Section 3.3) are
given names that end with an exclamation point. is is similar to the convention of
designating predicates by names that end with a question mark.
3We have already used begin implicitly in our programs, because in Scheme the
body of a procedure can be a sequence of expressions. Also, the ⟨consequent⟩ part of
each clause in a cond expression can be a sequence of expressions rather than a single
expression.
299
by withdraw to keep track of the state of the account.
We can make balance internal to withdraw by rewriting the deﬁ
nition as follows:
(define newwithdraw
(let ((balance 100))
(lambda (amount)
(if (>= balance amount)
(begin (set! balance ( balance amount))
balance)
"Insufficient funds"))))
What we have done here is use let to establish an environment with a
local variable balance, bound to the initial value 100. Within this local
environment, we use lambda to create a procedure that takes amount as
an argument and behaves like our previous withdraw procedure. is
procedure—returned as the result of evaluating the let expression—is
newwithdraw, which behaves in precisely the same way as withdraw
but whose variable balance is not accessible by any other procedure.4
Combining set! with local variables is the general programming
technique we will use for constructing computational objects with lo
cal state. Unfortunately, using this technique raises a serious problem:
When we ﬁrst introduced procedures, we also introduced the substi
tution model of evaluation (Section 1.1.5) to provide an interpretation
of what procedure application means. We said that applying a proce
dure should be interpreted as evaluating the body of the procedure with
the formal parameters replaced by their values. e trouble is that, as
4In programminglanguage jargon, the variable balance is said to be encapsulated
within the newwithdraw procedure. Encapsulation reﬂects the general systemdesign
principle known as the hiding principle: One can make a system more modular and ro
bust by protecting parts of the system from each other; that is, by providing information
access only to those parts of the system that have a “need to know.”
300
soon as we introduce assignment into our language, substitution is no
longer an adequate model of procedure application. (We will see why
this is so in Section 3.1.3.) As a consequence, we technically have at
this point no way to understand why the newwithdraw procedure be
haves as claimed above. In order to really understand a procedure such
as newwithdraw, we will need to develop a new model of procedure ap
plication. In Section 3.2 we will introduce such a model, together with
an explanation of set! and local variables. First, however, we examine
some variations on the theme established by newwithdraw.
e following procedure, makewithdraw, creates “withdrawal pro
cessors.” e formal parameter balance in makewithdraw speciﬁes the
initial amount of money in the account.5
(define (makewithdraw balance)
(lambda (amount)
(if (>= balance amount)
(begin (set! balance ( balance amount))
balance)
"Insufficient funds")))
makewithdraw can be used as follows to create two objects W1 and W2:
(define W1 (makewithdraw 100))
(define W2 (makewithdraw 100))
(W1 50)
50
(W2 70)
30
5In contrast with newwithdraw above, we do not have to use let to make balance
a local variable, since formal parameters are already local. is will be clearer aer the
discussion of the environment model of evaluation in Section 3.2. (See also Exercise
3.10.)
301
(W2 40)
"Insufficient funds"
(W1 40)
10
Observe that W1 and W2 are completely independent objects, each with
its own local state variable balance. Withdrawals from one do not aﬀect
the other.
We can also create objects that handle deposits as well as with
drawals, and thus we can represent simple bank accounts. Here is a
procedure that returns a “bankaccount object” with a speciﬁed initial
balance:
(define (makeaccount balance)
(define (withdraw amount)
(if (>= balance amount)
(begin (set! balance ( balance amount))
balance)
"Insufficient funds"))
(define (deposit amount)
(set! balance (+ balance amount))
balance)
(define (dispatch m)
(cond ((eq? m 'withdraw) withdraw)
((eq? m 'deposit) deposit)
(else (error "Unknown request: MAKEACCOUNT"
dispatch)
m))))
Each call to makeaccount sets up an environment with a local state
variable balance. Within this environment, makeaccount deﬁnes pro
cedures deposit and withdraw that access balance and an additional
procedure dispatch that takes a “message” as input and returns one of
302
the two local procedures. e dispatch procedure itself is returned as
the value that represents the bankaccount object. is is precisely the
messagepassing style of programming that we saw in Section 2.4.3, al
though here we are using it in conjunction with the ability to modify
local variables.
makeaccount can be used as follows:
(define acc (makeaccount 100))
((acc 'withdraw) 50)
50
((acc 'withdraw) 60)
"Insufficient funds"
((acc 'deposit) 40)
90
((acc 'withdraw) 60)
30
Each call to acc returns the locally deﬁned deposit or withdraw pro
cedure, which is then applied to the speciﬁed amount. As was the case
with makewithdraw, another call to makeaccount
(define acc2 (makeaccount 100))
will produce a completely separate account object, which maintains its
own local balance.
Exercise 3.1: An accumulator is a procedure that is called
repeatedly with a single numeric argument and accumu
lates its arguments into a sum. Each time it is called, it
returns the currently accumulated sum. Write a procedure
makeaccumulator that generates accumulators, each main
taining an independent sum. e input to makeaccumulator
should specify the initial value of the sum; for example
303
(define A (makeaccumulator 5))
(A 10)
15
(A 10)
25
Exercise 3.2: In sowaretesting applications, it is useful
to be able to count the number of times a given procedure
is called during the course of a computation. Write a pro
cedure makemonitored that takes as input a procedure, f,
that itself takes one input. e result returned by make
monitored is a third procedure, say mf, that keeps track
of the number of times it has been called by maintaining
an internal counter. If the input to mf is the special symbol
howmanycalls?, then mf returns the value of the counter.
If the input is the special symbol resetcount, then mf re
sets the counter to zero. For any other input, mf returns the
result of calling f on that input and increments the counter.
For instance, we could make a monitored version of the
sqrt procedure:
(define s (makemonitored sqrt))
(s 100)
10
(s 'howmanycalls?)
1
Exercise 3.3: Modify the makeaccount procedure so that
it creates passwordprotected accounts. at is, makeaccount
should take a symbol as an additional argument, as in
(define acc (makeaccount 100 'secretpassword))
304
e resulting account object should process a request only
if it is accompanied by the password with which the ac
count was created, and should otherwise return a complaint:
((acc 'secretpassword 'withdraw) 40)
60
((acc 'someotherpassword 'deposit) 50)
"Incorrect password"
Exercise 3.4: Modify the makeaccount procedure of Ex
ercise 3.3 by adding another local state variable so that, if
an account is accessed more than seven consecutive times
with an incorrect password, it invokes the procedure call
thecops.
3.1.2 The Benefits of Introducing Assignment
As we shall see, introducing assignment into our programming lan
guage leads us into a thicket of diﬃcult conceptual issues. Nevertheless,
viewing systems as collections of objects with local state is a powerful
technique for maintaining a modular design. As a simple example, con
sider the design of a procedure rand that, whenever it is called, returns
an integer chosen at random.
It is not at all clear what is meant by “chosen at random.” What we
presumably want is for successive calls to rand to produce a sequence of
numbers that has statistical properties of uniform distribution. We will
not discuss methods for generating suitable sequences here. Rather, let
us assume that we have a procedure randupdate that has the property
that if we start with a given number x1 and form
x2 = (randupdate x1)
x3 = (randupdate x2)
305
then the sequence of values x1, x2, x3, : : : will have the desired statistical
properties.6
We can implement rand as a procedure with a local state variable
x that is initialized to some ﬁxed value randominit. Each call to rand
computes randupdate of the current value of x, returns this as the
random number, and also stores this as the new value of x.
(define rand (let ((x randominit))
(lambda ()
(set! x (randupdate x))
x)))
Of course, we could generate the same sequence of random numbers
without using assignment by simply calling randupdate directly. How
ever, this would mean that any part of our program that used random
numbers would have to explicitly remember the current value of x to
be passed as an argument to randupdate. To realize what an annoy
ance this would be, consider using random numbers to implement a
technique called Monte Carlo simulation.
e Monte Carlo method consists of choosing sample experiments
at random from a large set and then making deductions on the basis of
6One common way to implement randupdate is to use the rule that x is updated
to ax + b modulo m, where a, b, and m are appropriately chosen integers. Chapter 3
of Knuth 1981 includes an extensive discussion of techniques for generating sequences
of random numbers and establishing their statistical properties. Notice that the rand
update procedure computes a mathematical function: Given the same input twice, it
produces the same output. erefore, the number sequence produced by randupdate
certainly is not “random,” if by “random” we insist that each number in the sequence
is unrelated to the preceding number. e relation between “real randomness” and so
called pseudorandom sequences, which are produced by welldetermined computations
and yet have suitable statistical properties, is a complex question involving diﬃcult
issues in mathematics and philosophy. Kolmogorov, Solomonoﬀ, and Chaitin have made
great progress in clarifying these issues; a discussion can be found in Chaitin 1975.
306
the probabilities estimated from tabulating the results of those experi
ments. For example, we can approximate π using the fact that 6=π 2 is
the probability that two integers chosen at random will have no fac
tors in common; that is, that their greatest common divisor will be 1.7
To obtain the approximation to π, we perform a large number of ex
periments. In each experiment we choose two integers at random and
perform a test to see if their is 1. e fraction of times that the test
is passed gives us our estimate of 6=π 2, and from this we obtain our
approximation to π.
e heart of our program is a procedure montecarlo, which takes
as arguments the number of times to try an experiment, together with
the experiment, represented as a noargument procedure that will re
turn either true or false each time it is run. montecarlo runs the exper
iment for the designated number of trials and returns a number telling
the fraction of the trials in which the experiment was found to be true.
(define (estimatepi trials)
(sqrt (/ 6 (montecarlo trials cesarotest))))
(define (cesarotest)
(= (gcd (rand) (rand)) 1))
(define (montecarlo trials experiment)
(define (iter trialsremaining trialspassed)
(cond ((= trialsremaining 0)
(/ trialspassed trials))
((experiment)
(iter ( trialsremaining 1)
(+ trialspassed 1)))
(else
7is theorem is due to E. Cesàro. See section 4.5.2 of Knuth 1981 for a discussion
and a proof.
307
(iter ( trialsremaining 1)
trialspassed))))
(iter trials 0))
Now let us try the same computation using randupdate directly rather
than rand, the way we would be forced to proceed if we did not use
assignment to model local state:
(define (estimatepi trials)
(sqrt (/ 6 (randomgcdtest trials randominit))))
(define (randomgcdtest trials initialx)
(define (iter trialsremaining trialspassed x)
(let ((x1 (randupdate x)))
(let ((x2 (randupdate x1)))
(cond ((= trialsremaining 0)
(/ trialspassed trials))
((= (gcd x1 x2) 1)
(iter ( trialsremaining 1)
(+ trialspassed 1)
x2))
(else
(iter ( trialsremaining 1)
trialspassed
x2))))))
(iter trials 0 initialx))
While the program is still simple, it betrays some painful breaches of
modularity. In our ﬁrst version of the program, using rand, we can ex
press the Monte Carlo method directly as a general montecarlo proce
dure that takes as an argument an arbitrary experiment procedure. In
our second version of the program, with no local state for the random
number generator, randomgcdtest must explicitly manipulate the ran
dom numbers x1 and x2 and recycle x2 through the iterative loop as
the new input to randupdate. is explicit handling of the random
308
numbers intertwines the structure of accumulating test results with the
fact that our particular experiment uses two random numbers, whereas
other Monte Carlo experiments might use one random number or three.
Even the toplevel procedure estimatepi has to be concerned with
supplying an initial random number. e fact that the randomnumber
generator’s insides are leaking out into other parts of the program makes
it diﬃcult for us to isolate the Monte Carlo idea so that it can be applied
to other tasks. In the ﬁrst version of the program, assignment encapsu
lates the state of the randomnumber generator within the rand proce
dure, so that the details of randomnumber generation remain indepen
dent of the rest of the program.
e general phenomenon illustrated by the Monte Carlo example is
this: From the point of view of one part of a complex process, the other
parts appear to change with time. ey have hidden timevarying local
state. If we wish to write computer programs whose structure reﬂects
this decomposition, we make computational objects (such as bank ac
counts and randomnumber generators) whose behavior changes with
time. We model state with local state variables, and we model the changes
of state with assignments to those variables.
It is tempting to conclude this discussion by saying that, by intro
ducing assignment and the technique of hiding state in local variables,
we are able to structure systems in a more modular fashion than if all
state had to be manipulated explicitly, by passing additional parameters.
Unfortunately, as we shall see, the story is not so simple.
Exercise 3.5: Monte Carlo integration is a method of esti
mating deﬁnite integrals by means of Monte Carlo simula
tion. Consider computing the area of a region of space de
scribed by a predicate P(x ; y) that is true for points (x ; y)
in the region and false for points not in the region. For
309
example, the region contained within a circle of radius 3
centered at (5, 7) is described by the predicate that tests
whether (x (cid:0) 5)2 + (y (cid:0) 7)2 (cid:20) 32. To estimate the area of the
region described by such a predicate, begin by choosing a
rectangle that contains the region. For example, a rectangle
with diagonally opposite corners at (2, 4) and (8, 10) con
tains the circle above. e desired integral is the area of
that portion of the rectangle that lies in the region. We can
estimate the integral by picking, at random, points (x ; y)
that lie in the rectangle, and testing P(x ; y) for each point
to determine whether the point lies in the region. If we try
this with many points, then the fraction of points that fall
in the region should give an estimate of the proportion of
the rectangle that lies in the region. Hence, multiplying this
fraction by the area of the entire rectangle should produce
an estimate of the integral.
Implement Monte Carlo integration as a procedure estimate
integral that takes as arguments a predicate P, upper and
lower bounds x1, x2, y1, and y2 for the rectangle, and the
number of trials to perform in order to produce the esti
mate. Your procedure should use the same montecarlo
procedure that was used above to estimate π. Use your estimate
integral to produce an estimate of π by measuring the
area of a unit circle.
You will ﬁnd it useful to have a procedure that returns a
number chosen at random from a given range. e follow
ing randominrange procedure implements this in terms
of the random procedure used in Section 1.2.6, which re
310
turns a nonnegative number less than its input.8
(define (randominrange low high)
(let ((range ( high low)))
(+ low (random range))))
Exercise 3.6: It is useful to be able to reset a randomnumber
generator to produce a sequence starting from a given value.
Design a new rand procedure that is called with an ar
gument that is either the symbol generate or the symbol
reset and behaves as follows: (rand 'generate) produces
a new random number; ((rand 'reset) ⟨newvalue⟩) re
sets the internal state variable to the designated⟨newvalue⟩.
us, by reseing the state, one can generate repeatable se
quences. ese are very handy to have when testing and
debugging programs that use random numbers.
3.1.3 The Costs of Introducing Assignment
As we have seen, the set! operation enables us to model objects that
have local state. However, this advantage comes at a price. Our pro
gramming language can no longer be interpreted in terms of the sub
stitution model of procedure application that we introduced in Section
1.1.5. Moreover, no simple model with “nice” mathematical properties
can be an adequate framework for dealing with objects and assignment
in programming languages.
So long as we do not use assignments, two evaluations of the same
procedure with the same arguments will produce the same result, so
8 Scheme provides such a procedure. If random is given an exact integer (as in
Section 1.2.6) it returns an exact integer, but if it is given a decimal value (as in this
exercise) it returns a decimal value.
311
that procedures can be viewed as computing mathematical functions.
Programming without any use of assignments, as we did throughout
the ﬁrst two chapters of this book, is accordingly known as functional
programming.
To understand how assignment complicates maers, consider a sim
pliﬁed version of the makewithdraw procedure of Section 3.1.1 that
does not bother to check for an insuﬃcient amount:
(define (makesimplifiedwithdraw balance)
(lambda (amount)
(set! balance ( balance amount))
balance))
(define W (makesimplifiedwithdraw 25))
(W 20)
5
(W 10)
5
Compare this procedure with the following makedecrementer proce
dure, which does not use set!:
(define (makedecrementer balance)
(lambda (amount)
( balance amount)))
makedecrementer returns a procedure that subtracts its input from a
designated amount balance, but there is no accumulated eﬀect over
successive calls, as with makesimplifiedwithdraw:
(define D (makedecrementer 25))
(D 20)
5
(D 10)
15
312
We can use the substitution model to explain how makedecrementer
works. For instance, let us analyze the evaluation of the expression
((makedecrementer 25) 20)
We ﬁrst simplify the operator of the combination by substituting 25 for
balance in the body of makedecrementer. is reduces the expression
to
((lambda (amount) ( 25 amount)) 20)
Now we apply the operator by substituting 20 for amount in the body
of the lambda expression:
( 25 20)
e ﬁnal answer is 5.
Observe, however, what happens if we aempt a similar substitution
analysis with makesimplifiedwithdraw:
((makesimplifiedwithdraw 25) 20)
We ﬁrst simplify the operator by substituting 25 for balance in the body
of makesimplifiedwithdraw. is reduces the expression to9
((lambda (amount) (set! balance ( 25 amount)) 25) 20)
Now we apply the operator by substituting 20 for amount in the body
of the lambda expression:
(set! balance ( 25 20)) 25
If we adhered to the substitution model, we would have to say that the
meaning of the procedure application is to ﬁrst set balance to 5 and then
9We don’t substitute for the occurrence of balance in the set! expression because
the ⟨name⟩ in a set! is not evaluated. If we did substitute for it, we would get (set!
25 ( 25 amount)), which makes no sense.
313
return 25 as the value of the expression. is gets the wrong answer. In
order to get the correct answer, we would have to somehow distinguish
the ﬁrst occurrence of balance (before the eﬀect of the set!) from the
second occurrence of balance (aer the eﬀect of the set!), and the
substitution model cannot do this.
e trouble here is that substitution is based ultimately on the no
tion that the symbols in our language are essentially names for values.
But as soon as we introduce set! and the idea that the value of a vari
able can change, a variable can no longer be simply a name. Now a
variable somehow refers to a place where a value can be stored, and the
value stored at this place can change. In Section 3.2 we will see how
environments play this role of “place” in our computational model.
Sameness and change
e issue surfacing here is more profound than the mere breakdown of
a particular model of computation. As soon as we introduce change into
our computational models, many notions that were previously straight
forward become problematical. Consider the concept of two things be
ing “the same.”
Suppose we call makedecrementer twice with the same argument
to create two procedures:
(define D1 (makedecrementer 25))
(define D2 (makedecrementer 25))
Are D1 and D2 the same? An acceptable answer is yes, because D1 and D2
have the same computational behavior—each is a procedure that sub
tracts its input from 25. In fact, D1 could be substituted for D2 in any
computation without changing the result.
Contrast this with making two calls to makesimplifiedwithdraw:
314
(define W1 (makesimplifiedwithdraw 25))
(define W2 (makesimplifiedwithdraw 25))
Are W1 and W2 the same? Surely not, because calls to W1 and W2 have
distinct eﬀects, as shown by the following sequence of interactions:
(W1 20)
5
(W1 20)
15
(W2 20)
5
Even though W1 and W2 are “equal” in the sense that they are both cre
ated by evaluating the same expression, (makesimplifiedwithdraw
25), it is not true that W1 could be substituted for W2 in any expression
without changing the result of evaluating the expression.
A language that supports the concept that “equals can be substituted
for equals” in an expression without changing the value of the expres
sion is said to be referentially transparent. Referential transparency is
violated when we include set! in our computer language. is makes
it tricky to determine when we can simplify expressions by substituting
equivalent expressions. Consequently, reasoning about programs that
use assignment becomes drastically more diﬃcult.
Once we forgo referential transparency, the notion of what it means
for computational objects to be “the same” becomes diﬃcult to capture
in a formal way. Indeed, the meaning of “same” in the real world that our
programs model is hardly clear in itself. In general, we can determine
that two apparently identical objects are indeed “the same one” only by
modifying one object and then observing whether the other object has
changed in the same way. But how can we tell if an object has “changed”
other than by observing the “same” object twice and seeing whether
315
some property of the object diﬀers from one observation to the next?
us, we cannot determine “change” without some a priori notion of
“sameness,” and we cannot determine sameness without observing the
eﬀects of change.
As an example of how this issue arises in programming, consider
the situation where Peter and Paul have a bank account with $100 in it.
ere is a substantial diﬀerence between modeling this as
(define peteracc (makeaccount 100))
(define paulacc (makeaccount 100))
and modeling it as
(define peteracc (makeaccount 100))
(define paulacc peteracc)
In the ﬁrst situation, the two bank accounts are distinct. Transactions
made by Peter will not aﬀect Paul’s account, and vice versa. In the sec
ond situation, however, we have deﬁned paulacc to be the same thing
as peteracc. In eﬀect, Peter and Paul now have a joint bank account,
and if Peter makes a withdrawal from peteracc Paul will observe less
money in paulacc. ese two similar but distinct situations can cause
confusion in building computational models. With the shared account,
in particular, it can be especially confusing that there is one object (the
bank account) that has two diﬀerent names (peteracc and paulacc);
if we are searching for all the places in our program where paulacc
can be changed, we must remember to look also at things that change
peteracc.10
10e phenomenon of a single computational object being accessed by more than one
name is known as aliasing. e joint bank account situation illustrates a very simple
example of an alias. In Section 3.3 we will see much more complex examples, such as
“distinct” compound data structures that share parts. Bugs can occur in our programs
316
With reference to the above remarks on “sameness” and “change,”
observe that if Peter and Paul could only examine their bank balances,
and could not perform operations that changed the balance, then the is
sue of whether the two accounts are distinct would be moot. In general,
so long as we never modify data objects, we can regard a compound
data object to be precisely the totality of its pieces. For example, a ratio
nal number is determined by giving its numerator and its denominator.
But this view is no longer valid in the presence of change, where a com
pound data object has an “identity” that is something diﬀerent from the
pieces of which it is composed. A bank account is still “the same” bank
account even if we change the balance by making a withdrawal; con
versely, we could have two diﬀerent bank accounts with the same state
information. is complication is a consequence, not of our program
ming language, but of our perception of a bank account as an object. We
do not, for example, ordinarily regard a rational number as a change
able object with identity, such that we could change the numerator and
still have “the same” rational number.
Pitfalls of imperative programming
In contrast to functional programming, programming that makes ex
tensive use of assignment is known as imperative programming. In ad
dition to raising complications about computational models, programs
wrien in imperative style are susceptible to bugs that cannot occur in
functional programs. For example, recall the iterative factorial program
if we forget that a change to an object may also, as a “side eﬀect,” change a “diﬀerent”
object because the two “diﬀerent” objects are actually a single object appearing under
diﬀerent aliases. ese socalled sideeﬀect bugs are so diﬃcult to locate and to analyze
that some people have proposed that programming languages be designed in such a
way as to not allow side eﬀects or aliasing (Lampson et al. 1981; Morris et al. 1980).
317
from Section 1.2.1:
(define (factorial n)
(define (iter product counter)
(if (> counter n)
product
(iter (* counter product) (+ counter 1))))
(iter 1 1))
Instead of passing arguments in the internal iterative loop, we could
adopt a more imperative style by using explicit assignment to update
the values of the variables product and counter:
(define (factorial n)
(let ((product 1)
(counter 1))
(define (iter)
(if (> counter n)
product
(begin (set! product (* counter product))
(set! counter (+ counter 1))
(iter))))
(iter)))
is does not change the results produced by the program, but it does
introduce a subtle trap. How do we decide the order of the assignments?
As it happens, the program is correct as wrien. But writing the assign
ments in the opposite order
(set! counter (+ counter 1))
(set! product (* counter product))
would have produced a diﬀerent, incorrect result. In general, program
ming with assignment forces us to carefully consider the relative orders
of the assignments to make sure that each statement is using the correct
318
version of the variables that have been changed. is issue simply does
not arise in functional programs.11
e complexity of imperative programs becomes even worse if we
consider applications in which several processes execute concurrently.
We will return to this in Section 3.4. First, however, we will address the
issue of providing a computational model for expressions that involve
assignment, and explore the uses of objects with local state in designing
simulations.
Exercise 3.7: Consider the bank account objects created by
makeaccount, with the password modiﬁcation described
in Exercise 3.3. Suppose that our banking system requires
the ability to make joint accounts. Deﬁne a procedure make
joint that accomplishes this. makejoint should take three
arguments. e ﬁrst is a passwordprotected account. e
second argument must match the password with which the
account was deﬁned in order for the makejoint operation
to proceed. e third argument is a new password. make
joint is to create an additional access to the original ac
count using the new password. For example, if peteracc
is a bank account with password opensesame, then
(define paulacc
(makejoint peteracc 'opensesame 'rosebud))
11In view of this, it is ironic that introductory programming is most oen taught
in a highly imperative style. is may be a vestige of a belief, common throughout
the 1960s and 1970s, that programs that call procedures must inherently be less eﬃ
cient than programs that perform assignments. (Steele 1977 debunks this argument.)
Alternatively it may reﬂect a view that stepbystep assignment is easier for beginners
to visualize than procedure call. Whatever the reason, it oen saddles beginning pro
grammers with “should I set this variable before or aer that one” concerns that can
complicate programming and obscure the important ideas.
319
will allow one to make transactions on peteracc using the
name paulacc and the password rosebud. You may wish
to modify your solution to Exercise 3.3 to accommodate this
new feature.
Exercise 3.8: When we deﬁned the evaluation model in
Section 1.1.3, we said that the ﬁrst step in evaluating an
expression is to evaluate its subexpressions. But we never
speciﬁed the order in which the subexpressions should be
evaluated (e.g., le to right or right to le). When we in
troduce assignment, the order in which the arguments to a
procedure are evaluated can make a diﬀerence to the result.
Deﬁne a simple procedure f such that evaluating
(+ (f 0) (f 1))
will return 0 if the arguments to + are evaluated from le to
right but will return 1 if the arguments are evaluated from
right to le.
3.2 The Environment Model of Evaluation
When we introduced compound procedures in Chapter 1, we used the
substitution model of evaluation (Section 1.1.5) to deﬁne what is meant
by applying a procedure to arguments:
• To apply a compound procedure to arguments, evaluate the body
of the procedure with each formal parameter replaced by the cor
responding argument.
Once we admit assignment into our programming language, such a def
inition is no longer adequate. In particular, Section 3.1.3 argued that, in
320
the presence of assignment, a variable can no longer be considered to be
merely a name for a value. Rather, a variable must somehow designate
a “place” in which values can be stored. In our new model of evaluation,
these places will be maintained in structures called environments.
An environment is a sequence of frames. Each frame is a table (pos
sibly empty) of bindings, which associate variable names with their cor
responding values. (A single frame may contain at most one binding
for any variable.) Each frame also has a pointer to its enclosing environ
ment, unless, for the purposes of discussion, the frame is considered to
be global. e value of a variable with respect to an environment is the
value given by the binding of the variable in the ﬁrst frame in the en
vironment that contains a binding for that variable. If no frame in the
sequence speciﬁes a binding for the variable, then the variable is said to
be unbound in the environment.
Figure 3.1 shows a simple environment structure consisting of three
frames, labeled I, II, and III. In the diagram, A, B, C, and D are pointers to
environments. C and D point to the same environment. e variables z
and x are bound in frame II, while y and x are bound in frame I. e value
of x in environment D is 3. e value of x with respect to environment
B is also 3. is is determined as follows: We examine the ﬁrst frame in
the sequence (frame III) and do not ﬁnd a binding for x, so we proceed
to the enclosing environment D and ﬁnd the binding in frame I. On the
other hand, the value of x in environment A is 7, because the ﬁrst frame
in the sequence (frame II) contains a binding of x to 7. With respect to
environment A, the binding of x to 7 in frame II is said to shadow the
binding of x to 3 in frame I.
e environment is crucial to the evaluation process, because it de
termines the context in which an expression should be evaluated. In
deed, one could say that expressions in a programming language do
321
Figure 3.1: A simple environment structure.
not, in themselves, have any meaning. Rather, an expression acquires a
meaning only with respect to some environment in which it is evalu
ated. Even the interpretation of an expression as straightforward as (+
1 1) depends on an understanding that one is operating in a context in
which + is the symbol for addition. us, in our model of evaluation we
will always speak of evaluating an expression with respect to some envi
ronment. To describe interactions with the interpreter, we will suppose
that there is a global environment, consisting of a single frame (with no
enclosing environment) that includes values for the symbols associated
with the primitive procedures. For example, the idea that + is the sym
bol for addition is captured by saying that the symbol + is bound in the
global environment to the primitive addition procedure.
3.2.1 The Rules for Evaluation
e overall speciﬁcation of how the interpreter evaluates a combination
remains the same as when we ﬁrst introduced it in Section 1.1.3:
322
ABCDIIIIIIz:6x:7m:1y:2x:3y:5• To evaluate a combination:
1. Evaluate the subexpressions of the combination.12
2. Apply the value of the operator subexpression to the values of the
operand subexpressions.
e environment model of evaluation replaces the substitution model in
specifying what it means to apply a compound procedure to arguments.
In the environment model of evaluation, a procedure is always a pair
consisting of some code and a pointer to an environment. Procedures
are created in one way only: by evaluating a λexpression. is produces
a procedure whose code is obtained from the text of the λexpression
and whose environment is the environment in which the λexpression
was evaluated to produce the procedure. For example, consider the pro
cedure deﬁnition
(define (square x)
(* x x))
evaluated in the global environment. e procedure deﬁnition syntax
is just syntactic sugar for an underlying implicit λexpression. It would
have been equivalent to have used
(define square
(lambda (x) (* x x)))
12Assignment introduces a subtlety into step 1 of the evaluation rule. As shown in
Exercise 3.8, the presence of assignment allows us to write expressions that will produce
diﬀerent values depending on the order in which the subexpressions in a combination
are evaluated. us, to be precise, we should specify an evaluation order in step 1 (e.g.,
le to right or right to le). However, this order should always be considered to be
an implementation detail, and one should never write programs that depend on some
particular order. For instance, a sophisticated compiler might optimize a program by
varying the order in which subexpressions are evaluated.
323
Figure 3.2: Environment structure produced by evaluating
(define (square x) (* x x)) in the global environment.
which evaluates (lambda (x) (* x x)) and binds square to the re
sulting value, all in the global environment.
Figure 3.2 shows the result of evaluating this define expression.
e procedure object is a pair whose code speciﬁes that the procedure
has one formal parameter, namely x, and a procedure body (* x x).
e environment part of the procedure is a pointer to the global envi
ronment, since that is the environment in which the λexpression was
evaluated to produce the procedure. A new binding, which associates
the procedure object with the symbol square, has been added to the
global frame. In general, define creates deﬁnitions by adding bindings
to frames.
Now that we have seen how procedures are created, we can describe
how procedures are applied. e environment model speciﬁes: To ap
ply a procedure to arguments, create a new environment containing a
frame that binds the parameters to the values of the arguments. e en
closing environment of this frame is the environment speciﬁed by the
324
other variablessquare:globalenv(define (square x) (* x x))parameters: xbody: (* x x)Figure 3.3: Environment created by evaluating (square 5)
in the global environment.
procedure. Now, within this new environment, evaluate the procedure
body.
To show how this rule is followed, Figure 3.3 illustrates the environ
ment structure created by evaluating the expression (square 5) in the
global environment, where square is the procedure generated in Figure
3.2. Applying the procedure results in the creation of a new environ
ment, labeled E1 in the ﬁgure, that begins with a frame in which x, the
formal parameter for the procedure, is bound to the argument 5. e
pointer leading upward from this frame shows that the frame’s enclos
ing environment is the global environment. e global environment is
chosen here, because this is the environment that is indicated as part
of the square procedure object. Within E1, we evaluate the body of the
procedure, (* x x). Since the value of x in E1 is 5, the result is (* 5
5), or 25.
e environment model of procedure application can be summa
rized by two rules:
325
E1(* x x)parameters: xbody: (* x x)(square 5)globalenvother variablessquare:x:5• A procedure object is applied to a set of arguments by construct
ing a frame, binding the formal parameters of the procedure to the
arguments of the call, and then evaluating the body of the proce
dure in the context of the new environment constructed. e new
frame has as its enclosing environment the environment part of
the procedure object being applied.
• A procedure is created by evaluating a λexpression relative to a
given environment. e resulting procedure object is a pair con
sisting of the text of the λexpression and a pointer to the envi
ronment in which the procedure was created.
We also specify that deﬁning a symbol using define creates a binding
in the current environment frame and assigns to the symbol the indi
cated value.13 Finally, we specify the behavior of set!, the operation
that forced us to introduce the environment model in the ﬁrst place.
Evaluating the expression (set! ⟨variable⟩ ⟨value⟩) in some environ
ment locates the binding of the variable in the environment and changes
that binding to indicate the new value. at is, one ﬁnds the ﬁrst frame
in the environment that contains a binding for the variable and modi
ﬁes that frame. If the variable is unbound in the environment, then set!
signals an error.
ese evaluation rules, though considerably more complex than the
substitution model, are still reasonably straightforward. Moreover, the
evaluation model, though abstract, provides a correct description of
13If there is already a binding for the variable in the current frame, then the binding is
changed. is is convenient because it allows redeﬁnition of symbols; however, it also
means that define can be used to change values, and this brings up the issues of assign
ment without explicitly using set!. Because of this, some people prefer redeﬁnitions
of existing symbols to signal errors or warnings.
326
how the interpreter evaluates expressions. In Chapter 4 we shall see
how this model can serve as a blueprint for implementing a working
interpreter. e following sections elaborate the details of the model by
analyzing some illustrative programs.
3.2.2 Applying Simple Procedures
When we introduced the substitution model in Section 1.1.5 we showed
how the combination (f 5) evaluates to 136, given the following pro
cedure deﬁnitions:
(define (square x)
(* x x))
(define (sumofsquares x y)
(+ (square x) (square y)))
(define (f a)
(sumofsquares (+ a 1) (* a 2)))
We can analyze the same example using the environment model. Figure
3.4 shows the three procedure objects created by evaluating the deﬁni
tions of f, square, and sumofsquares in the global environment. Each
procedure object consists of some code, together with a pointer to the
global environment.
In Figure 3.5 we see the environment structure created by evaluat
ing the expression (f 5). e call to f creates a new environment E1
beginning with a frame in which a, the formal parameter of f, is bound
to the argument 5. In E1, we evaluate the body of f:
(sumofsquares (+ a 1) (* a 2))
To evaluate this combination, we ﬁrst evaluate the subexpressions. e
ﬁrst subexpression, sumofsquares, has a value that is a procedure ob
ject. (Notice how this value is found: We ﬁrst look in the ﬁrst frame of
327
Figure 3.4: Procedure objects in the global frame.
E1, which contains no binding for sumofsquares. en we proceed
to the enclosing environment, i.e. the global environment, and ﬁnd the
binding shown in Figure 3.4.) e other two subexpressions are evalu
ated by applying the primitive operations + and * to evaluate the two
combinations (+ a 1) and (* a 2) to obtain 6 and 10, respectively.
Now we apply the procedure object sumofsquares to the argu
ments 6 and 10. is results in a new environment E2 in which the
formal parameters x and y are bound to the arguments. Within E2 we
evaluate the combination (+ (square x) (square y)). is leads us to
evaluate (square x), where square is found in the global frame and x
is 6. Once again, we set up a new environment, E3, in which x is bound
to 6, and within this we evaluate the body of square, which is (* x x).
Also as part of applying sumofsquares, we must evaluate the subex
pression (square y), where y is 10. is second call to square creates
another environment, E4, in which x, the formal parameter of square,
is bound to 10. And within E4 we must evaluate (* x x).
328
square:sumofsquares:f:globalenvparameters: abody: (sumofsquares (+ a 1) (* a 2))parameters: xbody: (* x x)parameters: x,ybody: (+ (square x) (square y))Figure 3.5: Environments created by evaluating (f 5) us
ing the procedures in Figure 3.4.
e important point to observe is that each call to square creates a
new environment containing a binding for x. We can see here how the
diﬀerent frames serve to keep separate the diﬀerent local variables all
named x. Notice that each frame created by square points to the global
environment, since this is the environment indicated by the square pro
cedure object.
Aer the subexpressions are evaluated, the results are returned. e
values generated by the two calls to square are added by sumofsquares,
and this result is returned by f. Since our focus here is on the environ
ment structures, we will not dwell on how these returned values are
passed from call to call; however, this is also an important aspect of the
evaluation process, and we will return to it in detail in Chapter 5.
Exercise 3.9: In Section 1.2.1 we used the substitution model
to analyze two procedures for computing factorials, a recur
sive version
329
(* x x)x:10E4(* x x)x:6E3(+ (square x) (square y))x:6y:10E2(sumofsquares (+ a 1) (* a 2))a:5E1(f 5)globalenv(define (factorial n)
(if (= n 1) 1 (* n (factorial ( n 1)))))
and an iterative version
(define (factorial n) (factiter 1 1 n))
(define (factiter product counter maxcount)
(if (> counter maxcount)
product
(factiter (* counter product)
(+ counter 1)
maxcount)))
Show the environment structures created by evaluating
(factorial 6) using each version of the factorial pro
cedure.14
3.2.3 Frames as the Repository of Local State
We can turn to the environment model to see how procedures and as
signment can be used to represent objects with local state. As an exam
ple, consider the “withdrawal processor” from Section 3.1.1 created by
calling the procedure
(define (makewithdraw balance)
(lambda (amount)
(if (>= balance amount)
(begin (set! balance ( balance amount))
balance)
"Insufficient funds")))
14e environment model will not clarify our claim in Section 1.2.1 that the inter
preter can execute a procedure such as factiter in a constant amount of space using
tail recursion. We will discuss tail recursion when we deal with the control structure
of the interpreter in Section 5.4.
330
Figure 3.6: Result of deﬁning makewithdraw in the global
environment.
Let us describe the evaluation of
(define W1 (makewithdraw 100))
followed by
(W1 50)
50
Figure 3.6 shows the result of deﬁning the makewithdraw procedure in
the global environment. is produces a procedure object that contains
a pointer to the global environment. So far, this is no diﬀerent from the
examples we have already seen, except that the body of the procedure
is itself a λexpression.
e interesting part of the computation happens when we apply the
procedure makewithdraw to an argument:
(define W1 (makewithdraw 100))
331
parameters: balancebody: (lambda (amount) (if (>= balance amount) (begin (set! balance ( balance amount)) balance) "insufficient funds"))globalenvmakewithdraw:Figure 3.7: Result of evaluating (define W1 (makewithdraw 100)).
We begin, as usual, by seing up an environment E1 in which the formal
parameter balance is bound to the argument 100. Within this environ
ment, we evaluate the body of makewithdraw, namely the λexpression.
is constructs a new procedure object, whose code is as speciﬁed by
the lambda and whose environment is E1, the environment in which
the lambda was evaluated to produce the procedure. e resulting pro
cedure object is the value returned by the call to makewithdraw. is
is bound to W1 in the global environment, since the define itself is be
ing evaluated in the global environment. Figure 3.7 shows the resulting
environment structure.
Now we can analyze what happens when W1 is applied to an argu
ment:
(W1 50)
50
332
E1makewithdraw:W1:globalenvbalance: 100parameters: balancebody: ...parameters: amountbody: (if (>= balance amount) (begin (set! balance ( balance amount)) balance) "insufficient funds")Figure 3.8: Environments created by applying the procedure object W1.
We begin by constructing a frame in which amount, the formal pa
rameter of W1, is bound to the argument 50. e crucial point to ob
serve is that this frame has as its enclosing environment not the global
environment, but rather the environment E1, because this is the envi
ronment that is speciﬁed by the W1 procedure object. Within this new
environment, we evaluate the body of the procedure:
(if (>= balance amount)
(begin (set! balance ( balance amount))
balance)
"Insufficient funds")
e resulting environment structure is shown in Figure 3.8. e expres
sion being evaluated references both amount and balance. amount will
be found in the ﬁrst frame in the environment, while balance will be
333
E1makewithdraw: ...W1:globalenvbalance: 100parameters: amountbody: ...amount: 50Here is the balancethat will be changedby the set!(if (>= balance amount) (begin (set! balance ( balance amount)) balance) "insufficient funds")Figure 3.9: Environments aer the call to W1.
found by following the enclosingenvironment pointer to E1.
When the set! is executed, the binding of balance in E1 is changed.
At the completion of the call to W1, balance is 50, and the frame that
contains balance is still pointed to by the procedure object W1. e
frame that binds amount (in which we executed the code that changed
balance) is no longer relevant, since the procedure call that constructed
it has terminated, and there are no pointers to that frame from other
parts of the environment. e next time W1 is called, this will build a
new frame that binds amount and whose enclosing environment is E1.
We see that E1 serves as the “place” that holds the local state variable
for the procedure object W1. Figure 3.9 shows the situation aer the call
to W1.
Observe what happens when we create a second “withdraw” object
by making another call to makewithdraw:
(define W2 (makewithdraw 100))
334
E1makewithdraw: ...W1:globalenvbalance: 50parameters: amountbody: ...Figure 3.10: Using (define W2 (makewithdraw 100)) to
create a second object.
is produces the environment structure of Figure 3.10, which shows
that W2 is a procedure object, that is, a pair with some code and an en
vironment. e environment E2 for W2 was created by the call to make
withdraw. It contains a frame with its own local binding for balance.
On the other hand, W1 and W2 have the same code: the code speciﬁed
by the λexpression in the body of makewithdraw.15 We see here why
W1 and W2 behave as independent objects. Calls to W1 reference the state
variable balance stored in E1, whereas calls to W2 reference the balance
stored in E2. us, changes to the local state of one object do not aﬀect
the other object.
15Whether W1 and W2 share the same physical code stored in the computer, or whether
they each keep a copy of the code, is a detail of the implementation. For the interpreter
we implement in Chapter 4, the code is in fact shared.
335
E1W2:W1:globalenvbalance: 50parameters: amountbody: ...E2balance: 100makewithdraw: ...Exercise 3.10: In the makewithdraw procedure, the local
variable balance is created as a parameter of makewithdraw.
We could also create the local state variable explicitly, us
ing let, as follows:
(define (makewithdraw initialamount)
(let ((balance initialamount))
(lambda (amount)
(if (>= balance amount)
(begin (set! balance ( balance amount))
balance)
"Insufficient funds"))))
Recall from Section 1.3.2 that let is simply syntactic sugar
for a procedure call:
(let ((⟨var⟩ ⟨exp⟩)) ⟨body⟩)
is interpreted as an alternate syntax for
((lambda (⟨var⟩) ⟨body⟩) ⟨exp⟩)
Use the environment model to analyze this alternate ver
sion of makewithdraw, drawing ﬁgures like the ones above
to illustrate the interactions
(define W1 (makewithdraw 100))
(W1 50)
(define W2 (makewithdraw 100))
Show that the two versions of makewithdraw create ob
jects with the same behavior. How do the environment struc
tures diﬀer for the two versions?
336
3.2.4 Internal Definitions
Section 1.1.8 introduced the idea that procedures can have internal def
initions, thus leading to a block structure as in the following procedure
to compute square roots:
(define (sqrt x)
(define (goodenough? guess)
(< (abs ( (square guess) x)) 0.001))
(define (improve guess)
(average guess (/ x guess)))
(define (sqrtiter guess)
(if (goodenough? guess)
guess
(sqrtiter (improve guess))))
(sqrtiter 1.0))
Now we can use the environment model to see why these internal deﬁ
nitions behave as desired. Figure 3.11 shows the point in the evaluation
of the expression (sqrt 2) where the internal procedure goodenough?
has been called for the ﬁrst time with guess equal to 1.
Observe the structure of the environment. sqrt is a symbol in the
global environment that is bound to a procedure object whose associ
ated environment is the global environment. When sqrt was called, a
new environment E1 was formed, subordinate to the global environ
ment, in which the parameter x is bound to 2. e body of sqrt was
then evaluated in E1. Since the ﬁrst expression in the body of sqrt is
(define (goodenough? guess)
(< (abs ( (square guess) x)) 0.001))
evaluating this expression deﬁned the procedure goodenough? in the
environment E1. To be more precise, the symbol goodenough? was
added to the ﬁrst frame of E1, bound to a procedure object whose asso
337
Figure 3.11: sqrt procedure with internal deﬁnitions.
ciated environment is E1. Similarly, improve and sqrtiter were de
ﬁned as procedures in E1. For conciseness, Figure 3.11 shows only the
procedure object for goodenough?.
Aer the local procedures were deﬁned, the expression (sqrtiter
1.0) was evaluated, still in environment E1. So the procedure object
bound to sqrtiter in E1 was called with 1 as an argument. is cre
ated an environment E2 in which guess, the parameter of sqrtiter,
is bound to 1. sqrtiter in turn called goodenough? with the value of
guess (from E2) as the argument for goodenough?. is set up another
338
parameters:xbody:(define goodenough? ...) (define improve ...) (define sqrtiter ...) (sqrtiter 1.0)globalenvsqrt:E1x:2goodenough?:improve: ...sqrtiter: ...parameters:guessbody:(< (abs ...) ...)guess: 1guess: 1call to sqrtiterE2call to goodenough?E3environment, E3, in which guess (the parameter of goodenough?) is
bound to 1. Although sqrtiter and goodenough? both have a pa
rameter named guess, these are two distinct local variables located in
diﬀerent frames. Also, E2 and E3 both have E1 as their enclosing en
vironment, because the sqrtiter and goodenough? procedures both
have E1 as their environment part. One consequence of this is that the
symbol x that appears in the body of goodenough? will reference the
binding of x that appears in E1, namely the value of x with which the
original sqrt procedure was called.
e environment model thus explains the two key properties that
make local procedure deﬁnitions a useful technique for modularizing
programs:
• e names of the local procedures do not interfere with names
external to the enclosing procedure, because the local procedure
names will be bound in the frame that the procedure creates when
it is run, rather than being bound in the global environment.
• e local procedures can access the arguments of the enclosing
procedure, simply by using parameter names as free variables.
is is because the body of the local procedure is evaluated in an
environment that is subordinate to the evaluation environment
for the enclosing procedure.
Exercise 3.11: In Section 3.2.3 we saw how the environ
ment model described the behavior of procedures with local
state. Now we have seen how internal deﬁnitions work. A
typical messagepassing procedure contains both of these
aspects. Consider the bank account procedure of Section
3.1.1:
339
(define (makeaccount balance)
(define (withdraw amount)
(if (>= balance amount)
(begin (set! balance ( balance amount))
balance)
"Insufficient funds"))
(define (deposit amount)
(set! balance (+ balance amount))
balance)
(define (dispatch m)
(cond ((eq? m 'withdraw) withdraw)
((eq? m 'deposit) deposit)
(else
(error "Unknown request: MAKEACCOUNT"
dispatch)
m))))
Show the environment structure generated by the sequence
of interactions
(define acc (makeaccount 50))
((acc 'deposit) 40)
90
((acc 'withdraw) 60)
30
Where is the local state for acc kept? Suppose we deﬁne
another account
(define acc2 (makeaccount 100))
How are the local states for the two accounts kept distinct?
Which parts of the environment structure are shared be
tween acc and acc2?
340
3.3 Modeling with Mutable Data
Chapter 2 dealt with compound data as a means for constructing com
putational objects that have several parts, in order to model realworld
objects that have several aspects. In that chapter we introduced the dis
cipline of data abstraction, according to which data structures are spec
iﬁed in terms of constructors, which create data objects, and selectors,
which access the parts of compound data objects. But we now know
that there is another aspect of data that Chapter 2 did not address. e
desire to model systems composed of objects that have changing state
leads us to the need to modify compound data objects, as well as to con
struct and select from them. In order to model compound objects with
changing state, we will design data abstractions to include, in addition
to selectors and constructors, operations called mutators, which mod
ify data objects. For instance, modeling a banking system requires us to
change account balances. us, a data structure for representing bank
accounts might admit an operation
(setbalance! ⟨account⟩ ⟨newvalue⟩)
that changes the balance of the designated account to the designated
new value. Data objects for which mutators are deﬁned are known as
mutable data objects.
Chapter 2 introduced pairs as a generalpurpose “glue” for synthe
sizing compound data. We begin this section by deﬁning basic mutators
for pairs, so that pairs can serve as building blocks for constructing mu
table data objects. ese mutators greatly enhance the representational
power of pairs, enabling us to build data structures other than the se
quences and trees that we worked with in Section 2.2. We also present
some examples of simulations in which complex systems are modeled
as collections of objects with local state.
341
3.3.1 Mutable List Structure
e basic operations on pairs—cons, car, and cdr—can be used to con
struct list structure and to select parts from list structure, but they are
incapable of modifying list structure. e same is true of the list oper
ations we have used so far, such as append and list, since these can
be deﬁned in terms of cons, car, and cdr. To modify list structures we
need new operations.
e primitive mutators for pairs are setcar! and setcdr!. set
car! takes two arguments, the ﬁrst of which must be a pair. It modiﬁes
this pair, replacing the car pointer by a pointer to the second argument
of setcar!.16
As an example, suppose that x is bound to the list ((a b) c d) and
y to the list (e f) as illustrated in Figure 3.12. Evaluating the expression
(setcar! x y) modiﬁes the pair to which x is bound, replacing its car
by the value of y. e result of the operation is shown in Figure 3.13.
e structure x has been modiﬁed and would now be printed as ((e f)
c d). e pairs representing the list (a b), identiﬁed by the pointer that
was replaced, are now detached from the original structure.17
Compare Figure 3.13 with Figure 3.14, which illustrates the result of
executing (define z (cons y (cdr x))) with x and y bound to the
original lists of Figure 3.12. e variable z is now bound to a new pair
created by the cons operation; the list to which x is bound is unchanged.
e setcdr! operation is similar to setcar!. e only diﬀerence
is that the cdr pointer of the pair, rather than the car pointer, is replaced.
e eﬀect of executing (setcdr! x y) on the lists of Figure 3.12 is
16setcar! and setcdr! return implementationdependent values. Like set!, they
should be used only for their eﬀect.
17We see from this that mutation operations on lists can create “garbage” that is
not part of any accessible structure. We will see in Section 5.3.2 that Lisp memory
management systems include a garbage collector, which identiﬁes and recycles the mem
ory space used by unneeded pairs.
342
Figure 3.12: Lists x: ((a b) c d) and y: (e f).
Figure 3.13: Eﬀect of (setcar! x y) on the lists in Figure 3.12.
343
cdyxefabcdyxefabFigure 3.14: Eﬀect of (define z (cons y (cdr x))) on
the lists in Figure 3.12.
Figure 3.15: Eﬀect of (setcdr! x y) on the lists in Figure 3.12.
344
cdyxefabzcdyxefabshown in Figure 3.15. Here the cdr pointer of x has been replaced by
the pointer to (e f). Also, the list (c d), which used to be the cdr of
x, is now detached from the structure.
cons builds new list structure by creating new pairs, while setcar!
and setcdr! modify existing pairs. Indeed, we could implement cons
in terms of the two mutators, together with a procedure getnewpair,
which returns a new pair that is not part of any existing list structure.
We obtain the new pair, set its car and cdr pointers to the designated
objects, and return the new pair as the result of the cons.18
(define (cons x y)
(let ((new (getnewpair)))
(setcar! new x)
(setcdr! new y)
new))
Exercise 3.12: e following procedure for appending lists
was introduced in Section 2.2.1:
(define (append x y)
(if (null? x)
y
(cons (car x) (append (cdr x) y))))
append forms a new list by successively consing the el
ements of x onto y. e procedure append! is similar to
append, but it is a mutator rather than a constructor. It ap
pends the lists by splicing them together, modifying the ﬁ
nal pair of x so that its cdr is now y. (It is an error to call
append! with an empty x.)
18getnewpair is one of the operations that must be implemented as part of the
memory management required by a Lisp implementation. We will discuss this in Sec
tion 5.3.1.
345
(define (append! x y)
(setcdr! (lastpair x) y)
x)
Here lastpair is a procedure that returns the last pair in
its argument:
(define (lastpair x)
(if (null? (cdr x)) x (lastpair (cdr x))))
Consider the interaction
(define x (list 'a 'b))
(define y (list 'c 'd))
(define z (append x y))
z
(a b c d)
(cdr x)
⟨response⟩
(define w (append! x y))
w
(a b c d)
(cdr x)
⟨response⟩
What are the missing ⟨response⟩s? Draw boxandpointer
diagrams to explain your answer.
Exercise 3.13: Consider the following makecycle proce
dure, which uses the lastpair procedure deﬁned in Exer
cise 3.12:
(define (makecycle x)
(setcdr! (lastpair x) x)
x)
346
Draw a boxandpointer diagram that shows the structure
z created by
(define z (makecycle (list 'a 'b 'c)))
What happens if we try to compute (lastpair z)?
Exercise 3.14: e following procedure is quite useful, al
though obscure:
(define (mystery x)
(define (loop x y)
(if (null? x)
y
(let ((temp (cdr x)))
(setcdr! x y)
(loop temp x))))
(loop x '()))
loop uses the “temporary” variable temp to hold the old
value of the cdr of x, since the setcdr! on the next line
destroys the cdr. Explain what mystery does in general.
Suppose v is deﬁned by (define v (list 'a 'b 'c
'd)). Draw the boxandpointer diagram that represents
the list to which v is bound. Suppose that we now evalu
ate (define w (mystery v)). Draw boxandpointer dia
grams that show the structures v and w aer evaluating this
expression. What would be printed as the values of v and
w?
Sharing and identity
We mentioned in Section 3.1.3 the theoretical issues of “sameness” and
“change” raised by the introduction of assignment. ese issues arise in
347
practice when individual pairs are shared among diﬀerent data objects.
For example, consider the structure formed by
(define x (list 'a 'b))
(define z1 (cons x x))
As shown in Figure 3.16, z1 is a pair whose car and cdr both point to
the same pair x. is sharing of x by the car and cdr of z1 is a con
sequence of the straightforward way in which cons is implemented. In
general, using cons to construct lists will result in an interlinked struc
ture of pairs in which many individual pairs are shared by many diﬀer
ent structures.
In contrast to Figure 3.16, Figure 3.17 shows the structure created
by
(define z2 (cons (list 'a 'b) (list 'a 'b)))
In this structure, the pairs in the two (a b) lists are distinct, although
the actual symbols are shared.19
When thought of as a list, z1 and z2 both represent “the same” list,
((a b) a b). In general, sharing is completely undetectable if we oper
ate on lists using only cons, car, and cdr. However, if we allow mutators
on list structure, sharing becomes signiﬁcant. As an example of the dif
ference that sharing can make, consider the following procedure, which
modiﬁes the car of the structure to which it is applied:
(define (settowow! x) (setcar! (car x) 'wow) x)
19e two pairs are distinct because each call to cons returns a new pair. e symbols
are shared; in Scheme there is a unique symbol with any given name. Since Scheme
provides no way to mutate a symbol, this sharing is undetectable. Note also that the
sharing is what enables us to compare symbols using eq?, which simply checks equality
of pointers.
348
Figure 3.16: e list z1 formed by (cons x x).
Figure 3.17: e list z2 formed by (cons (list 'a 'b)
(list 'a 'b)).
Even though z1 and z2 are “the same” structure, applying settowow!
to them yields diﬀerent results. With z1, altering the car also changes
the cdr, because in z1 the car and the cdr are the same pair. With z2,
the car and cdr are distinct, so settowow! modiﬁes only the car:
z1
((a b) a b)
(settowow! z1)
((wow b) wow b)
z2
((a b) a b)
349
z1xababz2(settowow! z2)
((wow b) a b)
One way to detect sharing in list structures is to use the predicate eq?,
which we introduced in Section 2.3.1 as a way to test whether two sym
bols are equal. More generally, (eq? x y) tests whether x and y are
the same object (that is, whether x and y are equal as pointers). us,
with z1 and z2 as deﬁned in Figure 3.16 and Figure 3.17, (eq? (car z1)
(cdr z1)) is true and (eq? (car z2) (cdr z2)) is false.
As will be seen in the following sections, we can exploit sharing to
greatly extend the repertoire of data structures that can be represented
by pairs. On the other hand, sharing can also be dangerous, since modi
ﬁcations made to structures will also aﬀect other structures that happen
to share the modiﬁed parts. e mutation operations setcar! and set
cdr! should be used with care; unless we have a good understanding of
how our data objects are shared, mutation can have unanticipated re
sults.20
Exercise 3.15: Draw boxandpointer diagrams to explain
the eﬀect of settowow! on the structures z1 and z2 above.
Exercise 3.16: Ben Bitdiddle decides to write a procedure
to count the number of pairs in any list structure. “It’s easy,”
20e subtleties of dealing with sharing of mutable data objects reﬂect the underlying
issues of “sameness” and “change” that were raised in Section 3.1.3. We mentioned there
that admiing change to our language requires that a compound object must have an
“identity” that is something diﬀerent from the pieces from which it is composed. In
Lisp, we consider this “identity” to be the quality that is tested by eq?, i.e., by equality of
pointers. Since in most Lisp implementations a pointer is essentially a memory address,
we are “solving the problem” of deﬁning the identity of objects by stipulating that a data
object “itself” is the information stored in some particular set of memory locations in
the computer. is suﬃces for simple Lisp programs, but is hardly a general way to
resolve the issue of “sameness” in computational models.
350
he reasons. “e number of pairs in any structure is the
number in the car plus the number in the cdr plus one
more to count the current pair.” So Ben writes the following
procedure:
(define (countpairs x)
(if (not (pair? x))
0
(+ (countpairs (car x))
(countpairs (cdr x))
1)))
Show that this procedure is not correct. In particular, draw
boxandpointer diagrams representing list structures made
up of exactly three pairs for which Ben’s procedure would
return 3; return 4; return 7; never return at all.
Exercise 3.17: Devise a correct version of the countpairs
procedure of Exercise 3.16 that returns the number of dis
tinct pairs in any structure. (Hint: Traverse the structure,
maintaining an auxiliary data structure that is used to keep
track of which pairs have already been counted.)
Exercise 3.18: Write a procedure that examines a list and
determines whether it contains a cycle, that is, whether a
program that tried to ﬁnd the end of the list by taking suc
cessive cdrs would go into an inﬁnite loop. Exercise 3.13
constructed such lists.
Exercise 3.19: Redo Exercise 3.18 using an algorithm that
takes only a constant amount of space. (is requires a very
clever idea.)
351
Mutation is just assignment
When we introduced compound data, we observed in Section 2.1.3 that
pairs can be represented purely in terms of procedures:
(define (cons x y)
(define (dispatch m)
(cond ((eq? m 'car) x)
((eq? m 'cdr) y)
(else (error "Undefined operation: CONS" m))))
dispatch)
(define (car z) (z 'car))
(define (cdr z) (z 'cdr))
e same observation is true for mutable data. We can implement mu
table data objects as procedures using assignment and local state. For
instance, we can extend the above pair implementation to handle set
car! and setcdr! in a manner analogous to the way we implemented
bank accounts using makeaccount in Section 3.1.1:
(define (cons x y)
(define (setx! v) (set! x v))
(define (sety! v) (set! y v))
(define (dispatch m)
(cond ((eq? m 'car) x)
((eq? m 'cdr) y)
((eq? m 'setcar!) setx!)
((eq? m 'setcdr!) sety!)
(else
(error "Undefined operation: CONS" m))))
dispatch)
(define (car z) (z 'car))
(define (cdr z) (z 'cdr))
(define (setcar! z newvalue)
((z 'setcar!) newvalue) z)
352
(define (setcdr! z newvalue)
((z 'setcdr!) newvalue) z)
Assignment is all that is needed, theoretically, to account for the behav
ior of mutable data. As soon as we admit set! to our language, we raise
all the issues, not only of assignment, but of mutable data in general.21
Exercise 3.20: Draw environment diagrams to illustrate
the evaluation of the sequence of expressions
(define x (cons 1 2))
(define z (cons x x))
(setcar! (cdr z) 17)
(car x)
17
using the procedural implementation of pairs given above.
(Compare Exercise 3.11.)
3.3.2 Representing eues
e mutators setcar! and setcdr! enable us to use pairs to construct
data structures that cannot be built with cons, car, and cdr alone. is
section shows how to use pairs to represent a data structure called a
queue. Section 3.3.3 will show how to represent data structures called
tables.
A queue is a sequence in which items are inserted at one end (called
the rear of the queue) and deleted from the other end (the front). Fig
ure 3.18 shows an initially empty queue in which the items a and b are
21On the other hand, from the viewpoint of implementation, assignment requires us
to modify the environment, which is itself a mutable data structure. us, assignment
and mutation are equipotent: Each can be implemented in terms of the other.
353
Figure 3.18: eue operations.
inserted. en a is removed, c and d are inserted, and b is removed. Be
cause items are always removed in the order in which they are inserted,
a queue is sometimes called a FIFO (ﬁrst in, ﬁrst out) buﬀer.
In terms of data abstraction, we can regard a queue as deﬁned by
the following set of operations:
• a constructor: (makequeue) returns an empty queue (a queue
containing no items).
• two selectors:
(emptyqueue? ⟨queue⟩) tests if the queue is empty.
(frontqueue ⟨queue⟩) returns the object at the front of the
queue, signaling an error if the queue is empty; it does not modify
the queue.
• two mutators:
(insertqueue! ⟨queue⟩ ⟨item⟩) inserts the item at the rear of
the queue and returns the modiﬁed queue as its value.
354
Operation Resulting Queue(define q (makequeue))(insertqueue! q 'a) a(insertqueue! q 'b) a b(deletequeue! q) b(insertqueue! q 'c) b c(insertqueue! q 'd) b c d(deletequeue! q) c d(deletequeue! ⟨queue⟩) removes the item at the front of the
queue and returns the modiﬁed queue as its value, signaling an
error if the queue is empty before the deletion.
Because a queue is a sequence of items, we could certainly represent it
as an ordinary list; the front of the queue would be the car of the list,
inserting an item in the queue would amount to appending a new ele
ment at the end of the list, and deleting an item from the queue would
just be taking the cdr of the list. However, this representation is ineﬃ
cient, because in order to insert an item we must scan the list until we
reach the end. Since the only method we have for scanning a list is by
successive cdr operations, this scanning requires Θ(n) steps for a list of
n items. A simple modiﬁcation to the list representation overcomes this
disadvantage by allowing the queue operations to be implemented so
that they require Θ(1) steps; that is, so that the number of steps needed
is independent of the length of the queue.
e diﬃculty with the list representation arises from the need to
scan to ﬁnd the end of the list. e reason we need to scan is that, al
though the standard way of representing a list as a chain of pairs read
ily provides us with a pointer to the beginning of the list, it gives us
no easily accessible pointer to the end. e modiﬁcation that avoids the
drawback is to represent the queue as a list, together with an additional
pointer that indicates the ﬁnal pair in the list. at way, when we go to
insert an item, we can consult the rear pointer and so avoid scanning
the list.
A queue is represented, then, as a pair of pointers, frontptr and
rearptr, which indicate, respectively, the ﬁrst and last pairs in an or
dinary list. Since we would like the queue to be an identiﬁable object, we
can use cons to combine the two pointers. us, the queue itself will be
the cons of the two pointers. Figure 3.19 illustrates this representation.
355
Figure 3.19: Implementation of a queue as a list with front
and rear pointers.
To deﬁne the queue operations we use the following procedures,
which enable us to select and to modify the front and rear pointers of a
queue:
(define (frontptr queue) (car queue))
(define (rearptr queue) (cdr queue))
(define (setfrontptr! queue item)
(setcar! queue item))
(define (setrearptr!
queue item)
(setcdr! queue item))
Now we can implement the actual queue operations. We will consider
a queue to be empty if its front pointer is the empty list:
(define (emptyqueue? queue)
(null? (frontptr queue)))
e makequeue constructor returns, as an initially empty queue, a pair
whose car and cdr are both the empty list:
(define (makequeue) (cons '() '()))
356
cfrontptrqabrearptrFigure 3.20: Result of using (insertqueue! q 'd) on the
queue of Figure 3.19.
To select the item at the front of the queue, we return the car of the pair
indicated by the front pointer:
(define (frontqueue queue)
(if (emptyqueue? queue)
(error "FRONT called with an empty queue" queue)
(car (frontptr queue))))
To insert an item in a queue, we follow the method whose result is in
dicated in Figure 3.20. We ﬁrst create a new pair whose car is the item
to be inserted and whose cdr is the empty list. If the queue was initially
empty, we set the front and rear pointers of the queue to this new pair.
Otherwise, we modify the ﬁnal pair in the queue to point to the new
pair, and also set the rear pointer to the new pair.
(define (insertqueue! queue item)
(let ((newpair (cons item '())))
(cond ((emptyqueue? queue)
(setfrontptr! queue newpair)
(setrearptr! queue newpair)
queue)
357
frontptrqabrearptrcdFigure 3.21: Result of using (deletequeue! q) on the
queue of Figure 3.20.
(else
(setcdr! (rearptr queue) newpair)
(setrearptr! queue newpair)
queue))))
To delete the item at the front of the queue, we merely modify the front
pointer so that it now points at the second item in the queue, which
can be found by following the cdr pointer of the ﬁrst item (see Figure
3.21):22
(define (deletequeue! queue)
(cond ((emptyqueue? queue)
(error "DELETE! called with an empty queue" queue))
(else (setfrontptr! queue (cdr (frontptr queue)))
queue)))
22If the ﬁrst item is the ﬁnal item in the queue, the front pointer will be the empty
list aer the deletion, which will mark the queue as empty; we needn’t worry about
updating the rear pointer, which will still point to the deleted item, because empty
queue? looks only at the front pointer.
358
frontptrqabrearptrcdExercise 3.21: Ben Bitdiddle decides to test the queue im
plementation described above. He types in the procedures
to the Lisp interpreter and proceeds to try them out:
(define q1 (makequeue))
(insertqueue! q1 'a)
((a) a)
(insertqueue! q1 'b)
((a b) b)
(deletequeue! q1)
((b) b)
(deletequeue! q1)
(() b)
“It’s all wrong!” he complains. “e interpreter’s response
shows that the last item is inserted into the queue twice.
And when I delete both items, the second b is still there,
so the queue isn’t empty, even though it’s supposed to be.”
Eva Lu Ator suggests that Ben has misunderstood what is
happening. “It’s not that the items are going into the queue
twice,” she explains. “It’s just that the standard Lisp printer
doesn’t know how to make sense of the queue representa
tion. If you want to see the queue printed correctly, you’ll
have to deﬁne your own print procedure for queues.” Ex
plain what Eva Lu is talking about. In particular, show why
Ben’s examples produce the printed results that they do.
Deﬁne a procedure printqueue that takes a queue as in
put and prints the sequence of items in the queue.
Exercise 3.22: Instead of representing a queue as a pair of
pointers, we can build a queue as a procedure with local
state. e local state will consist of pointers to the begin
359
ning and the end of an ordinary list. us, the makequeue
procedure will have the form
(define (makequeue)
(let ((frontptr : : : )
(rearptr : : : ))
⟨definitions of internal procedures⟩
(define (dispatch m) : : :)
dispatch))
Complete the deﬁnition of makequeue and provide imple
mentations of the queue operations using this representa
tion.
Exercise 3.23: A deque (“doubleended queue”) is a sequence
in which items can be inserted and deleted at either the
front or the rear. Operations on deques are the constructor
makedeque, the predicate emptydeque?, selectors front
deque and reardeque, mutators frontinsertdeque!,
rearinsertdeque!, frontdeletedeque!, and reardelete
deque!. Show how to represent deques using pairs, and
give implementations of the operations.23 All operations
should be accomplished in Θ(1) steps.
3.3.3 Representing Tables
When we studied various ways of representing sets in Chapter 2, we
mentioned in Section 2.3.3 the task of maintaining a table of records in
dexed by identifying keys. In the implementation of datadirected pro
gramming in Section 2.4.3, we made extensive use of twodimensional
23Be careful not to make the interpreter try to print a structure that contains cycles.
(See Exercise 3.13.)
360
Figure 3.22: A table represented as a headed list.
tables, in which information is stored and retrieved using two keys. Here
we see how to build tables as mutable list structures.
We ﬁrst consider a onedimensional table, in which each value is
stored under a single key. We implement the table as a list of records,
each of which is implemented as a pair consisting of a key and the as
sociated value. e records are glued together to form a list by pairs
whose cars point to successive records. ese gluing pairs are called
the backbone of the table. In order to have a place that we can change
when we add a new record to the table, we build the table as a headed list.
A headed list has a special backbone pair at the beginning, which holds
a dummy “record”—in this case the arbitrarily chosen symbol *table*.
Figure 3.22 shows the boxandpointer diagram for the table
a:
b:
c:
1
2
3
To extract information from a table we use the lookup procedure, which
takes a key as argument and returns the associated value (or false if
361
abc123*table*tablethere is no value stored under that key). lookup is deﬁned in terms of the
assoc operation, which expects a key and a list of records as arguments.
Note that assoc never sees the dummy record. assoc returns the record
that has the given key as its car.24 lookup then checks to see that the
resulting record returned by assoc is not false, and returns the value
(the cdr) of the record.
(define (lookup key table)
(let ((record (assoc key (cdr table))))
(if record
(cdr record)
false)))
(define (assoc key records)
(cond ((null? records) false)
((equal? key (caar records)) (car records))
(else (assoc key (cdr records)))))
To insert a value in a table under a speciﬁed key, we ﬁrst use assoc
to see if there is already a record in the table with this key. If not, we
form a new record by consing the key with the value, and insert this at
the head of the table’s list of records, aer the dummy record. If there
already is a record with this key, we set the cdr of this record to the
designated new value. e header of the table provides us with a ﬁxed
location to modify in order to insert the new record.25
(define (insert! key value table)
(let ((record (assoc key (cdr table))))
24Because assoc uses equal?, it can recognize keys that are symbols, numbers, or
list structure.
25us, the ﬁrst backbone pair is the object that represents the table “itself”; that is,
a pointer to the table is a pointer to this pair. is same backbone pair always starts
the table. If we did not arrange things in this way, insert! would have to return a new
value for the start of the table when it added a new record.
362
(if record
(setcdr! record value)
(setcdr! table
(cons (cons key value)
(cdr table)))))
'ok)
To construct a new table, we simply create a list containing the symbol
*table*:
(define (maketable)
(list '*table*))
Twodimensional tables
In a twodimensional table, each value is indexed by two keys. We can
construct such a table as a onedimensional table in which each key
identiﬁes a subtable. Figure 3.23 shows the boxandpointer diagram
for the table
math:
+:
43
: 45
*: 42
letters:
a:
97
b: 98
which has two subtables. (e subtables don’t need a special header
symbol, since the key that identiﬁes the subtable serves this purpose.)
When we look up an item, we use the ﬁrst key to identify the correct
subtable. en we use the second key to identify the record within the
subtable.
(define (lookup key1 key2 table)
(let ((subtable
(assoc key1 (cdr table))))
363
Figure 3.23: A twodimensional table.
(if subtable
(let ((record
(assoc key2 (cdr subtable))))
(if record
(cdr record)
false))
false)))
364
+*434542*table*ab9798lettersmathtableTo insert a new item under a pair of keys, we use assoc to see if
there is a subtable stored under the ﬁrst key. If not, we build a new
subtable containing the single record (key2, value) and insert it into
the table under the ﬁrst key. If a subtable already exists for the ﬁrst key,
we insert the new record into this subtable, using the insertion method
for onedimensional tables described above:
(define (insert! key1 key2 value table)
(let ((subtable (assoc key1 (cdr table))))
(if subtable
(let ((record (assoc key2 (cdr subtable))))
(if record
(setcdr! record value)
(setcdr! subtable
(cons (cons key2 value)
(cdr subtable)))))
(setcdr! table
(cons (list key1
(cons key2 value))
(cdr table)))))
'ok)
Creating local tables
e lookup and insert! operations deﬁned above take the table as an
argument. is enables us to use programs that access more than one ta
ble. Another way to deal with multiple tables is to have separate lookup
and insert! procedures for each table. We can do this by representing
a table procedurally, as an object that maintains an internal table as part
of its local state. When sent an appropriate message, this “table object”
supplies the procedure with which to operate on the internal table. Here
is a generator for twodimensional tables represented in this fashion:
365
(define (maketable)
(let ((localtable (list '*table*)))
(define (lookup key1 key2)
(let ((subtable
(assoc key1 (cdr localtable))))
(if subtable
(let ((record
(assoc key2 (cdr subtable))))
(if record (cdr record) false))
false)))
(define (insert! key1 key2 value)
(let ((subtable
(assoc key1 (cdr localtable))))
(if subtable
(let ((record
(assoc key2 (cdr subtable))))
(if record
(setcdr! record value)
(setcdr! subtable
(cons (cons key2 value)
(cdr subtable)))))
(setcdr! localtable
(cons (list key1 (cons key2 value))
(cdr localtable)))))
'ok)
(define (dispatch m)
(cond ((eq? m 'lookupproc) lookup)
((eq? m 'insertproc!) insert!)
(else (error "Unknown operation: TABLE" m))))
dispatch))
Using maketable, we could implement the get and put operations
used in Section 2.4.3 for datadirected programming, as follows:
366
(define operationtable (maketable))
(define get (operationtable 'lookupproc))
(define put (operationtable 'insertproc!))
get takes as arguments two keys, and put takes as arguments two keys
and a value. Both operations access the same local table, which is en
capsulated within the object created by the call to maketable.
Exercise 3.24: In the table implementations above, the keys
are tested for equality using equal? (called by assoc). is
is not always the appropriate test. For instance, we might
have a table with numeric keys in which we don’t need an
exact match to the number we’re looking up, but only a
number within some tolerance of it. Design a table con
structor maketable that takes as an argument a samekey?
procedure that will be used to test “equality” of keys. make
table should return a dispatch procedure that can be used
to access appropriate lookup and insert! procedures for a
local table.
Exercise 3.25: Generalizing one and twodimensional ta
bles, show how to implement a table in which values are
stored under an arbitrary number of keys and diﬀerent val
ues may be stored under diﬀerent numbers of keys. e
lookup and insert! procedures should take as input a list
of keys used to access the table.
Exercise 3.26: To search a table as implemented above, one
needs to scan through the list of records. is is basically
the unordered list representation of Section 2.3.3. For large
tables, it may be more eﬃcient to structure the table in a dif
ferent manner. Describe a table implementation where the
367
(key, value) records are organized using a binary tree, as
suming that keys can be ordered in some way (e.g., numer
ically or alphabetically). (Compare Exercise 2.66 of Chapter
2.)
Exercise 3.27: Memoization (also called tabulation) is a tech
nique that enables a procedure to record, in a local table,
values that have previously been computed. is technique
can make a vast diﬀerence in the performance of a program.
A memoized procedure maintains a table in which values
of previous calls are stored using as keys the arguments
that produced the values. When the memoized procedure
is asked to compute a value, it ﬁrst checks the table to see
if the value is already there and, if so, just returns that value.
Otherwise, it computes the new value in the ordinary way
and stores this in the table. As an example of memoization,
recall from Section 1.2.2 the exponential process for com
puting Fibonacci numbers:
(define (fib n)
(cond ((= n 0) 0)
((= n 1) 1)
(else (+ (fib ( n 1)) (fib ( n 2))))))
e memoized version of the same procedure is
(define memofib
(memoize
(lambda (n)
(cond ((= n 0) 0)
((= n 1) 1)
(else (+ (memofib ( n 1))
(memofib ( n 2))))))))
368
where the memoizer is deﬁned as
(define (memoize f)
(let ((table (maketable)))
(lambda (x)
(let ((previouslycomputedresult
(lookup x table)))
(or previouslycomputedresult
(let ((result (f x)))
(insert! x result table)
result))))))
Draw an environment diagram to analyze the computation
of (memofib 3). Explain why memofib computes the nth
Fibonacci number in a number of steps proportional to n.
Would the scheme still work if we had simply deﬁned memo
fib to be (memoize fib)?
3.3.4 A Simulator for Digital Circuits
Designing complex digital systems, such as computers, is an important
engineering activity. Digital systems are constructed by interconnect
ing simple elements. Although the behavior of these individual elements
is simple, networks of them can have very complex behavior. Computer
simulation of proposed circuit designs is an important tool used by digi
tal systems engineers. In this section we design a system for performing
digital logic simulations. is system typiﬁes a kind of program called
an eventdriven simulation, in which actions (“events”) trigger further
events that happen at a later time, which in turn trigger more events,
and so on.
Our computational model of a circuit will be composed of objects
that correspond to the elementary components from which the circuit
369
Figure 3.24: Primitive functions in the digital logic simulator.
is constructed. ere are wires, which carry digital signals. A digital sig
nal may at any moment have only one of two possible values, 0 and
1. ere are also various types of digital function boxes, which connect
wires carrying input signals to other output wires. Such boxes produce
output signals computed from their input signals. e output signal is
delayed by a time that depends on the type of the function box. For
example, an inverter is a primitive function box that inverts its input.
If the input signal to an inverter changes to 0, then one inverterdelay
later the inverter will change its output signal to 1. If the input signal to
an inverter changes to 1, then one inverterdelay later the inverter will
change its output signal to 0. We draw an inverter symbolically as in
Figure 3.24. An andgate, also shown in Figure 3.24, is a primitive func
tion box with two inputs and one output. It drives its output signal to
a value that is the logical and of the inputs. at is, if both of its input
signals become 1, then one andgatedelay time later the andgate will
force its output signal to be 1; otherwise the output will be 0. An orgate
is a similar twoinput primitive function box that drives its output sig
nal to a value that is the logical or of the inputs. at is, the output will
become 1 if at least one of the input signals is 1; otherwise the output
will become 0.
We can connect primitive functions together to construct more com
plex functions. To accomplish this we wire the outputs of some function
boxes to the inputs of other function boxes. For example, the halfadder
370
InverterAndgateOrgateFigure 3.25: A halfadder circuit.
circuit shown in Figure 3.25 consists of an orgate, two andgates, and
an inverter. It takes two input signals, A and B, and has two output sig
nals, S and C. S will become 1 whenever precisely one of A and B is 1,
and C will become 1 whenever A and B are both 1. We can see from the
ﬁgure that, because of the delays involved, the outputs may be gener
ated at diﬀerent times. Many of the diﬃculties in the design of digital
circuits arise from this fact.
We will now build a program for modeling the digital logic circuits
we wish to study. e program will construct computational objects
modeling the wires, which will “hold” the signals. Function boxes will
be modeled by procedures that enforce the correct relationships among
the signals.
One basic element of our simulation will be a procedure makewire,
which constructs wires. For example, we can construct six wires as fol
lows:
(define a (makewire))
(define b (makewire))
(define c (makewire))
(define d (makewire))
(define e (makewire))
(define s (makewire))
371
DEABSCWe aach a function box to a set of wires by calling a procedure that
constructs that kind of box. e arguments to the constructor procedure
are the wires to be aached to the box. For example, given that we can
construct andgates, orgates, and inverters, we can wire together the
halfadder shown in Figure 3.25:
(orgate a b d)
ok
(andgate a b c)
ok
(inverter c e)
ok
(andgate d e s)
ok
Beer yet, we can explicitly name this operation by deﬁning a procedure
halfadder that constructs this circuit, given the four external wires to
be aached to the halfadder:
(define (halfadder a b s c)
(let ((d (makewire)) (e (makewire)))
(orgate a b d)
(andgate a b c)
(inverter c e)
(andgate d e s)
'ok))
e advantage of making this deﬁnition is that we can use halfadder
itself as a building block in creating more complex circuits. Figure 3.26,
for example, shows a fulladder composed of two halfadders and an
orgate.26 We can construct a fulladder as follows:
26A fulladder is a basic circuit element used in adding two binary numbers. Here
A and B are the bits at corresponding positions in the two numbers to be added, and
372
Figure 3.26: A fulladder circuit.
(define (fulladder a b cin sum cout)
(let ((s (makewire)) (c1 (makewire)) (c2 (makewire)))
(halfadder b cin s c1)
(halfadder a s sum c2)
(orgate c1 c2 cout)
'ok))
Having deﬁned fulladder as a procedure, we can now use it as a build
ing block for creating still more complex circuits. (For example, see Ex
ercise 3.30.)
In essence, our simulator provides us with the tools to construct a
language of circuits. If we adopt the general perspective on languages
with which we approached the study of Lisp in Section 1.1, we can say
that the primitive function boxes form the primitive elements of the
language, that wiring boxes together provides a means of combination,
and that specifying wiring paerns as procedures serves as a means of
abstraction.
Cin is the carry bit from the addition one place to the right. e circuit generates SUM,
which is the sum bit in the corresponding position, and Cout, which is the carry bit to
be propagated to the le.
373
halfadderhalfadderABCinSUMCoutorPrimitive function boxes
e primitive function boxes implement the “forces” by which a change
in the signal on one wire inﬂuences the signals on other wires. To build
function boxes, we use the following operations on wires:
• (getsignal ⟨wire⟩)
returns the current value of the signal on the wire.
• (setsignal! ⟨wire⟩ ⟨new value⟩)
changes the value of the signal on the wire to the new value.
• (addaction! ⟨wire⟩ ⟨procedure of no arguments⟩)
asserts that the designated procedure should be run whenever
the signal on the wire changes value. Such procedures are the
vehicles by which changes in the signal value on the wire are
communicated to other wires.
In addition, we will make use of a procedure afterdelay that takes a
time delay and a procedure to be run and executes the given procedure
aer the given delay.
Using these procedures, we can deﬁne the primitive digital logic
functions. To connect an input to an output through an inverter, we use
addaction! to associate with the input wire a procedure that will be
run whenever the signal on the input wire changes value. e proce
dure computes the logicalnot of the input signal, and then, aer one
inverterdelay, sets the output signal to be this new value:
(define (inverter input output)
(define (invertinput)
(let ((newvalue (logicalnot (getsignal input))))
374
(afterdelay inverterdelay
(lambda () (setsignal! output newvalue)))))
(addaction! input invertinput) 'ok)
(define (logicalnot s)
(cond ((= s 0) 1)
((= s 1) 0)
(else (error "Invalid signal" s))))
An andgate is a lile more complex. e action procedure must be run
if either of the inputs to the gate changes. It computes the logical
and (using a procedure analogous to logicalnot) of the values of the
signals on the input wires and sets up a change to the new value to
occur on the output wire aer one andgatedelay.
(define (andgate a1 a2 output)
(define (andactionprocedure)
(let ((newvalue
(logicaland (getsignal a1) (getsignal a2))))
(afterdelay
andgatedelay
(lambda () (setsignal! output newvalue)))))
(addaction! a1 andactionprocedure)
(addaction! a2 andactionprocedure)
'ok)
Exercise 3.28: Deﬁne an orgate as a primitive function
box. Your orgate constructor should be similar to and
gate.
Exercise 3.29: Another way to construct an orgate is as
a compound digital logic device, built from andgates and
inverters. Deﬁne a procedure orgate that accomplishes
375
Figure 3.27: A ripplecarry adder for nbit numbers.
this. What is the delay time of the orgate in terms of and
gatedelay and inverterdelay?
Exercise 3.30: Figure 3.27 shows a ripplecarry adder formed
by stringing together n fulladders. is is the simplest form
of parallel adder for adding two nbit binary numbers. e
inputs A1, A2, A3, : : :, An and B1, B2, B3, : : :, Bn are the
two binary numbers to be added (each Ak and Bk is a 0 or
a 1). e circuit generates S1, S2, S3, : : :, Sn, the n bits of
the sum, and C, the carry from the addition. Write a proce
dure ripplecarryadder that generates this circuit. e
procedure should take as arguments three lists of n wires
each—the Ak , the Bk , and the Sk —and also another wire C.
e major drawback of the ripplecarry adder is the need
to wait for the carry signals to propagate. What is the delay
needed to obtain the complete output from an nbit ripple
carry adder, expressed in terms of the delays for andgates,
orgates, and inverters?
376
A1B1C1A2B2C2A3B3C3AnBnCn = 0 S1CS2S3SnCn1 FAFAFAFARepresenting wires
A wire in our simulation will be a computational object with two local
state variables: a signalvalue (initially taken to be 0) and a collec
tion of actionprocedures to be run when the signal changes value.
We implement the wire, using messagepassing style, as a collection of
local procedures together with a dispatch procedure that selects the ap
propriate local operation, just as we did with the simple bankaccount
object in Section 3.1.1:
(define (makewire)
(let ((signalvalue 0) (actionprocedures '()))
(define (setmysignal! newvalue)
(if (not (= signalvalue newvalue))
(begin (set! signalvalue newvalue)
(calleach actionprocedures))
'done))
(define (acceptactionprocedure! proc)
(set! actionprocedures
(cons proc actionprocedures))
(proc))
(define (dispatch m)
(cond ((eq? m 'getsignal) signalvalue)
((eq? m 'setsignal!) setmysignal!)
((eq? m 'addaction!) acceptactionprocedure!)
(else (error "Unknown operation: WIRE" m))))
dispatch))
e local procedure setmysignal! tests whether the new signal value
changes the signal on the wire. If so, it runs each of the action proce
dures, using the following procedure calleach, which calls each of the
items in a list of noargument procedures:
(define (calleach procedures)
377
(if (null? procedures)
'done
(begin ((car procedures))
(calleach (cdr procedures)))))
e local procedure acceptactionprocedure! adds the given proce
dure to the list of procedures to be run, and then runs the new procedure
once. (See Exercise 3.31.)
With the local dispatch procedure set up as speciﬁed, we can pro
vide the following procedures to access the local operations on wires:27
(define (getsignal wire) (wire 'getsignal))
(define (setsignal! wire newvalue)
((wire 'setsignal!) newvalue))
(define (addaction! wire actionprocedure)
((wire 'addaction!) actionprocedure))
Wires, which have timevarying signals and may be incrementally at
tached to devices, are typical of mutable objects. We have modeled them
as procedures with local state variables that are modiﬁed by assignment.
When a new wire is created, a new set of state variables is allocated
(by the let expression in makewire) and a new dispatch procedure
is constructed and returned, capturing the environment with the new
state variables.
27 ese procedures are simply syntactic sugar that allow us to use ordinary pro
cedural syntax to access the local procedures of objects. It is striking that we can in
terchange the role of “procedures” and “data” in such a simple way. For example, if we
write (wire 'getsignal) we think of wire as a procedure that is called with the mes
sage getsignal as input. Alternatively, writing (getsignal wire) encourages us to
think of wire as a data object that is the input to a procedure getsignal. e truth of
the maer is that, in a language in which we can deal with procedures as objects, there
is no fundamental diﬀerence between “procedures” and “data,” and we can choose our
syntactic sugar to allow us to program in whatever style we choose.
378
e wires are shared among the various devices that have been con
nected to them. us, a change made by an interaction with one device
will aﬀect all the other devices aached to the wire. e wire communi
cates the change to its neighbors by calling the action procedures pro
vided to it when the connections were established.
The agenda
e only thing needed to complete the simulator is afterdelay. e
idea here is that we maintain a data structure, called an agenda, that
contains a schedule of things to do. e following operations are deﬁned
for agendas:
• (makeagenda) returns a new empty agenda.
• (emptyagenda?
empty.
⟨agenda⟩) is true if the speciﬁed agenda is
• (firstagendaitem
⟨agenda⟩) returns the ﬁrst item on the
agenda.
• (removefirstagendaitem! ⟨agenda⟩) modiﬁes the agenda
by removing the ﬁrst item.
⟨agenda⟩) modiﬁes the
• (addtoagenda! ⟨time⟩
agenda by adding the given action procedure to be run at the spec
iﬁed time.
• (currenttime ⟨agenda⟩) returns the current simulation time.
⟨action⟩
e particular agenda that we use is denoted by theagenda. e pro
cedure afterdelay adds new elements to theagenda:
379
(define (afterdelay delay action)
(addtoagenda! (+ delay (currenttime theagenda))
action
theagenda))
e simulation is driven by the procedure propagate, which operates
on theagenda, executing each procedure on the agenda in sequence. In
general, as the simulation runs, new items will be added to the agenda,
and propagate will continue the simulation as long as there are items
on the agenda:
(define (propagate)
(if (emptyagenda? theagenda)
'done
(let ((firstitem (firstagendaitem theagenda)))
(firstitem)
(removefirstagendaitem! theagenda)
(propagate))))
A sample simulation
e following procedure, which places a “probe” on a wire, shows the
simulator in action. e probe tells the wire that, whenever its signal
changes value, it should print the new signal value, together with the
current time and a name that identiﬁes the wire:
(define (probe name wire)
(addaction! wire
(lambda ()
(newline)
(display name) (display " ")
(display (currenttime theagenda))
(display " Newvalue = ")
(display (getsignal wire)))))
380
We begin by initializing the agenda and specifying delays for the prim
itive function boxes:
(define theagenda (makeagenda))
(define inverterdelay 2)
(define andgatedelay 3)
(define orgatedelay 5)
Now we deﬁne four wires, placing probes on two of them:
(define input1 (makewire))
(define input2 (makewire))
(define sum (makewire))
(define carry (makewire))
(probe 'sum sum)
sum 0 Newvalue = 0
(probe 'carry carry)
carry 0 Newvalue = 0
Next we connect the wires in a halfadder circuit (as in Figure 3.25), set
the signal on input1 to 1, and run the simulation:
(halfadder input1 input2 sum carry)
ok
(setsignal! input1 1)
done
(propagate)
sum 8 Newvalue = 1
done
e sum signal changes to 1 at time 8. We are now eight time units from
the beginning of the simulation. At this point, we can set the signal on
input2 to 1 and allow the values to propagate:
381
(setsignal! input2 1)
done
(propagate)
carry 11 Newvalue = 1
sum 16 Newvalue = 0
done
e carry changes to 1 at time 11 and the sum changes to 0 at time 16.
Exercise 3.31: e internal procedure acceptactionprocedure!
deﬁned in makewire speciﬁes that when a new action pro
cedure is added to a wire, the procedure is immediately
run. Explain why this initialization is necessary. In particu
lar, trace through the halfadder example in the paragraphs
above and say how the system’s response would diﬀer if we
had deﬁned acceptactionprocedure! as
(define (acceptactionprocedure! proc)
(set! actionprocedures
(cons proc actionprocedures)))
Implementing the agenda
Finally, we give details of the agenda data structure, which holds the
procedures that are scheduled for future execution.
e agenda is made up of time segments. Each time segment is a
pair consisting of a number (the time) and a queue (see Exercise 3.32)
that holds the procedures that are scheduled to be run during that time
segment.
(define (maketimesegment time queue)
(cons time queue))
382
(define (segmenttime s) (car s))
(define (segmentqueue s) (cdr s))
We will operate on the timesegment queues using the queue operations
described in Section 3.3.2.
e agenda itself is a onedimensional table of time segments. It
diﬀers from the tables described in Section 3.3.3 in that the segments will
be sorted in order of increasing time. In addition, we store the current
time (i.e., the time of the last action that was processed) at the head of
the agenda. A newly constructed agenda has no time segments and has
a current time of 0:28
(define (makeagenda) (list 0))
(define (currenttime agenda) (car agenda))
(define (setcurrenttime! agenda time)
(setcar! agenda time))
(define (segments agenda) (cdr agenda))
(define (setsegments! agenda segments)
(setcdr! agenda segments))
(define (firstsegment agenda) (car (segments agenda)))
(define (restsegments agenda) (cdr (segments agenda)))
An agenda is empty if it has no time segments:
(define (emptyagenda? agenda)
(null? (segments agenda)))
To add an action to an agenda, we ﬁrst check if the agenda is empty. If so,
we create a time segment for the action and install this in the agenda.
Otherwise, we scan the agenda, examining the time of each segment.
If we ﬁnd a segment for our appointed time, we add the action to the
28e agenda is a headed list, like the tables in Section 3.3.3, but since the list is
headed by the time, we do not need an additional dummy header (such as the *table*
symbol used with tables).
383
associated queue. If we reach a time later than the one to which we are
appointed, we insert a new time segment into the agenda just before it.
If we reach the end of the agenda, we must create a new time segment
at the end.
(define (addtoagenda! time action agenda)
(define (belongsbefore? segments)
(or (null? segments)
(< time (segmenttime (car segments)))))
(define (makenewtimesegment time action)
(let ((q (makequeue)))
(insertqueue! q action)
(maketimesegment time q)))
(define (addtosegments! segments)
(if (= (segmenttime (car segments)) time)
(insertqueue! (segmentqueue (car segments))
action)
(let ((rest (cdr segments)))
(if (belongsbefore? rest)
(setcdr!
segments
(cons (makenewtimesegment time action)
(cdr segments)))
(addtosegments! rest)))))
(let ((segments (segments agenda)))
(if (belongsbefore? segments)
(setsegments!
agenda
(cons (makenewtimesegment time action)
segments))
(addtosegments! segments))))
e procedure that removes the ﬁrst item from the agenda deletes the
item at the front of the queue in the ﬁrst time segment. If this deletion
384
makes the time segment empty, we remove it from the list of segments:29
(define (removefirstagendaitem! agenda)
(let ((q (segmentqueue (firstsegment agenda))))
(deletequeue! q)
(if (emptyqueue? q)
(setsegments! agenda (restsegments agenda)))))
e ﬁrst agenda item is found at the head of the queue in the ﬁrst
time segment. Whenever we extract an item, we also update the cur
rent time:30
(define (firstagendaitem agenda)
(if (emptyagenda? agenda)
(error "Agenda is empty: FIRSTAGENDAITEM")
(let ((firstseg (firstsegment agenda)))
(setcurrenttime! agenda
(frontqueue (segmentqueue firstseg)))))
(segmenttime firstseg))
Exercise 3.32: e procedures to be run during each time
segment of the agenda are kept in a queue. us, the pro
cedures for each segment are called in the order in which
they were added to the agenda (ﬁrst in, ﬁrst out). Explain
why this order must be used. In particular, trace the behav
ior of an andgate whose inputs change from 0, 1 to 1, 0
29Observe that the if expression in this procedure has no ⟨alternative⟩ expression.
Such a “onearmed if statement” is used to decide whether to do something, rather
than to select between two expressions. An if expression returns an unspeciﬁed value
if the predicate is false and there is no ⟨alternative⟩.
30In this way, the current time will always be the time of the action most recently
processed. Storing this time at the head of the agenda ensures that it will still be avail
able even if the associated time segment has been deleted.
385
in the same segment and say how the behavior would dif
fer if we stored a segment’s procedures in an ordinary list,
adding and removing procedures only at the front (last in,
ﬁrst out).
3.3.5 Propagation of Constraints
Computer programs are traditionally organized as onedirectional com
putations, which perform operations on prespeciﬁed arguments to pro
duce desired outputs. On the other hand, we oen model systems in
terms of relations among quantities. For example, a mathematical model
of a mechanical structure might include the information that the deﬂec
tion d of a metal rod is related to the force F on the rod, the length L
of the rod, the crosssectional area A, and the elastic modulus E via the
equation
dAE = F L:
Such an equation is not onedirectional. Given any four of the quanti
ties, we can use it to compute the ﬁh. Yet translating the equation into
a traditional computer language would force us to choose one of the
quantities to be computed in terms of the other four. us, a procedure
for computing the area A could not be used to compute the deﬂection
d, even though the computations of A and d arise from the same equa
tion.31
31Constraint propagation ﬁrst appeared in the incredibly forwardlooking
system of Ivan Sutherland (1963). A beautiful constraintpropagation system based
on the Smalltalk language was developed by Alan Borning (1977) at Xerox Palo Alto
Research Center. Sussman, Stallman, and Steele applied constraint propagation to elec
trical circuit analysis (Sussman and Stallman 1975; Sussman and Steele 1980). TK!Solver
(Konopasek and Jayaraman 1984) is an extensive modeling environment based on
constraints.
386
In this section, we sketch the design of a language that enables us
to work in terms of relations themselves. e primitive elements of the
language are primitive constraints, which state that certain relations hold
between quantities. For example, (adder a b c) speciﬁes that the quan
tities a, b, and c must be related by the equation a + b = c, (multiplier
x y z) expresses the constraint xy = z, and (constant 3.14 x) says
that the value of x must be 3.14.
Our language provides a means of combining primitive constraints
in order to express more complex relations. We combine constraints
by constructing constraint networks, in which constraints are joined by
connectors. A connector is an object that “holds” a value that may par
ticipate in one or more constraints. For example, we know that the re
lationship between Fahrenheit and Celsius temperatures is
9C = 5(F (cid:0) 32):
Such a constraint can be thought of as a network consisting of primitive
adder, multiplier, and constant constraints (Figure 3.28). In the ﬁgure,
we see on the le a multiplier box with three terminals, labeled m1,
m2, and p. ese connect the multiplier to the rest of the network as
follows: e m1 terminal is linked to a connector C, which will hold the
Celsius temperature. e m2 terminal is linked to a connector w, which
is also linked to a constant box that holds 9. e p terminal, which the
multiplier box constrains to be the product of m1 and m2, is linked to
the p terminal of another multiplier box, whose m2 is connected to a
constant 5 and whose m1 is connected to one of the terms in a sum.
Computation by such a network proceeds as follows: When a con
nector is given a value (by the user or by a constraint box to which
it is linked), it awakens all of its associated constraints (except for the
constraint that just awakened it) to inform them that it has a value.
387
Figure 3.28: e relation 9C = 5(F (cid:0) 32) expressed as a
constraint network.
Each awakened constraint box then polls its connectors to see if there
is enough information to determine a value for a connector. If so, the
box sets that connector, which then awakens all of its associated con
straints, and so on. For instance, in conversion between Celsius and
Fahrenheit, w, x, and y are immediately set by the constant boxes to 9,
5, and 32, respectively. e connectors awaken the multipliers and the
adder, which determine that there is not enough information to pro
ceed. If the user (or some other part of the network) sets C to a value
(say 25), the lemost multiplier will be awakened, and it will set u to
25 (cid:1) 9 = 225. en u awakens the second multiplier, which sets v to 45,
and v awakens the adder, which sets f to 77.
Using the constraint system
To use the constraint system to carry out the temperature computation
outlined above, we ﬁrst create two connectors, C and F, by calling the
constructor makeconnector, and link C and F in an appropriate net
work:
(define C (makeconnector))
(define F (makeconnector))
388
m1m2p*pm1m2*uv3259a1a2s+FCwxy(celsiusfahrenheitconverter C F)
ok
e procedure that creates the network is deﬁned as follows:
(define (celsiusfahrenheitconverter c f)
(let ((u (makeconnector))
(v (makeconnector))
(w (makeconnector))
(x (makeconnector))
(y (makeconnector)))
(multiplier c w u)
(multiplier v x u)
(adder v y f)
(constant 9 w)
(constant 5 x)
(constant 32 y)
'ok))
is procedure creates the internal connectors u, v, w, x, and y, and links
them as shown in Figure 3.28 using the primitive constraint construc
tors adder, multiplier, and constant. Just as with the digitalcircuit
simulator of Section 3.3.4, expressing these combinations of primitive
elements in terms of procedures automatically provides our language
with a means of abstraction for compound objects.
To watch the network in action, we can place probes on the con
nectors C and F, using a probe procedure similar to the one we used to
monitor wires in Section 3.3.4. Placing a probe on a connector will cause
a message to be printed whenever the connector is given a value:
(probe "Celsius temp" C)
(probe "Fahrenheit temp" F)
Next we set the value of C to 25. (e third argument to setvalue!
tells C that this directive comes from the user.)
389
(setvalue! C 25 'user)
Probe: Celsius temp = 25
Probe: Fahrenheit temp = 77
done
e probe on C awakens and reports the value. C also propagates its
value through the network as described above. is sets F to 77, which
is reported by the probe on F.
Now we can try to set F to a new value, say 212:
(setvalue! F 212 'user)
Error! Contradiction (77 212)
e connector complains that it has sensed a contradiction: Its value is
77, and someone is trying to set it to 212. If we really want to reuse the
network with new values, we can tell C to forget its old value:
(forgetvalue! C 'user)
Probe: Celsius temp = ?
Probe: Fahrenheit temp = ?
done
C ﬁnds that the user, who set its value originally, is now retracting that
value, so C agrees to lose its value, as shown by the probe, and informs
the rest of the network of this fact. is information eventually prop
agates to F, which now ﬁnds that it has no reason for continuing to
believe that its own value is 77. us, F also gives up its value, as shown
by the probe.
Now that F has no value, we are free to set it to 212:
(setvalue! F 212 'user)
Probe: Fahrenheit temp = 212
Probe: Celsius temp = 100
done
390
is new value, when propagated through the network, forces C to have
a value of 100, and this is registered by the probe on C. Notice that the
very same network is being used to compute C given F and to compute
F given C. is nondirectionality of computation is the distinguishing
feature of constraintbased systems.
Implementing the constraint system
e constraint system is implemented via procedural objects with local
state, in a manner very similar to the digitalcircuit simulator of Sec
tion 3.3.4. Although the primitive objects of the constraint system are
somewhat more complex, the overall system is simpler, since there is
no concern about agendas and logic delays.
e basic operations on connectors are the following:
• (hasvalue? ⟨connector⟩) tells whether the connector has a
value.
• (getvalue ⟨connector⟩) returns the connector’s current value.
• (setvalue! ⟨connector⟩ ⟨newvalue⟩ ⟨informant⟩) indicates
that the informant is requesting the connector to set its value to
the new value.
• (forgetvalue! ⟨connector⟩ ⟨retractor⟩) tells the connector
that the retractor is requesting it to forget its value.
• (connect ⟨connector⟩ ⟨newconstraint⟩) tells the connector
to participate in the new constraint.
e connectors communicate with the constraints by means of the pro
cedures informaboutvalue, which tells the given constraint that the
391
connector has a value, and informaboutnovalue, which tells the
constraint that the connector has lost its value.
adder constructs an adder constraint among summand connectors
a1 and a2 and a sum connector. An adder is implemented as a procedure
with local state (the procedure me below):
(define (adder a1 a2 sum)
(define (processnewvalue)
(cond ((and (hasvalue? a1) (hasvalue? a2))
(setvalue! sum
(+ (getvalue a1) (getvalue a2))
me))
((and (hasvalue? a1) (hasvalue? sum))
(setvalue! a2
( (getvalue sum) (getvalue a1))
me))
((and (hasvalue? a2) (hasvalue? sum))
(setvalue! a1
( (getvalue sum) (getvalue a2))
me))))
(define (processforgetvalue)
(forgetvalue! sum me)
(forgetvalue! a1 me)
(forgetvalue! a2 me)
(processnewvalue))
(define (me request)
(cond ((eq? request 'Ihaveavalue)
(processnewvalue))
((eq? request 'Ilostmyvalue) (processforgetvalue))
(else (error "Unknown request: ADDER" request))))
(connect a1 me)
(connect a2 me)
(connect sum me)
me)
392
adder connects the new adder to the designated connectors and returns
it as its value. e procedure me, which represents the adder, acts as a
dispatch to the local procedures. e following “syntax interfaces” (see
Footnote 27 in Section 3.3.4) are used in conjunction with the dispatch:
(define (informaboutvalue constraint)
(constraint 'Ihaveavalue))
(define (informaboutnovalue constraint)
(constraint 'Ilostmyvalue))
e adder’s local procedure processnewvalue is called when the adder
is informed that one of its connectors has a value. e adder ﬁrst checks
to see if both a1 and a2 have values. If so, it tells sum to set its value to
the sum of the two addends. e informant argument to setvalue! is
me, which is the adder object itself. If a1 and a2 do not both have values,
then the adder checks to see if perhaps a1 and sum have values. If so, it
sets a2 to the diﬀerence of these two. Finally, if a2 and sum have values,
this gives the adder enough information to set a1. If the adder is told
that one of its connectors has lost a value, it requests that all of its con
nectors now lose their values. (Only those values that were set by this
adder are actually lost.) en it runs processnewvalue. e reason
for this last step is that one or more connectors may still have a value
(that is, a connector may have had a value that was not originally set by
the adder), and these values may need to be propagated back through
the adder.
A multiplier is very similar to an adder. It will set its product to 0 if
either of the factors is 0, even if the other factor is not known.
(define (multiplier m1 m2 product)
(define (processnewvalue)
(cond ((or (and (hasvalue? m1) (= (getvalue m1) 0))
(and (hasvalue? m2) (= (getvalue m2) 0)))
393
(setvalue! product 0 me))
((and (hasvalue? m1) (hasvalue? m2))
(setvalue! product
(* (getvalue m1) (getvalue m2))
me))
((and (hasvalue? product) (hasvalue? m1))
(setvalue! m2
(/ (getvalue product)
(getvalue m1))
me))
((and (hasvalue? product) (hasvalue? m2))
(setvalue! m1
(/ (getvalue product)
(getvalue m2))
me))))
(define (processforgetvalue)
(forgetvalue! product me)
(forgetvalue! m1 me)
(forgetvalue! m2 me)
(processnewvalue))
(define (me request)
(cond ((eq? request 'Ihaveavalue)
(processnewvalue))
((eq? request 'Ilostmyvalue) (processforgetvalue))
(else (error "Unknown request: MULTIPLIER"
request))))
(connect m1 me)
(connect m2 me)
(connect product me)
me)
A constant constructor simply sets the value of the designated con
nector. Any Ihaveavalue or Ilostmyvalue message sent to the
constant box will produce an error.
394
(define (constant value connector)
(define (me request)
(error "Unknown request: CONSTANT" request))
(connect connector me)
(setvalue! connector value me)
me)
Finally, a probe prints a message about the seing or unseing of the
designated connector:
(define (probe name connector)
(define (printprobe value)
(newline) (display "Probe: ") (display name)
(display " = ") (display value))
(define (processnewvalue)
(printprobe (getvalue connector)))
(define (processforgetvalue) (printprobe "?"))
(define (me request)
(cond ((eq? request 'Ihaveavalue)
(processnewvalue))
((eq? request 'Ilostmyvalue) (processforgetvalue))
(else (error "Unknown request: PROBE" request))))
(connect connector me)
me)
Representing connectors
A connector is represented as a procedural object with local state vari
ables value, the current value of the connector; informant, the object
that set the connector’s value; and constraints, a list of the constraints
in which the connector participates.
(define (makeconnector)
(let ((value false) (informant false) (constraints '()))
(define (setmyvalue newval setter)
395
(cond ((not (hasvalue? me))
(set! value newval)
(set! informant setter)
(foreachexcept setter
informaboutvalue
constraints))
((not (= value newval))
(error "Contradiction" (list value newval)))
(else 'ignored)))
(define (forgetmyvalue retractor)
(if (eq? retractor informant)
(begin (set! informant false)
(foreachexcept retractor
informaboutnovalue
constraints))
'ignored))
(define (connect newconstraint)
(if (not (memq newconstraint constraints))
(set! constraints
(cons newconstraint constraints)))
(if (hasvalue? me)
(informaboutvalue newconstraint))
'done)
(define (me request)
(cond ((eq? request 'hasvalue?)
(if informant true false))
((eq? request 'value) value)
((eq? request 'setvalue!) setmyvalue)
((eq? request 'forget) forgetmyvalue)
((eq? request 'connect) connect)
(else (error "Unknown operation: CONNECTOR"
me))
request))))
396
e connector’s local procedure setmyvalue is called when there is
a request to set the connector’s value. If the connector does not cur
rently have a value, it will set its value and remember as informant
the constraint that requested the value to be set.32 en the connector
will notify all of its participating constraints except the constraint that
requested the value to be set. is is accomplished using the follow
ing iterator, which applies a designated procedure to all items in a list
except a given one:
(define (foreachexcept exception procedure list)
(define (loop items)
(cond ((null? items) 'done)
((eq? (car items) exception) (loop (cdr items)))
(else (procedure (car items))
(loop (cdr items)))))
(loop list))
If a connector is asked to forget its value, it runs the local procedure
forgetmyvalue, which ﬁrst checks to make sure that the request is
coming from the same object that set the value originally. If so, the con
nector informs its associated constraints about the loss of the value.
e local procedure connect adds the designated new constraint to
the list of constraints if it is not already in that list. en, if the connector
has a value, it informs the new constraint of this fact.
e connector’s procedure me serves as a dispatch to the other in
ternal procedures and also represents the connector as an object. e
following procedures provide a syntax interface for the dispatch:
(define (hasvalue? connector)
(connector 'hasvalue?))
32e setter might not be a constraint. In our temperature example, we used user
as the setter.
397
(define (getvalue connector)
(connector 'value))
(define (setvalue! connector newvalue informant)
((connector 'setvalue!) newvalue informant))
(define (forgetvalue! connector retractor)
((connector 'forget) retractor))
(define (connect connector newconstraint)
((connector 'connect) newconstraint))
Exercise 3.33: Using primitive multiplier, adder, and con
stant constraints, deﬁne a procedure averager that takes
three connectors a, b, and c as inputs and establishes the
constraint that the value of c is the average of the values of
a and b.
Exercise 3.34: Louis Reasoner wants to build a squarer, a
constraint device with two terminals such that the value
of connector b on the second terminal will always be the
square of the value a on the ﬁrst terminal. He proposes the
following simple device made from a multiplier:
(define (squarer a b)
(multiplier a a b))
ere is a serious ﬂaw in this idea. Explain.
Exercise 3.35: Ben Bitdiddle tells Louis that one way to
avoid the trouble in Exercise 3.34 is to deﬁne a squarer
as a new primitive constraint. Fill in the missing portions
in Ben’s outline for a procedure to implement such a con
straint:
398
(define (squarer a b)
(define (processnewvalue)
(if (hasvalue? b)
(if (< (getvalue b) 0)
(error "square less than 0: SQUARER"
⟨alternative1⟩)
(getvalue b))
⟨alternative2⟩))
(define (processforgetvalue) ⟨body1⟩)
(define (me request) ⟨body2⟩)
⟨rest of definition⟩
me)
Exercise 3.36: Suppose we evaluate the following sequence
of expressions in the global environment:
(define a (makeconnector))
(define b (makeconnector))
(setvalue! a 10 'user)
At some time during evaluation of the setvalue!, the fol
lowing expression from the connector’s local procedure is
evaluated:
(foreachexcept
setter informaboutvalue constraints)
Draw an environment diagram showing the environment
in which the above expression is evaluated.
Exercise 3.37: e celsiusfahrenheitconverter pro
cedure is cumbersome when compared with a more expression
oriented style of deﬁnition, such as
399
(define (celsiusfahrenheitconverter x)
(c+ (c* (c/ (cv 9) (cv 5))
x)
(cv 32)))
(define C (makeconnector))
(define F (celsiusfahrenheitconverter C))
Here c+, c*, etc. are the “constraint” versions of the arith
metic operations. For example, c+ takes two connectors as
arguments and returns a connector that is related to these
by an adder constraint:
(define (c+ x y)
(let ((z (makeconnector)))
(adder x y z)
z))
Deﬁne analogous procedures c, c*, c/, and cv (constant
value) that enable us to deﬁne compound constraints as in
the converter example above.33
33e expressionoriented format is convenient because it avoids the need to name
the intermediate expressions in a computation. Our original formulation of the con
straint language is cumbersome in the same way that many languages are cumbersome
when dealing with operations on compound data. For example, if we wanted to com
pute the product (a +b)(cid:1) (c +d), where the variables represent vectors, we could work in
“imperative style,” using procedures that set the values of designated vector arguments
but do not themselves return vectors as values:
(vsum a b temp1)
(vsum c d temp2)
(vprod temp1 temp2 answer)
Alternatively, we could deal with expressions, using procedures that return vectors as
values, and thus avoid explicitly mentioning temp1 and temp2:
(define answer (vprod (vsum a b) (vsum c d)))
400
3.4 Concurrency: Time Is of the Essence
We’ve seen the power of computational objects with local state as tools
for modeling. Yet, as Section 3.1.3 warned, this power extracts a price:
the loss of referential transparency, giving rise to a thicket of questions
about sameness and change, and the need to abandon the substitution
model of evaluation in favor of the more intricate environment model.
e central issue lurking beneath the complexity of state, sameness,
and change is that by introducing assignment we are forced to admit
time into our computational models. Before we introduced assignment,
all our programs were timeless, in the sense that any expression that
has a value always has the same value. In contrast, recall the example of
modeling withdrawals from a bank account and returning the resulting
balance, introduced at the beginning of Section 3.1.1:
(withdraw 25)
75
(withdraw 25)
50
Since Lisp allows us to return compound objects as values of procedures, we can trans
form our imperativestyle constraint language into an expressionoriented style as
shown in this exercise. In languages that are impoverished in handling compound ob
jects, such as Algol, Basic, and Pascal (unless one explicitly uses Pascal pointer vari
ables), one is usually stuck with the imperative style when manipulating compound
objects. Given the advantage of the expressionoriented format, one might ask if there
is any reason to have implemented the system in imperative style, as we did in this
section. One reason is that the nonexpressionoriented constraint language provides
a handle on constraint objects (e.g., the value of the adder procedure) as well as on
connector objects. is is useful if we wish to extend the system with new operations
that communicate with constraints directly rather than only indirectly via operations
on connectors. Although it is easy to implement the expressionoriented style in terms
of the imperative implementation, it is very diﬃcult to do the converse.
401
Here successive evaluations of the same expression yield diﬀerent val
ues. is behavior arises from the fact that the execution of assignment
statements (in this case, assignments to the variable balance) delineates
moments in time when values change. e result of evaluating an ex
pression depends not only on the expression itself, but also on whether
the evaluation occurs before or aer these moments. Building models
in terms of computational objects with local state forces us to confront
time as an essential concept in programming.
We can go further in structuring computational models to match our
perception of the physical world. Objects in the world do not change
one at a time in sequence. Rather we perceive them as acting concur
rently—all at once. So it is oen natural to model systems as collections
of computational processes that execute concurrently. Just as we can
make our programs modular by organizing models in terms of objects
with separate local state, it is oen appropriate to divide computational
models into parts that evolve separately and concurrently. Even if the
programs are to be executed on a sequential computer, the practice of
writing programs as if they were to be executed concurrently forces
the programmer to avoid inessential timing constraints and thus makes
programs more modular.
In addition to making programs more modular, concurrent compu
tation can provide a speed advantage over sequential computation. Se
quential computers execute only one operation at a time, so the amount
of time it takes to perform a task is proportional to the total number
of operations performed.34 However, if it is possible to decompose a
34Most real processors actually execute a few operations at a time, following a strat
egy called pipelining. Although this technique greatly improves the eﬀective utilization
of the hardware, it is used only to speed up the execution of a sequential instruction
stream, while retaining the behavior of the sequential program.
402
problem into pieces that are relatively independent and need to com
municate only rarely, it may be possible to allocate pieces to separate
computing processors, producing a speed advantage proportional to the
number of processors available.
Unfortunately, the complexities introduced by assignment become
even more problematic in the presence of concurrency. e fact of con
current execution, either because the world operates in parallel or be
cause our computers do, entails additional complexity in our under
standing of time.
3.4.1 The Nature of Time in Concurrent Systems
On the surface, time seems straightforward. It is an ordering imposed
on events.35 For any events A and B, either A occurs before B, A and
B are simultaneous, or A occurs aer B. For instance, returning to the
bank account example, suppose that Peter withdraws $10 and Paul with
draws $25 from a joint account that initially contains $100, leaving $65
in the account. Depending on the order of the two withdrawals, the
sequence of balances in the account is either $100 ! $90 ! $65 or
$100 ! $75 ! $65 . In a computer implementation of the banking sys
tem, this changing sequence of balances could be modeled by successive
assignments to a variable balance.
In complex situations, however, such a view can be problematic.
Suppose that Peter and Paul, and other people besides, are accessing the
same bank account through a network of banking machines distributed
all over the world. e actual sequence of balances in the account will
depend critically on the detailed timing of the accesses and the details
of the communication among the machines.
35To quote some graﬃti seen on a Cambridge building wall: “Time is a device that
was invented to keep everything from happening at once.”
403
is indeterminacy in the order of events can pose serious prob
lems in the design of concurrent systems. For instance, suppose that the
withdrawals made by Peter and Paul are implemented as two separate
processes sharing a common variable balance, each process speciﬁed
by the procedure given in Section 3.1.1:
(define (withdraw amount)
(if (>= balance amount)
(begin
(set! balance ( balance amount))
balance)
"Insufficient funds"))
If the two processes operate independently, then Peter might test the
balance and aempt to withdraw a legitimate amount. However, Paul
might withdraw some funds in between the time that Peter checks the
balance and the time Peter completes the withdrawal, thus invalidating
Peter’s test.
ings can be worse still. Consider the expression
(set! balance ( balance amount))
executed as part of each withdrawal process. is consists of three steps:
(1) accessing the value of the balance variable; (2) computing the new
balance; (3) seing balance to this new value. If Peter and Paul’s with
drawals execute this statement concurrently, then the two withdrawals
might interleave the order in which they access balance and set it to
the new value.
e timing diagram in Figure 3.29 depicts an order of events where
balance starts at 100, Peter withdraws 10, Paul withdraws 25, and yet
the ﬁnal value of balance is 75. As shown in the diagram, the reason for
this anomaly is that Paul’s assignment of 75 to balance is made under
the assumption that the value of balance to be decremented is 100. at
404
Figure 3.29: Timing diagram showing how interleaving
the order of events in two banking withdrawals can lead
to an incorrect ﬁnal balance.
405
PeterAccess balance: $100new value: 100–10=90set! balance to $90timeBankPaul$100$90$75Access balance: $100new value: 100–25=75set! balance to $75assumption, however, became invalid when Peter changed balance to
90. is is a catastrophic failure for the banking system, because the
total amount of money in the system is not conserved. Before the trans
actions, the total amount of money was $100. Aerwards, Peter has $10,
Paul has $25, and the bank has $75.36
e general phenomenon illustrated here is that several processes
may share a common state variable. What makes this complicated is that
more than one process may be trying to manipulate the shared state at
the same time. For the bank account example, during each transaction,
each customer should be able to act as if the other customers did not
exist. When a customer changes the balance in a way that depends on
the balance, he must be able to assume that, just before the moment of
change, the balance is still what he thought it was.
Correct behavior of concurrent programs
e above example typiﬁes the subtle bugs that can creep into concur
rent programs. e root of this complexity lies in the assignments to
variables that are shared among the diﬀerent processes. We already
know that we must be careful in writing programs that use set!, be
cause the results of a computation depend on the order in which the
36An even worse failure for this system could occur if the two set! operations at
tempt to change the balance simultaneously, in which case the actual data appearing
in memory might end up being a random combination of the information being writ
ten by the two processes. Most computers have interlocks on the primitive memory
write operations, which protect against such simultaneous access. Even this seemingly
simple kind of protection, however, raises implementation challenges in the design of
multiprocessing computers, where elaborate cachecoherence protocols are required to
ensure that the various processors will maintain a consistent view of memory contents,
despite the fact that data may be replicated (“cached”) among the diﬀerent processors
to increase the speed of memory access.
406
assignments occur.37 With concurrent processes we must be especially
careful about assignments, because we may not be able to control the
order of the assignments made by the diﬀerent processes. If several such
changes might be made concurrently (as with two depositors accessing
a joint account) we need some way to ensure that our system behaves
correctly. For example, in the case of withdrawals from a joint bank ac
count, we must ensure that money is conserved. To make concurrent
programs behave correctly, we may have to place some restrictions on
concurrent execution.
One possible restriction on concurrency would stipulate that no two
operations that change any shared state variables can occur at the same
time. is is an extremely stringent requirement. For distributed bank
ing, it would require the system designer to ensure that only one trans
action could proceed at a time. is would be both ineﬃcient and overly
conservative. Figure 3.30 shows Peter and Paul sharing a bank account,
where Paul has a private account as well. e diagram illustrates two
withdrawals from the shared account (one by Peter and one by Paul)
and a deposit to Paul’s private account.38 e two withdrawals from
the shared account must not be concurrent (since both access and up
date the same account), and Paul’s deposit and withdrawal must not be
concurrent (since both access and update the amount in Paul’s wallet).
But there should be no problem permiing Paul’s deposit to his pri
vate account to proceed concurrently with Peter’s withdrawal from the
shared account.
A less stringent restriction on concurrency would ensure that a con
37e factorial program in Section 3.1.3 illustrates this for a single sequential process.
38e columns show the contents of Peter’s wallet, the joint account (in Bank1),
Paul’s wallet, and Paul’s private account (in Bank2), before and aer each withdrawal
(W) and deposit (D). Peter withdraws $10 from Bank1; Paul deposits $5 in Bank2, then
withdraws $25 from Bank1.
407
Figure 3.30: Concurrent deposits and withdrawals from a
joint account in Bank1 and a private account in Bank2.
current system produces the same result as if the processes had run
sequentially in some order. ere are two important aspects to this re
quirement. First, it does not require the processes to actually run se
quentially, but only to produce results that are the same as if they had
run sequentially. For the example in Figure 3.30, the designer of the
bank account system can safely allow Paul’s deposit and Peter’s with
drawal to happen concurrently, because the net result will be the same
as if the two operations had happened sequentially. Second, there may
be more than one possible “correct” result produced by a concurrent
program, because we require only that the result be the same as for
408
$100$7$5$300$0$305$305$25$65$17$17$90WWDtimePeterBank1PaulBank2some sequential order. For example, suppose that Peter and Paul’s joint
account starts out with $100, and Peter deposits $40 while Paul concur
rently withdraws half the money in the account. en sequential exe
cution could result in the account balance being either $70 or $90 (see
Exercise 3.38).39
ere are still weaker requirements for correct execution of con
current programs. A program for simulating diﬀusion (say, the ﬂow of
heat in an object) might consist of a large number of processes, each
one representing a small volume of space, that update their values con
currently. Each process repeatedly changes its value to the average of
its own value and its neighbors’ values. is algorithm converges to the
right answer independent of the order in which the operations are done;
there is no need for any restrictions on concurrent use of the shared val
ues.
Exercise 3.38: Suppose that Peter, Paul, and Mary share
a joint bank account that initially contains $100. Concur
rently, Peter deposits $10, Paul withdraws $20, and Mary
withdraws half the money in the account, by executing the
following commands:
Peter: (set! balance (+ balance 10))
Paul: (set! balance ( balance 20))
Mary: (set! balance ( balance (/ balance 2)))
a. List all the diﬀerent possible values for balance aer
these three transactions have been completed, assum
39 A more formal way to express this idea is to say that concurrent programs are
inherently nondeterministic. at is, they are described not by singlevalued functions,
but by functions whose results are sets of possible values. In Section 4.3 we will study
a language for expressing nondeterministic computations.
409
ing that the banking system forces the three processes
to run sequentially in some order.
b. What are some other values that could be produced
if the system allows the processes to be interleaved?
Draw timing diagrams like the one in Figure 3.29 to
explain how these values can occur.
3.4.2 Mechanisms for Controlling Concurrency
We’ve seen that the diﬃculty in dealing with concurrent processes is
rooted in the need to consider the interleaving of the order of events in
the diﬀerent processes. For example, suppose we have two processes,
one with three ordered events (a; b; c) and one with three ordered events
(x ; y; z). If the two processes run concurrently, with no constraints on
how their execution is interleaved, then there are 20 diﬀerent possible
orderings for the events that are consistent with the individual order
ings for the two processes:
(a,b,c,x,y,z)
(a,b,x,c,y,z)
(a,b,x,y,c,z)
(a,b,x,y,z,c)
(a,x,b,c,y,z)
(a,x,b,y,c,z)
(a,x,b,y,z,c)
(a,x,y,b,c,z)
(a,x,y,b,z,c)
(a,x,y,z,b,c)
(x,a,b,c,y,z) (x,a,y,z,b,c)
(x,a,b,y,c,z) (x,y,a,b,c,z)
(x,a,b,y,z,c) (x,y,a,b,z,c)
(x,a,y,b,c,z) (x,y,a,z,b,c)
(x,a,y,b,z,c) (x,y,z,a,b,c)
As programmers designing this system, we would have to consider the
eﬀects of each of these 20 orderings and check that each behavior is
acceptable. Such an approach rapidly becomes unwieldy as the numbers
of processes and events increase.
A more practical approach to the design of concurrent systems is to
devise general mechanisms that allow us to constrain the interleaving of
concurrent processes so that we can be sure that the program behavior
410
is correct. Many mechanisms have been developed for this purpose. In
this section, we describe one of them, the serializer.
Serializing access to shared state
Serialization implements the following idea: Processes will execute con
currently, but there will be certain collections of procedures that cannot
be executed concurrently. More precisely, serialization creates distin
guished sets of procedures such that only one execution of a procedure
in each serialized set is permied to happen at a time. If some procedure
in the set is being executed, then a process that aempts to execute any
procedure in the set will be forced to wait until the ﬁrst execution has
ﬁnished.
We can use serialization to control access to shared variables. For
example, if we want to update a shared variable based on the previ
ous value of that variable, we put the access to the previous value of
the variable and the assignment of the new value to the variable in the
same procedure. We then ensure that no other procedure that assigns
to the variable can run concurrently with this procedure by serializing
all of these procedures with the same serializer. is guarantees that
the value of the variable cannot be changed between an access and the
corresponding assignment.
Serializers in Scheme
To make the above mechanism more concrete, suppose that we have
extended Scheme to include a procedure called parallelexecute:
(parallelexecute ⟨p1⟩ ⟨p2⟩ : : : ⟨pk⟩)
Each ⟨p⟩ must be a procedure of no arguments. parallelexecute cre
ates a separate process for each⟨p⟩, which applies⟨p⟩ (to no arguments).
411
ese processes all run concurrently.40
As an example of how this is used, consider
(define x 10)
(parallelexecute
(lambda () (set! x (* x x)))
(lambda () (set! x (+ x 1))))
is creates two concurrent processes—P1, which sets x to x times x,
and P2, which increments x. Aer execution is complete, x will be le
with one of ﬁve possible values, depending on the interleaving of the
events of P1 and P2:
101: P1 sets x to 100 and then P2 increments x to 101.
121: P2 increments x to 11 and then P1 sets x to x * x.
110: P2 changes x from 10 to 11 between the two times that
P1 accesses the value of x during the evaluation of (* x x).
11: P2 accesses x, then P1 sets x to 100, then P2 sets x.
100: P1 accesses x (twice), then P2 sets x to 11, then P1 sets x.
We can constrain the concurrency by using serialized procedures, which
are created by serializers. Serializers are constructed by makeserializer,
whose implementation is given below. A serializer takes a procedure as
argument and returns a serialized procedure that behaves like the origi
nal procedure. All calls to a given serializer return serialized procedures
in the same set.
us, in contrast to the example above, executing
(define x 10)
40parallelexecute is not part of standard Scheme, but it can be implemented in
Scheme. In our implementation, the new concurrent processes also run concur
rently with the original Scheme process. Also, in our implementation, the value re
turned by parallelexecute is a special control object that can be used to halt the
newly created processes.
412
(define s (makeserializer))
(parallelexecute
(s (lambda () (set! x (* x x))))
(s (lambda () (set! x (+ x 1)))))
can produce only two possible values for x, 101 or 121. e other pos
sibilities are eliminated, because the execution of P1 and P2 cannot be
interleaved.
Here is a version of the makeaccount procedure from Section 3.1.1,
where the deposits and withdrawals have been serialized:
(define (makeaccount balance)
(define (withdraw amount)
(if (>= balance amount)
(begin (set! balance ( balance amount))
balance)
"Insufficient funds"))
(define (deposit amount)
(set! balance (+ balance amount))
balance)
(let ((protected (makeserializer)))
(define (dispatch m)
(cond ((eq? m 'withdraw) (protected withdraw))
((eq? m 'deposit) (protected deposit))
((eq? m 'balance) balance)
(else (error "Unknown request: MAKEACCOUNT"
dispatch))
m))))
With this implementation, two processes cannot be withdrawing from
or depositing into a single account concurrently. is eliminates the
source of the error illustrated in Figure 3.29, where Peter changes the
account balance between the times when Paul accesses the balance to
compute the new value and when Paul actually performs the assign
413
ment. On the other hand, each account has its own serializer, so that
deposits and withdrawals for diﬀerent accounts can proceed concur
rently.
Exercise 3.39: Which of the ﬁve possibilities in the par
allel execution shown above remain if we instead serialize
execution as follows:
(define x 10)
(define s (makeserializer))
(parallelexecute
(lambda () (set! x ((s (lambda () (* x x))))))
(s (lambda () (set! x (+ x 1)))))
Exercise 3.40: Give all possible values of x that can result
from executing
(define x 10)
(parallelexecute (lambda () (set! x (* x x)))
(lambda () (set! x (* x x x))))
Which of these possibilities remain if we instead use seri
alized procedures:
(define x 10)
(define s (makeserializer))
(parallelexecute (s (lambda () (set! x (* x x))))
(s (lambda () (set! x (* x x x)))))
Exercise 3.41: Ben Bitdiddle worries that it would be bet
ter to implement the bank account as follows (where the
commented line has been changed):
414
(define (makeaccount balance)
(define (withdraw amount)
(if (>= balance amount)
(begin (set! balance
( balance amount))
balance)
"Insufficient funds"))
(define (deposit amount)
(set! balance (+ balance amount))
balance)
(let ((protected (makeserializer)))
(define (dispatch m)
(cond ((eq? m 'withdraw) (protected withdraw))
((eq? m 'deposit) (protected deposit))
((eq? m 'balance)
((protected
(lambda () balance)))) ; serialized
(else
(error "Unknown request: MAKEACCOUNT"
dispatch))
m))))
because allowing unserialized access to the bank balance
can result in anomalous behavior. Do you agree? Is there
any scenario that demonstrates Ben’s concern?
Exercise 3.42: Ben Bitdiddle suggests that it’s a waste of
time to create a new serialized procedure in response to
every withdraw and deposit message. He says that make
account could be changed so that the calls to protected
are done outside the dispatch procedure. at is, an ac
count would return the same serialized procedure (which
415
was created at the same time as the account) each time it is
asked for a withdrawal procedure.
(define (makeaccount balance)
(define (withdraw amount)
(if (>= balance amount)
(begin (set! balance ( balance amount))
balance)
"Insufficient funds"))
(define (deposit amount)
(set! balance (+ balance amount))
balance)
(let ((protected (makeserializer)))
(let ((protectedwithdraw (protected withdraw))
(protecteddeposit (protected deposit)))
(define (dispatch m)
(cond ((eq? m 'withdraw) protectedwithdraw)
((eq? m 'deposit) protecteddeposit)
((eq? m 'balance) balance)
(else
(error "Unknown request: MAKEACCOUNT"
dispatch)))
m))))
Is this a safe change to make? In particular, is there any dif
ference in what concurrency is allowed by these two ver
sions of makeaccount?
Complexity of using multiple shared resources
Serializers provide a powerful abstraction that helps isolate the com
plexities of concurrent programs so that they can be dealt with carefully
and (hopefully) correctly. However, while using serializers is relatively
416
straightforward when there is only a single shared resource (such as
a single bank account), concurrent programming can be treacherously
diﬃcult when there are multiple shared resources.
To illustrate one of the diﬃculties that can arise, suppose we wish to
swap the balances in two bank accounts. We access each account to ﬁnd
the balance, compute the diﬀerence between the balances, withdraw
this diﬀerence from one account, and deposit it in the other account.
We could implement this as follows:41
(define (exchange account1 account2)
(let ((difference ( (account1 'balance)
(account2 'balance))))
((account1 'withdraw) difference)
((account2 'deposit) difference)))
is procedure works well when only a single process is trying to do
the exchange. Suppose, however, that Peter and Paul both have access
to accounts a1, a2, and a3, and that Peter exchanges a1 and a2 while
Paul concurrently exchanges a1 and a3. Even with account deposits and
withdrawals serialized for individual accounts (as in the makeaccount
procedure shown above in this section), exchange can still produce in
correct results. For example, Peter might compute the diﬀerence in the
balances for a1 and a2, but then Paul might change the balance in a1
before Peter is able to complete the exchange.42 For correct behavior,
we must arrange for the exchange procedure to lock out any other con
current accesses to the accounts during the entire time of the exchange.
41We have simpliﬁed exchange by exploiting the fact that our deposit message ac
cepts negative amounts. (is is a serious bug in our banking system!)
42If the account balances start out as $10, $20, and $30, then aer any number of
concurrent exchanges, the balances should still be $10, $20, and $30 in some order.
Serializing the deposits to individual accounts is not suﬃcient to guarantee this. See
Exercise 3.43.
417
One way we can accomplish this is by using both accounts’ seri
alizers to serialize the entire exchange procedure. To do this, we will
arrange for access to an account’s serializer. Note that we are deliber
ately breaking the modularity of the bankaccount object by exposing
the serializer. e following version of makeaccount is identical to the
original version given in Section 3.1.1, except that a serializer is pro
vided to protect the balance variable, and the serializer is exported via
message passing:
(define (makeaccountandserializer balance)
(define (withdraw amount)
(if (>= balance amount)
(begin (set! balance ( balance amount))
balance)
"Insufficient funds"))
(define (deposit amount)
(set! balance (+ balance amount))
balance)
(let ((balanceserializer (makeserializer)))
(define (dispatch m)
(cond ((eq? m 'withdraw) withdraw)
((eq? m 'deposit) deposit)
((eq? m 'balance) balance)
((eq? m 'serializer) balanceserializer)
(else (error "Unknown request: MAKEACCOUNT" m))))
dispatch))
We can use this to do serialized deposits and withdrawals. However,
unlike our earlier serialized account, it is now the responsibility of each
user of bankaccount objects to explicitly manage the serialization, for
example as follows:43
43Exercise 3.45 investigates why deposits and withdrawals are no longer automati
cally serialized by the account.
418
(define (deposit account amount)
(let ((s (account 'serializer))
(d (account 'deposit)))
((s d) amount)))
Exporting the serializer in this way gives us enough ﬂexibility to imple
ment a serialized exchange program. We simply serialize the original
exchange procedure with the serializers for both accounts:
(define (serializedexchange account1 account2)
(let ((serializer1 (account1 'serializer))
(serializer2 (account2 'serializer)))
((serializer1 (serializer2 exchange))
account1
account2)))
Exercise 3.43: Suppose that the balances in three accounts
start out as $10, $20, and $30, and that multiple processes
run, exchanging the balances in the accounts. Argue that if
the processes are run sequentially, aer any number of con
current exchanges, the account balances should be $10, $20,
and $30 in some order. Draw a timing diagram like the one
in Figure 3.29 to show how this condition can be violated
if the exchanges are implemented using the ﬁrst version of
the accountexchange program in this section. On the other
hand, argue that even with this exchange program, the sum
of the balances in the accounts will be preserved. Draw a
timing diagram to show how even this condition would be
violated if we did not serialize the transactions on individ
ual accounts.
Exercise 3.44: Consider the problem of transferring an amount
from one account to another. Ben Bitdiddle claims that this
419
can be accomplished with the following procedure, even if
there are multiple people concurrently transferring money
among multiple accounts, using any account mechanism
that serializes deposit and withdrawal transactions, for ex
ample, the version of makeaccount in the text above.
(define (transfer fromaccount toaccount amount)
((fromaccount 'withdraw) amount)
((toaccount 'deposit) amount))
Louis Reasoner claims that there is a problem here, and
that we need to use a more sophisticated method, such as
the one required for dealing with the exchange problem. Is
Louis right? If not, what is the essential diﬀerence between
the transfer problem and the exchange problem? (You should
assume that the balance in fromaccount is at least amount.)
Exercise 3.45: Louis Reasoner thinks our bankaccount sys
tem is unnecessarily complex and errorprone now that de
posits and withdrawals aren’t automatically serialized. He
suggests that makeaccountandserializer should have
exported the serializer (for use by such procedures as serialized
exchange) in addition to (rather than instead o) using it
to serialize accounts and deposits as makeaccount did. He
proposes to redeﬁne accounts as follows:
(define (makeaccountandserializer balance)
(define (withdraw amount)
(if (>= balance amount)
(begin (set! balance ( balance amount)) balance)
"Insufficient funds"))
(define (deposit amount)
(set! balance (+ balance amount)) balance)
420
(let ((balanceserializer (makeserializer)))
(define (dispatch m)
(cond ((eq? m 'withdraw) (balanceserializer withdraw))
((eq? m 'deposit) (balanceserializer deposit))
((eq? m 'balance) balance)
((eq? m 'serializer) balanceserializer)
(else (error "Unknown request: MAKEACCOUNT" m))))
dispatch))
en deposits are handled as with the original makeaccount:
(define (deposit account amount)
((account 'deposit) amount))
Explain what is wrong with Louis’s reasoning. In particu
lar, consider what happens when serializedexchange is
called.
Implementing serializers
We implement serializers in terms of a more primitive synchroniza
tion mechanism called a mutex. A mutex is an object that supports two
operations—the mutex can be acquired, and the mutex can be released.
Once a mutex has been acquired, no other acquire operations on that
mutex may proceed until the mutex is released.44 In our implementa
44e term “mutex” is an abbreviation for mutual exclusion. e general problem of
arranging a mechanism that permits concurrent processes to safely share resources is
called the mutual exclusion problem. Our mutex is a simple variant of the semaphore
mechanism (see Exercise 3.47), which was introduced in the “THE” Multiprogramming
System developed at the Technological University of Eindhoven and named for the
university’s initials in Dutch (Dijkstra 1968a). e acquire and release operations were
originally called P and V, from the Dutch words passeren (to pass) and vrijgeven (to
release), in reference to the semaphores used on railroad systems. Dijkstra’s classic
exposition (Dijkstra 1968b) was one of the ﬁrst to clearly present the issues of concur
421
tion, each serializer has an associated mutex. Given a procedure p, the
serializer returns a procedure that acquires the mutex, runs p, and then
releases the mutex. is ensures that only one of the procedures pro
duced by the serializer can be running at once, which is precisely the
serialization property that we need to guarantee.
(define (makeserializer)
(let ((mutex (makemutex)))
(lambda (p)
(define (serializedp . args)
(mutex 'acquire)
(let ((val (apply p args)))
(mutex 'release)
val))
serializedp)))
e mutex is a mutable object (here we’ll use a oneelement list, which
we’ll refer to as a cell) that can hold the value true or false. When the
value is false, the mutex is available to be acquired. When the value is
true, the mutex is unavailable, and any process that aempts to acquire
the mutex must wait.
Our mutex constructor makemutex begins by initializing the cell
contents to false. To acquire the mutex, we test the cell. If the mutex
is available, we set the cell contents to true and proceed. Otherwise,
we wait in a loop, aempting to acquire over and over again, until we
ﬁnd that the mutex is available.45 To release the mutex, we set the cell
rency control, and showed how to use semaphores to handle a variety of concurrency
problems.
45In most timeshared operating systems, processes that are blocked by a mutex do
not waste time “busywaiting” as above. Instead, the system schedules another process
to run while the ﬁrst is waiting, and the blocked process is awakened when the mutex
becomes available.
422
contents to false.
(define (makemutex)
(let ((cell (list false)))
(define (themutex m)
(cond ((eq? m 'acquire)
(if (testandset! cell)
(themutex 'acquire))) ; retry
((eq? m 'release) (clear! cell))))
themutex))
(define (clear! cell) (setcar! cell false))
testandset! tests the cell and returns the result of the test. In addi
tion, if the test was false, testandset! sets the cell contents to true
before returning false. We can express this behavior as the following
procedure:
(define (testandset! cell)
(if (car cell) true (begin (setcar! cell true) false)))
However, this implementation of testandset! does not suﬃce as
it stands. ere is a crucial subtlety here, which is the essential place
where concurrency control enters the system: e testandset! op
eration must be performed atomically. at is, we must guarantee that,
once a process has tested the cell and found it to be false, the cell con
tents will actually be set to true before any other process can test the
cell. If we do not make this guarantee, then the mutex can fail in a way
similar to the bankaccount failure in Figure 3.29. (See Exercise 3.46.)
e actual implementation of testandset! depends on the de
tails of how our system runs concurrent processes. For example, we
might be executing concurrent processes on a sequential processor us
ing a timeslicing mechanism that cycles through the processes, permit
ting each process to run for a short time before interrupting it and mov
423
ing on to the next process. In that case, testandset! can work by dis
abling time slicing during the testing and seing.46 Alternatively, mul
tiprocessing computers provide instructions that support atomic oper
ations directly in hardware.47
Exercise 3.46: Suppose that we implement testandset!
using an ordinary procedure as shown in the text, without
aempting to make the operation atomic. Draw a timing
46In Scheme for a single processor, which uses a timeslicing model, testand
set! can be implemented as follows:
(define (testandset! cell)
(withoutinterrupts
(lambda ()
(if (car cell)
true
(begin (setcar! cell true)
false)))))
withoutinterrupts disables timeslicing interrupts while its procedure argument is
being executed.
47ere are many variants of such instructions—including testandset, testand
clear, swap, compareandexchange, loadreserve, and storeconditional—whose design
must be carefully matched to the machine’s processormemory interface. One issue that
arises here is to determine what happens if two processes aempt to acquire the same
resource at exactly the same time by using such an instruction. is requires some
mechanism for making a decision about which process gets control. Such a mechanism
is called an arbiter. Arbiters usually boil down to some sort of hardware device. Un
fortunately, it is possible to prove that one cannot physically construct a fair arbiter
that works 100% of the time unless one allows the arbiter an arbitrarily long time to
make its decision. e fundamental phenomenon here was originally observed by the
fourteenthcentury French philosopher Jean Buridan in his commentary on Aristotle’s
De caelo. Buridan argued that a perfectly rational dog placed between two equally at
tractive sources of food will starve to death, because it is incapable of deciding which
to go to ﬁrst.
424
diagram like the one in Figure 3.29 to demonstrate how the
mutex implementation can fail by allowing two processes
to acquire the mutex at the same time.
Exercise 3.47: A semaphore (of size n) is a generalization of
a mutex. Like a mutex, a semaphore supports acquire and
release operations, but it is more general in that up to n
processes can acquire it concurrently. Additional processes
that aempt to acquire the semaphore must wait for release
operations. Give implementations of semaphores
a. in terms of mutexes
b. in terms of atomic testandset! operations.
Deadlock
Now that we have seen how to implement serializers, we can see that
account exchanging still has a problem, even with the serialized
exchange procedure above. Imagine that Peter aempts to exchange
a1 with a2 while Paul concurrently aempts to exchange a2 with a1.
Suppose that Peter’s process reaches the point where it has entered a
serialized procedure protecting a1 and, just aer that, Paul’s process en
ters a serialized procedure protecting a2. Now Peter cannot proceed (to
enter a serialized procedure protecting a2) until Paul exits the serialized
procedure protecting a2. Similarly, Paul cannot proceed until Peter exits
the serialized procedure protecting a1. Each process is stalled forever,
waiting for the other. is situation is called a deadlock. Deadlock is al
ways a danger in systems that provide concurrent access to multiple
shared resources.
One way to avoid the deadlock in this situation is to give each ac
count a unique identiﬁcation number and rewrite serializedexchange
425
so that a process will always aempt to enter a procedure protecting the
lowestnumbered account ﬁrst. Although this method works well for
the exchange problem, there are other situations that require more so
phisticated deadlockavoidance techniques, or where deadlock cannot
be avoided at all. (See Exercise 3.48 and Exercise 3.49.)48
Exercise 3.48: Explain in detail why the deadlockavoidance
method described above, (i.e., the accounts are numbered,
and each process aempts to acquire the smallernumbered
account ﬁrst) avoids deadlock in the exchange problem. Re
write serializedexchange to incorporate this idea. (You
will also need to modify makeaccount so that each account
is created with a number, which can be accessed by sending
an appropriate message.)
Exercise 3.49: Give a scenario where the deadlockavoid
ance mechanism described above does not work. (Hint: In
the exchange problem, each process knows in advance which
accounts it will need to get access to. Consider a situation
where a process must get access to some shared resources
before it can know which additional shared resources it will
require.)
48e general technique for avoiding deadlock by numbering the shared resources
and acquiring them in order is due to Havender (1968). Situations where deadlock can
not be avoided require deadlockrecovery methods, which entail having processes “back
out” of the deadlocked state and try again. Deadlockrecovery mechanisms are widely
used in database management systems, a topic that is treated in detail in Gray and
Reuter 1993.
426
Concurrency, time, and communication
We’ve seen how programming concurrent systems requires controlling
the ordering of events when diﬀerent processes access shared state, and
we’ve seen how to achieve this control through judicious use of serial
izers. But the problems of concurrency lie deeper than this, because,
from a fundamental point of view, it’s not always clear what is meant
by “shared state.”
Mechanisms such as testandset! require processes to examine a
global shared ﬂag at arbitrary times. is is problematic and ineﬃcient
to implement in modern highspeed processors, where due to optimiza
tion techniques such as pipelining and cached memory, the contents
of memory may not be in a consistent state at every instant. In con
temporary multiprocessing systems, therefore, the serializer paradigm
is being supplanted by new approaches to concurrency control.49
e problematic aspects of shared state also arise in large, distributed
systems. For instance, imagine a distributed banking system where indi
vidual branch banks maintain local values for bank balances and period
ically compare these with values maintained by other branches. In such
a system the value of “the account balance” would be undetermined,
except right aer synchronization. If Peter deposits money in an ac
count he holds jointly with Paul, when should we say that the account
balance has changed—when the balance in the local branch changes, or
not until aer the synchronization? And if Paul accesses the account
49One such alternative to serialization is called barrier synchronization. e program
mer permits concurrent processes to execute as they please, but establishes certain
synchronization points (“barriers”) through which no process can proceed until all the
processes have reached the barrier. Modern processors provide machine instructions
that permit programmers to establish synchronization points at places where consis
tency is required. e PowerPC, for example, includes for this purpose two instructions
called and (Enforced Inorder Execution of Input/Output).
427
from a diﬀerent branch, what are the reasonable constraints to place on
the banking system such that the behavior is “correct”? e only thing
that might maer for correctness is the behavior observed by Peter and
Paul individually and the “state” of the account immediately aer syn
chronization. estions about the “real” account balance or the order of
events between synchronizations may be irrelevant or meaningless.50
e basic phenomenon here is that synchronizing diﬀerent pro
cesses, establishing shared state, or imposing an order on events re
quires communication among the processes. In essence, any notion of
time in concurrency control must be intimately tied to communica
tion.51 It is intriguing that a similar connection between time and com
munication also arises in the eory of Relativity, where the speed of
light (the fastest signal that can be used to synchronize events) is a
fundamental constant relating time and space. e complexities we en
counter in dealing with time and state in our computational models may
in fact mirror a fundamental complexity of the physical universe.
3.5 Streams
We’ve gained a good understanding of assignment as a tool in modeling,
as well as an appreciation of the complex problems that assignment
raises. It is time to ask whether we could have gone about things in a
diﬀerent way, so as to avoid some of these problems. In this section,
50is may seem like a strange point of view, but there are systems that work this
way. International charges to creditcard accounts, for example, are normally cleared
on a percountry basis, and the charges made in diﬀerent countries are periodically
reconciled. us the account balance may be diﬀerent in diﬀerent countries.
51For distributed systems, this perspective was pursued by Lamport (1978), who
showed how to use communication to establish “global clocks” that can be used to
establish orderings on events in distributed systems.
428
we explore an alternative approach to modeling state, based on data
structures called streams. As we shall see, streams can mitigate some of
the complexity of modeling state.
Let’s step back and review where this complexity comes from. In
an aempt to model realworld phenomena, we made some apparently
reasonable decisions: We modeled realworld objects with local state by
computational objects with local variables. We identiﬁed time variation
in the real world with time variation in the computer. We implemented
the time variation of the states of the model objects in the computer
with assignments to the local variables of the model objects.
Is there another approach? Can we avoid identifying time in the
computer with time in the modeled world? Must we make the model
change with time in order to model phenomena in a changing world?
ink about the issue in terms of mathematical functions. We can de
scribe the timevarying behavior of a quantity x as a function of time
x(t). If we concentrate on x instant by instant, we think of it as a chang
ing quantity. Yet if we concentrate on the entire time history of values,
we do not emphasize change—the function itself does not change.52
If time is measured in discrete steps, then we can model a time func
tion as a (possibly inﬁnite) sequence. In this section, we will see how to
model change in terms of sequences that represent the time histories
of the systems being modeled. To accomplish this, we introduce new
data structures called streams. From an abstract point of view, a stream
is simply a sequence. However, we will ﬁnd that the straightforward
implementation of streams as lists (as in Section 2.2.1) doesn’t fully re
52Physicists sometimes adopt this view by introducing the “world lines” of particles
as a device for reasoning about motion. We’ve also already mentioned (Section 2.2.3)
that this is the natural way to think about signalprocessing systems. We will explore
applications of streams to signal processing in Section 3.5.3.
429
veal the power of stream processing. As an alternative, we introduce
the technique of delayed evaluation, which enables us to represent very
large (even inﬁnite) sequences as streams.
Stream processing lets us model systems that have state without
ever using assignment or mutable data. is has important implications,
both theoretical and practical, because we can build models that avoid
the drawbacks inherent in introducing assignment. On the other hand,
the stream framework raises diﬃculties of its own, and the question
of which modeling technique leads to more modular and more easily
maintained systems remains open.
3.5.1 Streams Are Delayed Lists
As we saw in Section 2.2.3, sequences can serve as standard interfaces
for combining program modules. We formulated powerful abstractions
for manipulating sequences, such as map, filter, and accumulate, that
capture a wide variety of operations in a manner that is both succinct
and elegant.
Unfortunately, if we represent sequences as lists, this elegance is
bought at the price of severe ineﬃciency with respect to both the time
and space required by our computations. When we represent manip
ulations on sequences as transformations of lists, our programs must
construct and copy data structures (which may be huge) at every step
of a process.
To see why this is true, let us compare two programs for computing
the sum of all the prime numbers in an interval. e ﬁrst program is
wrien in standard iterative style:53
53Assume that we have a predicate prime? (e.g., as in Section 1.2.6) that tests for
primality.
430
(define (sumprimes a b)
(define (iter count accum)
(cond ((> count b) accum)
((prime? count)
(iter (+ count 1) (+ count accum)))
(else (iter (+ count 1) accum))))
(iter a 0))
e second program performs the same computation using the sequence
operations of Section 2.2.3:
(define (sumprimes a b)
(accumulate +
0
(filter prime?
(enumerateinterval a b))))
In carrying out the computation, the ﬁrst program needs to store only
the sum being accumulated. In contrast, the ﬁlter in the second pro
gram cannot do any testing until enumerateinterval has constructed
a complete list of the numbers in the interval. e ﬁlter generates an
other list, which in turn is passed to accumulate before being collapsed
to form a sum. Such large intermediate storage is not needed by the ﬁrst
program, which we can think of as enumerating the interval incremen
tally, adding each prime to the sum as it is generated.
e ineﬃciency in using lists becomes painfully apparent if we use
the sequence paradigm to compute the second prime in the interval
from 10,000 to 1,000,000 by evaluating the expression
(car (cdr (filter prime?
(enumerateinterval 10000 1000000))))
is expression does ﬁnd the second prime, but the computational over
head is outrageous. We construct a list of almost a million integers, ﬁlter
431
this list by testing each element for primality, and then ignore almost
all of the result. In a more traditional programming style, we would in
terleave the enumeration and the ﬁltering, and stop when we reached
the second prime.
Streams are a clever idea that allows one to use sequence manipu
lations without incurring the costs of manipulating sequences as lists.
With streams we can achieve the best of both worlds: We can formu
late programs elegantly as sequence manipulations, while aaining the
eﬃciency of incremental computation. e basic idea is to arrange to
construct a stream only partially, and to pass the partial construction
to the program that consumes the stream. If the consumer aempts to
access a part of the stream that has not yet been constructed, the stream
will automatically construct just enough more of itself to produce the
required part, thus preserving the illusion that the entire stream exists.
In other words, although we will write programs as if we were process
ing complete sequences, we design our stream implementation to au
tomatically and transparently interleave the construction of the stream
with its use.
On the surface, streams are just lists with diﬀerent names for the
procedures that manipulate them. ere is a constructor, consstream,
and two selectors, streamcar and streamcdr, which satisfy the con
straints
(streamcar (consstream x y)) = x
(streamcdr (consstream x y)) = y
ere is a distinguishable object, theemptystream, which cannot be
the result of any consstream operation, and which can be identiﬁed
with the predicate streamnull?.54 us we can make and use streams,
54In the implementation, theemptystream is the same as the empty list '(),
and streamnull? is the same as null?.
432
in just the same way as we can make and use lists, to represent aggregate
data arranged in a sequence. In particular, we can build stream analogs
of the list operations from Chapter 2, such as listref, map, and for
each:55
(define (streamref s n)
(if (= n 0)
(streamcar s)
(streamref (streamcdr s) ( n 1))))
(define (streammap proc s)
(if (streamnull? s)
theemptystream
(consstream (proc (streamcar s))
(streammap proc (streamcdr s)))))
(define (streamforeach proc s)
(if (streamnull? s)
'done
(begin (proc (streamcar s))
(streamforeach proc (streamcdr s)))))
streamforeach is useful for viewing streams:
(define (displaystream s)
(streamforeach displayline s))
(define (displayline x) (newline) (display x))
To make the stream implementation automatically and transparently
interleave the construction of a stream with its use, we will arrange for
55is should bother you. e fact that we are deﬁning such similar procedures for
streams and lists indicates that we are missing some underlying abstraction. Unfor
tunately, in order to exploit this abstraction, we will need to exert ﬁner control over
the process of evaluation than we can at present. We will discuss this point further at
the end of Section 3.5.4. In Section 4.2, we’ll develop a framework that uniﬁes lists and
streams.
433
the cdr of a stream to be evaluated when it is accessed by the stream
cdr procedure rather than when the stream is constructed by cons
stream. is implementation choice is reminiscent of our discussion of
rational numbers in Section 2.1.2, where we saw that we can choose
to implement rational numbers so that the reduction of numerator and
denominator to lowest terms is performed either at construction time
or at selection time. e two rationalnumber implementations produce
the same data abstraction, but the choice has an eﬀect on eﬃciency.
ere is a similar relationship between streams and ordinary lists. As a
data abstraction, streams are the same as lists. e diﬀerence is the time
at which the elements are evaluated. With ordinary lists, both the car
and the cdr are evaluated at construction time. With streams, the cdr
is evaluated at selection time.
Our implementation of streams will be based on a special form called
delay. Evaluating (delay ⟨exp⟩) does not evaluate the expression⟨exp⟩,
but rather returns a socalled delayed object, which we can think of as
a “promise” to evaluate ⟨exp⟩ at some future time. As a companion to
delay, there is a procedure called force that takes a delayed object as
argument and performs the evaluation—in eﬀect, forcing the delay to
fulﬁll its promise. We will see below how delay and force can be im
plemented, but ﬁrst let us use these to construct streams.
consstream is a special form deﬁned so that
(consstream ⟨a⟩ ⟨b⟩)
is equivalent to
(cons ⟨a⟩ (delay ⟨b⟩))
What this means is that we will construct streams using pairs. How
ever, rather than placing the value of the rest of the stream into the cdr
of the pair we will put there a promise to compute the rest if it is ever
434
requested. streamcar and streamcdr can now be deﬁned as proce
dures:
(define (streamcar stream) (car stream))
(define (streamcdr stream) (force (cdr stream)))
streamcar selects the car of the pair; streamcdr selects the cdr of
the pair and evaluates the delayed expression found there to obtain the
rest of the stream.56
The stream implementation in action
To see how this implementation behaves, let us analyze the “outra
geous” prime computation we saw above, reformulated in terms of streams:
(streamcar
(streamcdr
(streamfilter prime?
(streamenumerateinterval
10000 1000000))))
We will see that it does indeed work eﬃciently.
We begin by calling streamenumerateinterval with the argu
ments 10,000 and 1,000,000. streamenumerateinterval is the stream
analog of enumerateinterval (Section 2.2.3):
(define (streamenumerateinterval low high)
(if (> low high)
theemptystream
(consstream
56Although streamcar and streamcdr can be deﬁned as procedures, consstream
must be a special form. If consstream were a procedure, then, according to our model
of evaluation, evaluating (consstream ⟨a⟩ ⟨b⟩) would automatically cause ⟨b⟩ to be
evaluated, which is precisely what we do not want to happen. For the same reason,
delay must be a special form, though force can be an ordinary procedure.
435
low
(streamenumerateinterval (+ low 1) high))))
and thus the result returned by streamenumerateinterval, formed
by the consstream, is57
(cons 10000
(delay (streamenumerateinterval 10001 1000000)))
at is, streamenumerateinterval returns a stream represented as a
pair whose car is 10,000 and whose cdr is a promise to enumerate more
of the interval if so requested. is stream is now ﬁltered for primes,
using the stream analog of the filter procedure (Section 2.2.3):
(define (streamfilter pred stream)
(cond ((streamnull? stream) theemptystream)
((pred (streamcar stream))
(consstream (streamcar stream)
(streamfilter
pred
(streamcdr stream))))
(else (streamfilter pred (streamcdr stream)))))
streamfilter tests the streamcar of the stream (the car of the pair,
which is 10,000). Since this is not prime, streamfilter examines the
streamcdr of its input stream. e call to streamcdr forces evaluation
of the delayed streamenumerateinterval, which now returns
(cons 10001
(delay (streamenumerateinterval 10002 1000000)))
57e numbers shown here do not really appear in the delayed expression. What
actually appears is the original expression, in an environment in which the variables
are bound to the appropriate numbers. For example, (+ low 1) with low bound to
10,000 actually appears where 10001 is shown.
436
streamfilter now looks at the streamcar of this stream, 10,001,
sees that this is not prime either, forces another streamcdr, and so on,
until streamenumerateinterval yields the prime 10,007, whereupon
streamfilter, according to its deﬁnition, returns
(consstream (streamcar stream)
(streamfilter pred (streamcdr stream)))
which in this case is
(cons 10007
(delay (streamfilter
prime?
(cons 10008
(delay (streamenumerateinterval
10009
1000000))))))
is result is now passed to streamcdr in our original expression. is
forces the delayed streamfilter, which in turn keeps forcing the de
layed streamenumerateinterval until it ﬁnds the next prime, which
is 10,009. Finally, the result passed to streamcar in our original ex
pression is
(cons 10009
(delay (streamfilter
prime?
(cons 10010
(delay (streamenumerateinterval
10011
1000000))))))
streamcar returns 10,009, and the computation is complete. Only as
many integers were tested for primality as were necessary to ﬁnd the
437
second prime, and the interval was enumerated only as far as was nec
essary to feed the prime ﬁlter.
In general, we can think of delayed evaluation as “demanddriven”
programming, whereby each stage in the stream process is activated
only enough to satisfy the next stage. What we have done is to decouple
the actual order of events in the computation from the apparent struc
ture of our procedures. We write procedures as if the streams existed “all
at once” when, in reality, the computation is performed incrementally,
as in traditional programming styles.
Implementing delay and force
Although delay and force may seem like mysterious operations, their
implementation is really quite straightforward. delay must package an
expression so that it can be evaluated later on demand, and we can ac
complish this simply by treating the expression as the body of a proce
dure. delay can be a special form such that
(delay ⟨exp⟩)
is syntactic sugar for
(lambda () ⟨exp⟩)
force simply calls the procedure (of no arguments) produced by delay,
so we can implement force as a procedure:
(define (force delayedobject) (delayedobject))
is implementation suﬃces for delay and force to work as advertised,
but there is an important optimization that we can include. In many ap
plications, we end up forcing the same delayed object many times. is
can lead to serious ineﬃciency in recursive programs involving streams.
(See Exercise 3.57.) e solution is to build delayed objects so that the
438
ﬁrst time they are forced, they store the value that is computed. Subse
quent forcings will simply return the stored value without repeating the
computation. In other words, we implement delay as a specialpurpose
memoized procedure similar to the one described in Exercise 3.27. One
way to accomplish this is to use the following procedure, which takes as
argument a procedure (of no arguments) and returns a memoized ver
sion of the procedure. e ﬁrst time the memoized procedure is run, it
saves the computed result. On subsequent evaluations, it simply returns
the result.
(define (memoproc proc)
(let ((alreadyrun? false) (result false))
(lambda ()
(if (not alreadyrun?)
(begin (set! result (proc))
(set! alreadyrun? true)
result)
result))))
delay is then deﬁned so that (delay ⟨exp⟩) is equivalent to
(memoproc (lambda () ⟨exp⟩))
and force is as deﬁned previously.58
58ere are many possible implementations of streams other than the one described
in this section. Delayed evaluation, which is the key to making streams practical, was
inherent in Algol 60’s callbyname parameterpassing method. e use of this mech
anism to implement streams was ﬁrst described by Landin (1965). Delayed evaluation
for streams was introduced into Lisp by Friedman and Wise (1976). In their implemen
tation, cons always delays evaluating its arguments, so that lists automatically behave
as streams. e memoizing optimization is also known as callbyneed. e Algol com
munity would refer to our original delayed objects as callbyname thunks and to the
optimized versions as callbyneed thunks.
439
Exercise 3.50: Complete the following deﬁnition, which
generalizes streammap to allow procedures that take mul
tiple arguments, analogous to map in Section 2.2.1, Footnote
12.
(define (streammap proc . argstreams)
(if (⟨??⟩ (car argstreams))
theemptystream
(⟨??⟩
(apply proc (map ⟨??⟩ argstreams))
(apply streammap
(cons proc (map ⟨??⟩ argstreams))))))
Exercise 3.51: In order to take a closer look at delayed eval
uation, we will use the following procedure, which simply
returns its argument aer printing it:
(define (show x)
(displayline x)
x)
What does the interpreter print in response to evaluating
each expression in the following sequence?59
(define x
59Exercises such as Exercise 3.51 and Exercise 3.52 are valuable for testing our un
derstanding of how delay works. On the other hand, intermixing delayed evaluation
with printing—and, even worse, with assignment—is extremely confusing, and instruc
tors of courses on computer languages have traditionally tormented their students with
examination questions such as the ones in this section. Needless to say, writing pro
grams that depend on such subtleties is odious programming style. Part of the power
of stream processing is that it lets us ignore the order in which events actually happen
in our programs. Unfortunately, this is precisely what we cannot aﬀord to do in the
presence of assignment, which forces us to be concerned with time and change.
440
(streammap show
(streamenumerateinterval 0 10)))
(streamref x 5)
(streamref x 7)
Exercise 3.52: Consider the sequence of expressions
(define sum 0)
(define (accum x) (set! sum (+ x sum)) sum)
(define seq
(streammap accum
(streamenumerateinterval 1 20)))
(define y (streamfilter even? seq))
(define z
(streamfilter (lambda (x) (= (remainder x 5) 0))
seq))
(streamref y 7)
(displaystream z)
What is the value of sum aer each of the above expressions
is evaluated? What is the printed response to evaluating
the streamref and displaystream expressions? Would
these responses diﬀer if we had implemented (delay ⟨exp⟩)
simply as (lambda () ⟨exp⟩) without using the optimiza
tion provided by memoproc? Explain.
3.5.2 Infinite Streams
We have seen how to support the illusion of manipulating streams as
complete entities even though, in actuality, we compute only as much
of the stream as we need to access. We can exploit this technique to rep
resent sequences eﬃciently as streams, even if the sequences are very
441
long. What is more striking, we can use streams to represent sequences
that are inﬁnitely long. For instance, consider the following deﬁnition
of the stream of positive integers:
(define (integersstartingfrom n)
(consstream n (integersstartingfrom (+ n 1))))
(define integers (integersstartingfrom 1))
is makes sense because integers will be a pair whose car is 1 and
whose cdr is a promise to produce the integers beginning with 2. is
is an inﬁnitely long stream, but in any given time we can examine only
a ﬁnite portion of it. us, our programs will never know that the entire
inﬁnite stream is not there.
Using integers we can deﬁne other inﬁnite streams, such as the
stream of integers that are not divisible by 7:
(define (divisible? x y) (= (remainder x y) 0))
(define nosevens
(streamfilter (lambda (x) (not (divisible? x 7)))
integers))
en we can ﬁnd integers not divisible by 7 simply by accessing ele
ments of this stream:
(streamref nosevens 100)
117
In analogy with integers, we can deﬁne the inﬁnite stream of Fibonacci
numbers:
(define (fibgen a b) (consstream a (fibgen b (+ a b))))
(define fibs (fibgen 0 1))
fibs is a pair whose car is 0 and whose cdr is a promise to evaluate
(fibgen 1 1). When we evaluate this delayed (fibgen 1 1), it will
442
produce a pair whose car is 1 and whose cdr is a promise to evaluate
(fibgen 1 2), and so on.
For a look at a more exciting inﬁnite stream, we can generalize the
nosevens example to construct the inﬁnite stream of prime numbers,
using a method known as the sieve of Eratosthenes.60 We start with the
integers beginning with 2, which is the ﬁrst prime. To get the rest of
the primes, we start by ﬁltering the multiples of 2 from the rest of the
integers. is leaves a stream beginning with 3, which is the next prime.
Now we ﬁlter the multiples of 3 from the rest of this stream. is leaves
a stream beginning with 5, which is the next prime, and so on. In other
words, we construct the primes by a sieving process, described as fol
lows: To sieve a stream S, form a stream whose ﬁrst element is the ﬁrst
element of S and the rest of which is obtained by ﬁltering all multiples
of the ﬁrst element of S out of the rest of S and sieving the result. is
process is readily described in terms of stream operations:
(define (sieve stream)
(consstream
(streamcar stream)
(sieve (streamfilter
(lambda (x)
(not (divisible? x (streamcar stream))))
(streamcdr stream)))))
(define primes (sieve (integersstartingfrom 2)))
60Eratosthenes, a thirdcentury .. Alexandrian Greek philosopher, is famous for
giving the ﬁrst accurate estimate of the circumference of the Earth, which he computed
by observing shadows cast at noon on the day of the summer solstice. Eratosthenes’s
sieve method, although ancient, has formed the basis for specialpurpose hardware
“sieves” that, until recently, were the most powerful tools in existence for locating large
primes. Since the 70s, however, these methods have been superseded by outgrowths of
the probabilistic techniques discussed in Section 1.2.6.
443
Figure 3.31: e prime sieve viewed as a signalprocessing
system.
Now to ﬁnd a particular prime we need only ask for it:
(streamref primes 50)
233
It is interesting to contemplate the signalprocessing system set up by
sieve, shown in the “Henderson diagram” in Figure 3.31.61 e input
stream feeds into an “unconser” that separates the ﬁrst element of the
stream from the rest of the stream. e ﬁrst element is used to construct
a divisibility ﬁlter, through which the rest is passed, and the output of
the ﬁlter is fed to another sieve box. en the original ﬁrst element is
consed onto the output of the internal sieve to form the output stream.
us, not only is the stream inﬁnite, but the signal processor is also
inﬁnite, because the sieve contains a sieve within it.
61We have named these ﬁgures aer Peter Henderson, who was the ﬁrst person to
show us diagrams of this sort as a way of thinking about stream processing. Each solid
line represents a stream of values being transmied. e dashed line from the car to
the cons and the filter indicates that this is a single value rather than a stream.
444
filter:notdivisible?sievesievecarcdrconsDefining streams implicitly
e integers and fibs streams above were deﬁned by specifying “gen
erating” procedures that explicitly compute the stream elements one by
one. An alternative way to specify streams is to take advantage of de
layed evaluation to deﬁne streams implicitly. For example, the following
expression deﬁnes the stream ones to be an inﬁnite stream of ones:
(define ones (consstream 1 ones))
is works much like the deﬁnition of a recursive procedure: ones is
a pair whose car is 1 and whose cdr is a promise to evaluate ones.
Evaluating the cdr gives us again a 1 and a promise to evaluate ones,
and so on.
We can do more interesting things by manipulating streams with
operations such as addstreams, which produces the elementwise sum
of two given streams:62
(define (addstreams s1 s2) (streammap + s1 s2))
Now we can deﬁne the integers as follows:
(define integers
(consstream 1 (addstreams ones integers)))
is deﬁnes integers to be a stream whose ﬁrst element is 1 and the rest
of which is the sum of ones and integers. us, the second element of
integers is 1 plus the ﬁrst element of integers, or 2; the third element
of integers is 1 plus the second element of integers, or 3; and so on.
is deﬁnition works because, at any point, enough of the integers
stream has been generated so that we can feed it back into the deﬁnition
to produce the next integer.
We can deﬁne the Fibonacci numbers in the same style:
62is uses the generalized version of streammap from Exercise 3.50.
445
(define fibs
(consstream
0
(consstream 1 (addstreams (streamcdr fibs) fibs))))
is deﬁnition says that fibs is a stream beginning with 0 and 1, such
that the rest of the stream can be generated by adding fibs to itself
shied by one place:
1 1
0 1
1
2
2
1
3
3
2
5
5
3
8
8
5
13
13
8
21
21
13
34
: : :
: : :
: : :
= (streamcdr fibs)
= fibs
= fibs
0
1
scalestream is another useful procedure in formulating such stream
deﬁnitions. is multiplies each item in a stream by a given constant:
(define (scalestream stream factor)
(streammap (lambda (x) (* x factor))
stream))
For example,
(define double (consstream 1 (scalestream double 2)))
produces the stream of powers of 2: 1, 2, 4, 8, 16, 32, : : :.
An alternate deﬁnition of the stream of primes can be given by start
ing with the integers and ﬁltering them by testing for primality. We will
need the ﬁrst prime, 2, to get started:
(define primes
(consstream
2
(streamfilter prime? (integersstartingfrom 3))))
is deﬁnition is not so straightforward as it appears, because we will
test whether a number n is prime by checking whether n is divisible by
a prime (not by just any integer) less than or equal to
p
n:
446
(define (prime? n)
(define (iter ps)
(cond ((> (square (streamcar ps)) n) true)
((divisible? n (streamcar ps)) false)
(else (iter (streamcdr ps)))))
(iter primes))
is is a recursive deﬁnition, since primes is deﬁned in terms of the
prime? predicate, which itself uses the primes stream. e reason this
procedure works is that, at any point, enough of the primes stream has
been generated to test the primality of the numbers we need to check
next. at is, for every n we test for primality, either n is not prime (in
which case there is a prime already generated that divides it) or n is
prime (in which case there is a prime already generated—i.e., a prime
less than n—that is greater than
p
n).63
Exercise 3.53: Without running the program, describe the
elements of the stream deﬁned by
(define s (consstream 1 (addstreams s s)))
Exercise 3.54: Deﬁne a procedure mulstreams, analogous
to addstreams, that produces the elementwise product of
its two input streams. Use this together with the stream of
integers to complete the following deﬁnition of the stream
whose nth element (counting from 0) is n + 1 factorial:
63is last point is very subtle and relies on the fact that pn+1 (cid:20) p2
n. (Here, pk denotes
the kth prime.) Estimates such as these are very diﬃcult to establish. e ancient proof
by Euclid that there are an inﬁnite number of primes shows that pn+1 (cid:20) p1p2 (cid:1) (cid:1) (cid:1) pn + 1,
and no substantially beer result was proved until 1851, when the Russian mathemati
cian P. L. Chebyshev established that pn+1 (cid:20) 2pn for all n. is result, originally con
jectured in 1845, is known as Bertrand’s hypothesis. A proof can be found in section 22.3
of Hardy and Wright 1960.
447
(define factorials
(consstream 1 (mulstreams ⟨??⟩ ⟨??⟩)))
Exercise 3.55: Deﬁne a procedure partialsums that takes
as argument a stream S and returns the stream whose ele
ments are S0, S0+S1, S0+S1+S2; : : :. For example, (partial
sums integers) should be the stream 1, 3, 6, 10, 15, : : :.
Exercise 3.56: A famous problem, ﬁrst raised by R. Ham
ming, is to enumerate, in ascending order with no repeti
tions, all positive integers with no prime factors other than
2, 3, or 5. One obvious way to do this is to simply test each
integer in turn to see whether it has any factors other than
2, 3, and 5. But this is very ineﬃcient, since, as the integers
get larger, fewer and fewer of them ﬁt the requirement. As
an alternative, let us call the required stream of numbers S
and notice the following facts about it.
• S begins with 1.
• e elements of (scalestream S 2) are also ele
ments of S.
• e same is true for (scalestream S 3) and (scale
stream 5 S).
• ese are all the elements of S.
Now all we have to do is combine elements from these sources.
For this we deﬁne a procedure merge that combines two or
dered streams into one ordered result stream, eliminating
repetitions:
448
(define (merge s1 s2)
(cond ((streamnull? s1) s2)
((streamnull? s2) s1)
(else
(let ((s1car (streamcar s1))
(s2car (streamcar s2)))
(cond ((< s1car s2car)
(consstream
s1car
(merge (streamcdr s1) s2)))
((> s1car s2car)
(consstream
s2car
(merge s1 (streamcdr s2))))
(else
(consstream
s1car
(merge (streamcdr s1)
(streamcdr s2)))))))))
en the required stream may be constructed with merge,
as follows:
(define S (consstream 1 (merge ⟨??⟩ ⟨??⟩)))
Fill in the missing expressions in the places marked ⟨⁇⟩
above.
Exercise 3.57: How many additions are performed when
we compute the nth Fibonacci number using the deﬁnition
of fibs based on the addstreams procedure? Show that
the number of additions would be exponentially greater
if we had implemented (delay ⟨exp⟩) simply as (lambda
449
() ⟨exp⟩), without using the optimization provided by the
memoproc procedure described in Section 3.5.1.64
Exercise 3.58: Give an interpretation of the stream com
puted by the following procedure:
(define (expand num den radix)
(consstream
(quotient (* num radix) den)
(expand (remainder (* num radix) den) den radix)))
(quotient is a primitive that returns the integer quotient of
two integers.) What are the successive elements produced
by (expand 1 7 10)? What is produced by (expand 3 8
10)?
Exercise 3.59: In Section 2.5.3 we saw how to implement
a polynomial arithmetic system representing polynomials
as lists of terms. In a similar way, we can work with power
series, such as
ex = 1 + x +
x 2
2
+
x 3
3 (cid:1) 2
cos x = 1 (cid:0) x 2
2
sin x = x (cid:0) x 3
3 (cid:1) 2
+
+
+ : : : ;
+
x 4
4 (cid:1) 3 (cid:1) 2
x 4
4 (cid:1) 3 (cid:1) 2
x 5
5 (cid:1) 4 (cid:1) 3 (cid:1) 2
(cid:0) : : : ;
(cid:0) : : :
64is exercise shows how callbyneed is closely related to ordinary memoization as
described in Exercise 3.27. In that exercise, we used assignment to explicitly construct
a local table. Our callbyneed stream optimization eﬀectively constructs such a table
automatically, storing values in the previously forced parts of the stream.
450
represented as inﬁnite streams. We will represent the series
a0 + a1x + a2x 2 + a3x 3 + : : : as the stream whose elements
are the coeﬃcients a0, a1, a2, a3, : : :.
a. e integral of the series a0 + a1x + a2x 2 + a3x 3 + : : :
is the series
c + a0x +
1
2
a1x 2 +
1
3
a2x 3 +
1
4
a3x 4 + : : : ;
where c is any constant. Deﬁne a procedure integrate
series that takes as input a stream a0, a1, a2, : : : rep
resenting a power series and returns the stream a0,
1
2a1, 1
3a2, : : : of coeﬃcients of the nonconstant terms
of the integral of the series. (Since the result has no
constant term, it doesn’t represent a power series; when
we use integrateseries, we will cons on the ap
propriate constant.)
b. e function x 7! ex is its own derivative. is im
plies that ex and the integral of ex are the same se
ries, except for the constant term, which is e0 = 1.
Accordingly, we can generate the series for ex as
(define expseries
(consstream 1 (integrateseries expseries)))
Show how to generate the series for sine and cosine,
starting from the facts that the derivative of sine is
cosine and the derivative of cosine is the negative of
sine:
(define cosineseries (consstream 1 ⟨??⟩))
(define sineseries (consstream 0 ⟨??⟩))
451
Exercise 3.60: With power series represented as streams
of coeﬃcients as in Exercise 3.59, adding series is imple
mented by addstreams. Complete the deﬁnition of the fol
lowing procedure for multiplying series:
(define (mulseries s1 s2)
(consstream ⟨??⟩ (addstreams ⟨??⟩ ⟨??⟩)))
You can test your procedure by verifying that sin2x + cos2x = 1,
using the series from Exercise 3.59.
Exercise 3.61: Let S be a power series (Exercise 3.59) whose
constant term is 1. Suppose we want to ﬁnd the power se
ries 1=S, that is, the series X such that SX = 1. Write
S = 1 + SR where SR is the part of S aer the constant
term. en we can solve for X as follows:
S (cid:1) X = 1;
(1 + SR ) (cid:1) X = 1;
X + SR (cid:1) X = 1;
X = 1 (cid:0) SR (cid:1) X :
In other words, X is the power series whose constant term
is 1 and whose higherorder terms are given by the negative
of SR times X . Use this idea to write a procedure invert
unitseries that computes 1=S for a power series S with
constant term 1. You will need to use mulseries from Ex
ercise 3.60.
Exercise 3.62: Use the results of Exercise 3.60 and Exer
cise 3.61 to deﬁne a procedure divseries that divides two
power series. divseries should work for any two series,
452
provided that the denominator series begins with a nonzero
constant term. (If the denominator has a zero constant term,
then divseries should signal an error.) Show how to use
divseries together with the result of Exercise 3.59 to gen
erate the power series for tangent.
3.5.3 Exploiting the Stream Paradigm
Streams with delayed evaluation can be a powerful modeling tool, pro
viding many of the beneﬁts of local state and assignment. Moreover,
they avoid some of the theoretical tangles that accompany the intro
duction of assignment into a programming language.
e stream approach can be illuminating because it allows us to
build systems with diﬀerent module boundaries than systems organized
around assignment to state variables. For example, we can think of an
entire time series (or signal) as a focus of interest, rather than the values
of the state variables at individual moments. is makes it convenient
to combine and compare components of state from diﬀerent moments.
Formulating iterations as stream processes
In Section 1.2.1, we introduced iterative processes, which proceed by
updating state variables. We know now that we can represent state as
a “timeless” stream of values rather than as a set of variables to be up
dated. Let’s adopt this perspective in revisiting the squareroot proce
dure from Section 1.1.7. Recall that the idea is to generate a sequence of
beer and beer guesses for the square root of x by applying over and
over again the procedure that improves guesses:
(define (sqrtimprove guess x)
(average guess (/ x guess)))
453
In our original sqrt procedure, we made these guesses be the successive
values of a state variable. Instead we can generate the inﬁnite stream of
guesses, starting with an initial guess of 1:65
(define (sqrtstream x)
(define guesses
(consstream
1.0
(streammap (lambda (guess) (sqrtimprove guess x))
guesses)))
guesses)
(displaystream (sqrtstream 2))
1.
1.5
1.4166666666666665
1.4142156862745097
1.4142135623746899
: : :
We can generate more and more terms of the stream to get beer and
beer guesses. If we like, we can write a procedure that keeps generating
terms until the answer is good enough. (See Exercise 3.64.)
Another iteration that we can treat in the same way is to generate
an approximation to π, based upon the alternating series that we saw
in Section 1.3.1:
π
4
= 1 (cid:0) 1
3
+
1
5
(cid:0) 1
7
+ : : : :
We ﬁrst generate the stream of summands of the series (the reciprocals
of the odd integers, with alternating signs). en we take the stream of
65We can’t use let to bind the local variable guesses, because the value of guesses
depends on guesses itself. Exercise 3.63 addresses why we want a local variable here.
454
sums of more and more terms (using the partialsums procedure of
Exercise 3.55) and scale the result by 4:
(define (pisummands n)
(consstream (/ 1.0 n)
(streammap  (pisummands (+ n 2)))))
(define pistream
(scalestream (partialsums (pisummands 1)) 4))
(displaystream pistream)
4.
2.666666666666667
3.466666666666667
2.8952380952380956
3.3396825396825403
2.9760461760461765
3.2837384837384844
3.017071817071818
: : :
is gives us a stream of beer and beer approximations to π, although
the approximations converge rather slowly. Eight terms of the sequence
bound the value of π between 3.284 and 3.017.
So far, our use of the stream of states approach is not much diﬀerent
from updating state variables. But streams give us an opportunity to do
some interesting tricks. For example, we can transform a stream with
a sequence accelerator that converts a sequence of approximations to a
new sequence that converges to the same value as the original, only
faster.
One such accelerator, due to the eighteenthcentury Swiss math
ematician Leonhard Euler, works well with sequences that are partial
sums of alternating series (series of terms with alternating signs). In Eu
ler’s technique, if Sn is the nth term of the original sum sequence, then
455
the accelerated sequence has terms
Sn+1 (cid:0)
(Sn+1 (cid:0) Sn)2
Sn(cid:0)1 (cid:0) 2Sn + Sn+1
:
us, if the original sequence is represented as a stream of values, the
transformed sequence is given by
(define (eulertransform s)
(let ((s0 (streamref s 0))
(s1 (streamref s 1))
(s2 (streamref s 2)))
; Sn(cid:0)1
; Sn
; Sn+1
(consstream ( s2 (/ (square ( s2 s1))
(+ s0 (* 2 s1) s2)))
(eulertransform (streamcdr s)))))
We can demonstrate Euler acceleration with our sequence of approxi
mations to π :
(displaystream (eulertransform pistream))
3.166666666666667
3.1333333333333337
3.1452380952380956
3.13968253968254
3.1427128427128435
3.1408813408813416
3.142071817071818
3.1412548236077655
: : :
Even beer, we can accelerate the accelerated sequence, and recursively
accelerate that, and so on. Namely, we create a stream of streams (a
structure we’ll call a tableau) in which each stream is the transform of
the preceding one:
456
(define (maketableau transform s)
(consstream s (maketableau transform (transform s))))
e tableau has the form
s00
s01
s10
s02
s11
s20
s03
s12
s21
: : :
s04
s13
s22
: : :
: : :
: : :
Finally, we form a sequence by taking the ﬁrst term in each row of the
tableau:
(define (acceleratedsequence transform s)
(streammap streamcar (maketableau transform s)))
We can demonstrate this kind of “superacceleration” of the π sequence:
(displaystream
(acceleratedsequence eulertransform pistream))
4.
3.166666666666667
3.142105263157895
3.141599357319005
3.1415927140337785
3.1415926539752927
3.1415926535911765
3.141592653589778
: : :
e result is impressive. Taking eight terms of the sequence yields the
correct value of π to 14 decimal places. If we had used only the original
π sequence, we would need to compute on the order of 1013 terms (i.e.,
expanding the series far enough so that the individual terms are less
than 10
(cid:0)13) to get that much accuracy!
457
We could have implemented these acceleration techniques without
using streams. But the stream formulation is particularly elegant and
convenient because the entire sequence of states is available to us as a
data structure that can be manipulated with a uniform set of operations.
Exercise 3.63: Louis Reasoner asks why the sqrtstream
procedure was not wrien in the following more straight
forward way, without the local variable guesses:
(define (sqrtstream x)
(consstream 1.0 (streammap
(lambda (guess)
(sqrtimprove guess x))
(sqrtstream x))))
Alyssa P. Hacker replies that this version of the procedure
is considerably less eﬃcient because it performs redundant
computation. Explain Alyssa’s answer. Would the two ver
sions still diﬀer in eﬃciency if our implementation of delay
used only (lambda () ⟨exp⟩) without using the optimiza
tion provided by memoproc (Section 3.5.1)?
Exercise 3.64: Write a procedure streamlimit that takes
as arguments a stream and a number (the tolerance). It should
examine the stream until it ﬁnds two successive elements
that diﬀer in absolute value by less than the tolerance, and
return the second of the two elements. Using this, we could
compute square roots up to a given tolerance by
(define (sqrt x tolerance)
(streamlimit (sqrtstream x) tolerance))
458
Exercise 3.65: Use the series
ln 2 = 1 (cid:0) 1
2
+
1
3
(cid:0) 1
4
+ : : :
to compute three sequences of approximations to the nat
ural logarithm of 2, in the same way we did above for π.
How rapidly do these sequences converge?
Infinite streams of pairs
In Section 2.2.3, we saw how the sequence paradigm handles traditional
nested loops as processes deﬁned on sequences of pairs. If we generalize
this technique to inﬁnite streams, then we can write programs that are
not easily represented as loops, because the “looping” must range over
an inﬁnite set.
For example, suppose we want to generalize the primesumpairs
procedure of Section 2.2.3 to produce the stream of pairs of all integers
(i; j) with i (cid:20) j such that i + j is prime. If intpairs is the sequence of
all pairs of integers (i; j) with i (cid:20) j, then our required stream is simply66
(streamfilter
(lambda (pair) (prime? (+ (car pair) (cadr pair))))
intpairs)
Our problem, then, is to produce the stream intpairs. More generally,
suppose we have two streams S = (Si ) and T = (Tj ), and imagine the
inﬁnite rectangular array
(S0;T0)
(S1;T0)
(S2;T0)
: : :
(S0;T1)
(S1;T1)
(S2;T1)
(S0;T2)
(S1;T2)
(S2;T2)
: : :
: : :
: : :
66As in Section 2.2.3, we represent a pair of integers as a list rather than a Lisp pair.
459
We wish to generate a stream that contains all the pairs in the array
that lie on or above the diagonal, i.e., the pairs
(S0;T0)
(S0;T1)
(S1;T1)
(S0;T2)
(S1;T2)
(S2;T2)
: : :
: : :
: : :
: : :
(If we take both S and T to be the stream of integers, then this will be
our desired stream intpairs.)
Call the general stream of pairs (pairs S T), and consider it to be
composed of three parts: the pair (S0;T0), the rest of the pairs in the ﬁrst
row, and the remaining pairs:67
(S0;T0)
(S0;T1)
(S1;T1)
(S0;T2)
(S1;T2)
(S2;T2)
: : :
: : :
: : :
: : :
Observe that the third piece in this decomposition (pairs that are not
in the ﬁrst row) is (recursively) the pairs formed from (streamcdr S)
and (streamcdr T). Also note that the second piece (the rest of the
ﬁrst row) is
(streammap (lambda (x) (list (streamcar s) x))
(streamcdr t))
us we can form our stream of pairs as follows:
(define (pairs s t)
(consstream
(list (streamcar s) (streamcar t))
67See Exercise 3.68 for some insight into why we chose this decomposition.
460
(⟨combineinsomeway⟩
(streammap (lambda (x) (list (streamcar s) x))
(streamcdr t))
(pairs (streamcdr s) (streamcdr t)))))
In order to complete the procedure, we must choose some way to com
bine the two inner streams. One idea is to use the stream analog of the
append procedure from Section 2.2.1:
(define (streamappend s1 s2)
(if (streamnull? s1)
s2
(consstream (streamcar s1)
(streamappend (streamcdr s1) s2))))
is is unsuitable for inﬁnite streams, however, because it takes all the
elements from the ﬁrst stream before incorporating the second stream.
In particular, if we try to generate all pairs of positive integers using
(pairs integers integers)
our stream of results will ﬁrst try to run through all pairs with the ﬁrst
integer equal to 1, and hence will never produce pairs with any other
value of the ﬁrst integer.
To handle inﬁnite streams, we need to devise an order of combina
tion that ensures that every element will eventually be reached if we
let our program run long enough. An elegant way to accomplish this is
with the following interleave procedure:68
68e precise statement of the required property on the order of combination is as
follows: ere should be a function f of two arguments such that the pair correspond
ing to element i of the ﬁrst stream and element j of the second stream will appear as
element number f (i; j) of the output stream. e trick of using interleave to accom
plish this was shown to us by David Turner, who employed it in the language KRC
(Turner 1981).
461
(define (interleave s1 s2)
(if (streamnull? s1)
s2
(consstream (streamcar s1)
(interleave s2 (streamcdr s1)))))
Since interleave takes elements alternately from the two streams, ev
ery element of the second stream will eventually ﬁnd its way into the
interleaved stream, even if the ﬁrst stream is inﬁnite.
We can thus generate the required stream of pairs as
(define (pairs s t)
(consstream
(list (streamcar s) (streamcar t))
(interleave
(streammap (lambda (x) (list (streamcar s) x))
(streamcdr t))
(pairs (streamcdr s) (streamcdr t)))))
Exercise 3.66: Examine the stream (pairs integers integers).
Can you make any general comments about the order in
which the pairs are placed into the stream? For example,
approximately how many pairs precede the pair (1, 100)?
the pair (99, 100)? the pair (100, 100)? (If you can make pre
cise mathematical statements here, all the beer. But feel
free to give more qualitative answers if you ﬁnd yourself
geing bogged down.)
Exercise 3.67: Modify the pairs procedure so that (pairs
integers integers) will produce the stream of all pairs of
integers (i; j) (without the condition i (cid:20) j). Hint: You will
need to mix in an additional stream.
462
Exercise 3.68: Louis Reasoner thinks that building a stream
of pairs from three parts is unnecessarily complicated. In
stead of separating the pair (S0;T0) from the rest of the pairs
in the ﬁrst row, he proposes to work with the whole ﬁrst
row, as follows:
(define (pairs s t)
(interleave
(streammap (lambda (x) (list (streamcar s) x))
t)
(pairs (streamcdr s) (streamcdr t))))
Does this work? Consider what happens if we evaluate (pairs
integers integers) using Louis’s deﬁnition of pairs.
Exercise 3.69: Write a procedure triples that takes three
inﬁnite streams, S, T , and U , and produces the stream of
triples (Si ;Tj ; Uk ) such that i (cid:20) j (cid:20) k. Use triples to gen
erate the stream of all Pythagorean triples of positive inte
gers, i.e., the triples (i; j; k) such that i (cid:20) j and i2 + j2 = k2.
Exercise 3.70: It would be nice to be able to generate streams
in which the pairs appear in some useful order, rather than
in the order that results from an ad hoc interleaving pro
cess. We can use a technique similar to the merge procedure
of Exercise 3.56, if we deﬁne a way to say that one pair of
integers is “less than” another. One way to do this is to de
ﬁne a “weighting function” W (i; j) and stipulate that (i1; j1)
is less than (i2; j2) if W (i1; j1) < W (i2; j2). Write a proce
dure mergeweighted that is like merge, except that merge
weighted takes an additional argument weight, which is a
procedure that computes the weight of a pair, and is used
463
to determine the order in which elements should appear in
the resulting merged stream.69 Using this, generalize pairs
to a procedure weightedpairs that takes two streams, to
gether with a procedure that computes a weighting func
tion, and generates the stream of pairs, ordered according
to weight. Use your procedure to generate
a. the stream of all pairs of positive integers (i; j) with
i (cid:20) j ordered according to the sum i + j,
b. the stream of all pairs of positive integers (i; j) with
i (cid:20) j, where neitheri nor j is divisible by 2, 3, or 5, and
the pairs are ordered according to the sum 2i + 3j + 5ij.
Exercise 3.71: Numbers that can be expressed as the sum of
two cubes in more than one way are sometimes called Ra
manujan numbers, in honor of the mathematician Srinivasa
Ramanujan.70 Ordered streams of pairs provide an elegant
solution to the problem of computing these numbers. To
ﬁnd a number that can be wrien as the sum of two cubes
in two diﬀerent ways, we need only generate the stream of
pairs of integers (i; j) weighted according to the sum i3 + j3
69We will require that the weighting function be such that the weight of a pair in
creases as we move out along a row or down along a column of the array of pairs.
70To quote from G. H. Hardy’s obituary of Ramanujan (Hardy 1921): “It was Mr.
Lilewood (I believe) who remarked that ‘every positive integer was one of his friends.’
I remember once going to see him when he was lying ill at Putney. I had ridden in taxi
cab No. 1729, and remarked that the number seemed to me a rather dull one, and that I
hoped it was not an unfavorable omen. ‘No,’ he replied, ‘it is a very interesting number;
it is the smallest number expressible as the sum of two cubes in two diﬀerent ways.’ ”
e trick of using weighted pairs to generate the Ramanujan numbers was shown to
us by Charles Leiserson.
464
(see Exercise 3.70), then search the stream for two consecu
tive pairs with the same weight. Write a procedure to gener
ate the Ramanujan numbers. e ﬁrst such number is 1,729.
What are the next ﬁve?
Exercise 3.72: In a similar way to Exercise 3.71 generate a
stream of all numbers that can be wrien as the sum of two
squares in three diﬀerent ways (showing how they can be
so wrien).
Streams as signals
We began our discussion of streams by describing them as computa
tional analogs of the “signals” in signalprocessing systems. In fact, we
can use streams to model signalprocessing systems in a very direct
way, representing the values of a signal at successive time intervals as
consecutive elements of a stream. For instance, we can implement an
integrator or summer that, for an input stream x = (xi ), an initial value
C, and a small increment dt, accumulates the sum
i∑
Si = C +
xj dt
j =1
and returns the stream of values S = (Si ). e following integral pro
cedure is reminiscent of the “implicit style” deﬁnition of the stream of
integers (Section 3.5.2):
(define (integral integrand initialvalue dt)
(define int
(consstream initialvalue
(addstreams (scalestream integrand dt)
int)
int)))
465
Figure 3.32: e integral procedure viewed as a signal
processing system.
Figure 3.32 is a picture of a signalprocessing system that corresponds
to the integral procedure. e input stream is scaled by dt and passed
through an adder, whose output is passed back through the same adder.
e selfreference in the deﬁnition of int is reﬂected in the ﬁgure by
the feedback loop that connects the output of the adder to one of the
inputs.
Exercise 3.73: We can model electrical circuits using streams
to represent the values of currents or voltages at a sequence
of times. For instance, suppose we have an RC circuit con
sisting of a resistor of resistance R and a capacitor of capac
itance C in series. e voltage response v of the circuit to
an injected current i is determined by the formula in Fig
ure 3.33, whose structure is shown by the accompanying
signalﬂow diagram.
Write a procedure RC that models this circuit. RC should
take as inputs the values of R, C, and dt and should return
a procedure that takes as inputs a stream representing the
current i and an initial value for the capacitor voltage v0
466
addconsinitialvalueintegralinputscale: dtFigure 3.33: An RC circuit and the associated signalﬂow diagram.
and produces as output the stream of voltages v. For ex
ample, you should be able to use RC to model an RC circuit
with R = 5 ohms, C = 1 farad, and a 0.5second time step by
evaluating (define RC1 (RC 5 1 0.5)). is deﬁnes RC1
as a procedure that takes a stream representing the time
sequence of currents and an initial capacitor voltage and
produces the output stream of voltages.
Exercise 3.74: Alyssa P. Hacker is designing a system to
process signals coming from physical sensors. One impor
tant feature she wishes to produce is a signal that describes
the zero crossings of the input signal. at is, the resulting
signal should be +1 whenever the input signal changes from
negative to positive, (cid:0)1 whenever the input signal changes
from positive to negative, and 0 otherwise. (Assume that
the sign of a 0 input is positive.) For example, a typical in
467
vv0iRCi+vscale: Rintegraladdscale: 1Cv = v0 + 1 idt + Ri0tCZput signal with its associated zerocrossing signal would be
: : : 1 2 1.5 1 0.5 0.1 2 3 2 0.5 0.2 3 4 : : :
: : : 0 0
0 0 : : :
1
0
0
0
0
0
0
0
1
In Alyssa’s system, the signal from the sensor is represented
as a stream sensedata and the stream zerocrossings
is the corresponding stream of zero crossings. Alyssa ﬁrst
writes a procedure signchangedetector that takes two
values as arguments and compares the signs of the values
to produce an appropriate 0, 1, or  1. She then constructs
her zerocrossing stream as follows:
(define (makezerocrossings inputstream lastvalue)
(consstream
(signchangedetector
(streamcar inputstream)
lastvalue)
(makezerocrossings
(streamcdr inputstream)
(streamcar inputstream))))
(define zerocrossings
(makezerocrossings sensedata 0))
Alyssa’s boss, Eva Lu Ator, walks by and suggests that this
program is approximately equivalent to the following one,
which uses the generalized version of streammap from Ex
ercise 3.50:
(define zerocrossings
(streammap signchangedetector
sensedata
⟨expression⟩))
468
Complete the program by supplying the indicated⟨expression⟩.
Exercise 3.75: Unfortunately, Alyssa’s zerocrossing de
tector in Exercise 3.74 proves to be insuﬃcient, because the
noisy signal from the sensor leads to spurious zero cross
ings. Lem E. Tweakit, a hardware specialist, suggests that
Alyssa smooth the signal to ﬁlter out the noise before ex
tracting the zero crossings. Alyssa takes his advice and de
cides to extract the zero crossings from the signal constructed
by averaging each value of the sense data with the previous
value. She explains the problem to her assistant, Louis Rea
soner, who aempts to implement the idea, altering Alyssa’s
program as follows:
(define (makezerocrossings inputstream lastvalue)
(let ((avpt (/ (+ (streamcar inputstream)
lastvalue)
2)))
(consstream
(signchangedetector avpt lastvalue)
(makezerocrossings
(streamcdr inputstream) avpt))))
is does not correctly implement Alyssa’s plan. Find the
bug that Louis has installed and ﬁx it without changing the
structure of the program. (Hint: You will need to increase
the number of arguments to makezerocrossings.)
Exercise 3.76: Eva Lu Ator has a criticism of Louis’s ap
proach in Exercise 3.75. e program he wrote is not mod
ular, because it intermixes the operation of smoothing with
the zerocrossing extraction. For example, the extractor should
469
not have to be changed if Alyssa ﬁnds a beer way to con
dition her input signal. Help Louis by writing a procedure
smooth that takes a stream as input and produces a stream
in which each element is the average of two successive in
put stream elements. en use smooth as a component to
implement the zerocrossing detector in a more modular
style.
3.5.4 Streams and Delayed Evaluation
e integral procedure at the end of the preceding section shows how
we can use streams to model signalprocessing systems that contain
feedback loops. e feedback loop for the adder shown in Figure 3.32
is modeled by the fact that integral’s internal stream int is deﬁned in
terms of itself:
(define int
(consstream
initialvalue
(addstreams (scalestream integrand dt)
int)))
e interpreter’s ability to deal with such an implicit deﬁnition depends
on the delay that is incorporated into consstream. Without this delay,
the interpreter could not construct int before evaluating both argu
ments to consstream, which would require that int already be deﬁned.
In general, delay is crucial for using streams to model signalprocessing
systems that contain loops. Without delay, our models would have to
be formulated so that the inputs to any signalprocessing component
would be fully evaluated before the output could be produced. is
would outlaw loops.
470
Figure 3.34: An “analog computer circuit” that solves the
equation dy=dt = f (y).
Unfortunately, stream models of systems with loops may require
uses of delay beyond the “hidden” delay supplied by consstream. For
instance, Figure 3.34 shows a signalprocessing system for solving the
diﬀerential equation dy=dt = f (y) where f is a given function. e ﬁg
ure shows a mapping component, which applies f to its input signal,
linked in a feedback loop to an integrator in a manner very similar to
that of the analog computer circuits that are actually used to solve such
equations.
Assuming we are given an initial value y0 for y, we could try to
model this system using the procedure
(define (solve f y0 dt)
(define y (integral dy y0 dt))
(define dy (streammap f y))
y)
is procedure does not work, because in the ﬁrst line of solve the
call to integral requires that the input dy be deﬁned, which does not
happen until the second line of solve.
On the other hand, the intent of our deﬁnition does make sense,
because we can, in principle, begin to generate the y stream without
471
y0dyyintegralmap: fknowing dy. Indeed, integral and many other stream operations have
properties similar to those of consstream, in that we can generate
part of the answer given only partial information about the arguments.
For integral, the ﬁrst element of the output stream is the speciﬁed
initialvalue. us, we can generate the ﬁrst element of the output
stream without evaluating the integrand dy. Once we know the ﬁrst
element of y, the streammap in the second line of solve can begin
working to generate the ﬁrst element of dy, which will produce the
next element of y, and so on.
To take advantage of this idea, we will redeﬁne integral to expect
the integrand stream to be a delayed argument. integral will force the
integrand to be evaluated only when it is required to generate more than
the ﬁrst element of the output stream:
(define (integral delayedintegrand initialvalue dt)
(define int
(consstream
initialvalue
(let ((integrand (force delayedintegrand)))
(addstreams (scalestream integrand dt) int))))
int)
Now we can implement our solve procedure by delaying the evaluation
of dy in the deﬁnition of y:71
(define (solve f y0 dt)
(define y (integral (delay dy) y0 dt))
(define dy (streammap f y))
y)
71is procedure is not guaranteed to work in all Scheme implementations, although
for any implementation there is a simple variation that will work. e problem has to
do with subtle diﬀerences in the ways that Scheme implementations handle internal
deﬁnitions. (See Section 4.1.6.)
472
In general, every caller of integral must now delay the integrand ar
gument. We can demonstrate that the solve procedure works by ap
proximating e (cid:25) 2:718 by computing the value at y = 1 of the solution
to the diﬀerential equation dy=dt = y with initial condition y(0) = 1:
(streamref (solve (lambda (y) y)
1
0.001)
1000)
2.716924
Exercise 3.77: e integral procedure used above was
analogous to the “implicit” deﬁnition of the inﬁnite stream
of integers in Section 3.5.2. Alternatively, we can give a def
inition of integral that is more like integersstarting
from (also in Section 3.5.2):
(define (integral integrand initialvalue dt)
(consstream
initialvalue
(if (streamnull? integrand)
theemptystream
(integral (streamcdr integrand)
(+ (* dt (streamcar integrand))
initialvalue)
dt))))
When used in systems with loops, this procedure has the
same problem as does our original version of integral.
Modify the procedure so that it expects the integrand as
a delayed argument and hence can be used in the solve
procedure shown above.
473
Figure 3.35: Signalﬂow diagram for the solution to a
secondorder linear diﬀerential equation.
Exercise 3.78: Consider the problem of designing a signal
processing system to study the homogeneous secondorder
linear diﬀerential equation
(cid:0) a
(cid:0) by = 0:
d2y
dt2
dy
dt
e output stream, modeling y, is generated by a network
that contains a loop. is is because the value of d2y=dt2 de
pends upon the values of y and dy=dt and both of these are
determined by integrating d2y=dt2. e diagram we would
like to encode is shown in Figure 3.35. Write a procedure
solve2nd that takes as arguments the constants a, b, and
dt and the initial values y0 and dy0 for y and dy=dt and gen
474
ddyy0dyyscale: bintegralintegralscale: aadddy0Figure 3.36: A series RLC circuit.
erates the stream of successive values of y.
Exercise 3.79: Generalize the solve2nd procedure of Ex
ercise 3.78 so that it can be used to solve general second
order diﬀerential equations d2y=dt2 = f (dy=dt ; y).
Exercise 3.80: A series RLC circuit consists of a resistor, a
capacitor, and an inductor connected in series, as shown
in Figure 3.36. If R, L, and C are the resistance, inductance,
and capacitance, then the relations between voltage (v) and
current (i) for the three components are described by the
equations
vR = iR R;
vL = L
diL
dt
;
iC = C
dvC
dt
;
and the circuit connections dictate the relations
iR = iL = (cid:0)iC ;
vC = vL + vR :
Combining these equations shows that the state of the cir
cuit (summarized by vC , the voltage across the capacitor,
475
+vRRiRLvL+iLCiCvC+Figure 3.37: A signalﬂow diagram for the solution to a
series RLC circuit.
and iL, the current in the inductor) is described by the pair
of diﬀerential equations
dvC
dt
= (cid:0)iL
C
;
diL
dt
= 1
L
vC (cid:0) R
L
iL :
e signalﬂow diagram representing this system of diﬀer
ential equations is shown in Figure 3.37.
Write a procedure RLC that takes as arguments the param
eters R, L, and C of the circuit and the time increment dt.
476
diLvC0iLvCdvCiL0scale: 1/Lintegralscale:1/Cintegralscale:R/LaddIn a manner similar to that of the RC procedure of Exercise
3.73, RLC should produce a procedure that takes the initial
values of the state variables, vC0 and iL0, and produces a
pair (using cons) of the streams of states vC and iL. Using
RLC, generate the pair of streams that models the behavior
of a series RLC circuit with R = 1 ohm, C = 0.2 farad, L = 1
henry, dt = 0.1 second, and initial values iL0 = 0 amps and
vC0 = 10 volts.
Normalorder evaluation
e examples in this section illustrate how the explicit use of delay
and force provides great programming ﬂexibility, but the same exam
ples also show how this can make our programs more complex. Our new
integral procedure, for instance, gives us the power to model systems
with loops, but we must now remember that integral should be called
with a delayed integrand, and every procedure that uses integral must
be aware of this. In eﬀect, we have created two classes of procedures:
ordinary procedures and procedures that take delayed arguments. In
general, creating separate classes of procedures forces us to create sep
arate classes of higherorder procedures as well.72
72is is a small reﬂection, in Lisp, of the diﬃculties that conventional strongly typed
languages such as Pascal have in coping with higherorder procedures. In such lan
guages, the programmer must specify the data types of the arguments and the result
of each procedure: number, logical value, sequence, and so on. Consequently, we could
not express an abstraction such as “map a given procedure proc over all the elements in
a sequence” by a single higherorder procedure such as streammap. Rather, we would
need a diﬀerent mapping procedure for each diﬀerent combination of argument and
result data types that might be speciﬁed for a proc. Maintaining a practical notion of
“data type” in the presence of higherorder procedures raises many diﬃcult issues. One
way of dealing with this problem is illustrated by the language ML (Gordon et al. 1979),
477
One way to avoid the need for two diﬀerent classes of procedures is
to make all procedures take delayed arguments. We could adopt a model
of evaluation in which all arguments to procedures are automatically
delayed and arguments are forced only when they are actually needed
(for example, when they are required by a primitive operation). is
would transform our language to use normalorder evaluation, which
we ﬁrst described when we introduced the substitution model for evalu
ation in Section 1.1.5. Converting to normalorder evaluation provides a
uniform and elegant way to simplify the use of delayed evaluation, and
this would be a natural strategy to adopt if we were concerned only
with stream processing. In Section 4.2, aer we have studied the eval
uator, we will see how to transform our language in just this way. Un
fortunately, including delays in procedure calls wreaks havoc with our
ability to design programs that depend on the order of events, such as
programs that use assignment, mutate data, or perform input or output.
Even the single delay in consstream can cause great confusion, as
illustrated by Exercise 3.51 and Exercise 3.52. As far as anyone knows,
mutability and delayed evaluation do not mix well in programming lan
guages, and devising ways to deal with both of these at once is an active
area of research.
whose “polymorphic data types” include templates for higherorder transformations
between data types. Moreover, data types for most procedures in ML are never explic
itly declared by the programmer. Instead, ML includes a typeinferencing mechanism
that uses information in the environment to deduce the data types for newly deﬁned
procedures.
478
3.5.5 Modularity of Functional Programs
and Modularity of Objects
As we saw in Section 3.1.2, one of the major beneﬁts of introducing
assignment is that we can increase the modularity of our systems by
encapsulating, or “hiding,” parts of the state of a large system within
local variables. Stream models can provide an equivalent modularity
without the use of assignment. As an illustration, we can reimplement
the Monte Carlo estimation of π, which we examined in Section 3.1.2,
from a streamprocessing point of view.
e key modularity issue was that we wished to hide the internal
state of a randomnumber generator from programs that used random
numbers. We began with a procedure randupdate, whose successive
values furnished our supply of random numbers, and used this to pro
duce a randomnumber generator:
(define rand
(let ((x randominit))
(lambda ()
(set! x (randupdate x))
x)))
In the stream formulation there is no randomnumber generator per se,
just a stream of random numbers produced by successive calls to rand
update:
(define randomnumbers
(consstream
randominit
(streammap randupdate randomnumbers)))
We use this to construct the stream of outcomes of the Cesàro experi
ment performed on consecutive pairs in the randomnumbers stream:
479
(define cesarostream
(mapsuccessivepairs
(lambda (r1 r2) (= (gcd r1 r2) 1))
randomnumbers))
(define (mapsuccessivepairs f s)
(consstream
(f (streamcar s) (streamcar (streamcdr s)))
(mapsuccessivepairs f (streamcdr (streamcdr s)))))
e cesarostream is now fed to a montecarlo procedure, which pro
duces a stream of estimates of probabilities. e results are then con
verted into a stream of estimates of π. is version of the program
doesn’t need a parameter telling how many trials to perform. Beer esti
mates of π (from performing more experiments) are obtained by looking
farther into the pi stream:
(define (montecarlo experimentstream passed failed)
(define (next passed failed)
(consstream
(/ passed (+ passed failed))
(montecarlo
(streamcdr experimentstream) passed failed)))
(if (streamcar experimentstream)
(next (+ passed 1) failed)
(next passed (+ failed 1))))
(define pi
(streammap
(lambda (p) (sqrt (/ 6 p)))
(montecarlo cesarostream 0 0)))
ere is considerable modularity in this approach, because we still can
formulate a general montecarlo procedure that can deal with arbitrary
experiments. Yet there is no assignment or local state.
480
Exercise 3.81: Exercise 3.6 discussed generalizing the random
number generator to allow one to reset the randomnumber
sequence so as to produce repeatable sequences of “ran
dom” numbers. Produce a stream formulation of this same
generator that operates on an input stream of requests to
generate a new random number or to reset the sequence
to a speciﬁed value and that produces the desired stream of
random numbers. Don’t use assignment in your solution.
Exercise 3.82: Redo Exercise 3.5 on Monte Carlo integra
tion in terms of streams. e stream version of estimate
integral will not have an argument telling how many tri
als to perform. Instead, it will produce a stream of estimates
based on successively more trials.
A functionalprogramming view of time
Let us now return to the issues of objects and state that were raised at
the beginning of this chapter and examine them in a new light. We in
troduced assignment and mutable objects to provide a mechanism for
modular construction of programs that model systems with state. We
constructed computational objects with local state variables and used
assignment to modify these variables. We modeled the temporal behav
ior of the objects in the world by the temporal behavior of the corre
sponding computational objects.
Now we have seen that streams provide an alternative way to model
objects with local state. We can model a changing quantity, such as the
local state of some object, using a stream that represents the time his
tory of successive states. In essence, we represent time explicitly, using
streams, so that we decouple time in our simulated world from the se
481
quence of events that take place during evaluation. Indeed, because of
the presence of delay there may be lile relation between simulated
time in the model and the order of events during the evaluation.
In order to contrast these two approaches to modeling, let us recon
sider the implementation of a “withdrawal processor” that monitors the
balance in a bank account. In Section 3.1.3 we implemented a simpliﬁed
version of such a processor:
(define (makesimplifiedwithdraw balance)
(lambda (amount)
(set! balance ( balance amount))
balance))
Calls to makesimplifiedwithdraw produce computational objects,
each with a local state variable balance that is decremented by suc
cessive calls to the object. e object takes an amount as an argument
and returns the new balance. We can imagine the user of a bank ac
count typing a sequence of inputs to such an object and observing the
sequence of returned values shown on a display screen.
Alternatively, we can model a withdrawal processor as a procedure
that takes as input a balance and a stream of amounts to withdraw and
produces the stream of successive balances in the account:
(define (streamwithdraw balance amountstream)
(consstream
balance
(streamwithdraw ( balance (streamcar amountstream))
(streamcdr amountstream))))
streamwithdraw implements a welldeﬁned mathematical function whose
output is fully determined by its input. Suppose, however, that the in
put amountstream is the stream of successive values typed by the user
and that the resulting stream of balances is displayed. en, from the
482
perspective of the user who is typing values and watching results, the
stream process has the same behavior as the object created by make
simplifiedwithdraw. However, with the stream version, there is no
assignment, no local state variable, and consequently none of the theo
retical diﬃculties that we encountered in Section 3.1.3. Yet the system
has state!
is is really remarkable. Even though streamwithdraw implements
a welldeﬁned mathematical function whose behavior does not change,
the user’s perception here is one of interacting with a system that has a
changing state. One way to resolve this paradox is to realize that it is the
user’s temporal existence that imposes state on the system. If the user
could step back from the interaction and think in terms of streams of
balances rather than individual transactions, the system would appear
stateless.73
From the point of view of one part of a complex process, the other
parts appear to change with time. ey have hidden timevarying lo
cal state. If we wish to write programs that model this kind of natural
decomposition in our world (as we see it from our viewpoint as a part
of that world) with structures in our computer, we make computational
objects that are not functional—they must change with time. We model
state with local state variables, and we model the changes of state with
assignments to those variables. By doing this we make the time of ex
ecution of a computation model time in the world that we are part of,
and thus we get “objects” in our computer.
Modeling with objects is powerful and intuitive, largely because this
matches the perception of interacting with a world of which we are
73Similarly in physics, when we observe a moving particle, we say that the position
(state) of the particle is changing. However, from the perspective of the particle’s world
line in spacetime there is no change involved.
483
part. However, as we’ve seen repeatedly throughout this chapter, these
models raise thorny problems of constraining the order of events and
of synchronizing multiple processes. e possibility of avoiding these
problems has stimulated the development of functional programming
languages, which do not include any provision for assignment or mu
table data. In such a language, all procedures implement welldeﬁned
mathematical functions of their arguments, whose behavior does not
change. e functional approach is extremely aractive for dealing with
concurrent systems.74
On the other hand, if we look closely, we can see timerelated prob
lems creeping into functional models as well. One particularly trou
blesome area arises when we wish to design interactive systems, es
pecially ones that model interactions between independent entities. For
instance, consider once more the implementation a banking system that
permits joint bank accounts. In a conventional system using assignment
and objects, we would model the fact that Peter and Paul share an ac
count by having both Peter and Paul send their transaction requests
to the same bankaccount object, as we saw in Section 3.1.3. From the
stream point of view, where there are no “objects” per se, we have al
ready indicated that a bank account can be modeled as a process that
operates on a stream of transaction requests to produce a stream of
responses. Accordingly, we could model the fact that Peter and Paul
have a joint bank account by merging Peter’s stream of transaction re
quests with Paul’s stream of requests and feeding the result to the bank
account stream process, as shown in Figure 3.38.
74John Backus, the inventor of Fortran, gave high visibility to functional program
ming when he was awarded the Turing award in 1978. His acceptance speech
(Backus 1978) strongly advocated the functional approach. A good overview of func
tional programming is given in Henderson 1980 and in Darlington et al. 1982.
484
Figure 3.38: A joint bank account, modeled by merging
two streams of transaction requests.
e trouble with this formulation is in the notion of merge. It will
not do to merge the two streams by simply taking alternately one re
quest from Peter and one request from Paul. Suppose Paul accesses the
account only very rarely. We could hardly force Peter to wait for Paul to
access the account before he could issue a second transaction. However
such a merge is implemented, it must interleave the two transaction
streams in some way that is constrained by “real time” as perceived
by Peter and Paul, in the sense that, if Peter and Paul meet, they can
agree that certain transactions were processed before the meeting, and
other transactions were processed aer the meeting.75 is is precisely
the same constraint that we had to deal with in Section 3.4.1, where
we found the need to introduce explicit synchronization to ensure a
“correct” order of events in concurrent processing of objects with state.
us, in an aempt to support the functional style, the need to merge
inputs from diﬀerent agents reintroduces the same problems that the
functional style was meant to eliminate.
75Observe that, for any two streams, there is in general more than one acceptable or
der of interleaving. us, technically, “merge” is a relation rather than a function—the
answer is not a deterministic function of the inputs. We already mentioned (Footnote
39) that nondeterminism is essential when dealing with concurrency. e merge rela
tion illustrates the same essential nondeterminism, from the functional perspective. In
Section 4.3, we will look at nondeterminism from yet another point of view.
485
mergebankaccountPaul's requestsPeter's requestsWe began this chapter with the goal of building computational mod
els whose structure matches our perception of the real world we are
trying to model. We can model the world as a collection of separate,
timebound, interacting objects with state, or we can model the world
as a single, timeless, stateless unity. Each view has powerful advantages,
but neither view alone is completely satisfactory. A grand uniﬁcation
has yet to emerge.76
76e object model approximates the world by dividing it into separate pieces. e
functional model does not modularize along object boundaries. e object model is
useful when the unshared state of the “objects” is much larger than the state that they
share. An example of a place where the object viewpoint fails is quantum mechanics,
where thinking of things as individual particles leads to paradoxes and confusions. Uni
fying the object view with the functional view may have lile to do with programming,
but rather with fundamental epistemological issues.
486
Metalinguistic Abstraction
: : : It’s in words that the magic is—Abracadabra, Open Sesame,
and the rest—but the magic words in one story aren’t magi
cal in the next. e real magic is to understand which words
work, and when, and for what; the trick is to learn the trick.
: : : And those words are made from the leers of our alpha
bet: a coupledozen squiggles we can draw with the pen.
is is the key! And the treasure, too, if we can only get
our hands on it! It’s as if—as if the key to the treasure is the
treasure!
—John Barth, Chimera
I , we have seen that expert program
mers control the complexity of their designs with the same general
techniques used by designers of all complex systems. ey combine
primitive elements to form compound objects, they abstract compound
487
objects to form higherlevel building blocks, and they preserve modu
larity by adopting appropriate largescale views of system structure. In
illustrating these techniques, we have used Lisp as a language for de
scribing processes and for constructing computational data objects and
processes to model complex phenomena in the real world. However, as
we confront increasingly complex problems, we will ﬁnd that Lisp, or
indeed any ﬁxed programming language, is not suﬃcient for our needs.
We must constantly turn to new languages in order to express our ideas
more eﬀectively. Establishing new languages is a powerful strategy for
controlling complexity in engineering design; we can oen enhance our
ability to deal with a complex problem by adopting a new language that
enables us to describe (and hence to think about) the problem in a dif
ferent way, using primitives, means of combination, and means of ab
straction that are particularly well suited to the problem at hand.1
Programming is endowed with a multitude of languages. ere are
1e same idea is pervasive throughout all of engineering. For example, electri
cal engineers use many diﬀerent languages for describing circuits. Two of these are
the language of electrical networks and the language of electrical systems. e network
language emphasizes the physical modeling of devices in terms of discrete electrical el
ements. e primitive objects of the network language are primitive electrical compo
nents such as resistors, capacitors, inductors, and transistors, which are characterized
in terms of physical variables called voltage and current. When describing circuits in
the network language, the engineer is concerned with the physical characteristics of a
design. In contrast, the primitive objects of the system language are signalprocessing
modules such as ﬁlters and ampliﬁers. Only the functional behavior of the modules is
relevant, and signals are manipulated without concern for their physical realization as
voltages and currents. e system language is erected on the network language, in the
sense that the elements of signalprocessing systems are constructed from electrical
networks. Here, however, the concerns are with the largescale organization of elec
trical devices to solve a given application problem; the physical feasibility of the parts
is assumed. is layered collection of languages is another example of the stratiﬁed
design technique illustrated by the picture language of Section 2.2.4.
488
physical languages, such as the machine languages for particular com
puters. ese languages are concerned with the representation of data
and control in terms of individual bits of storage and primitive machine
instructions. e machinelanguage programmer is concerned with us
ing the given hardware to erect systems and utilities for the eﬃcient im
plementation of resourcelimited computations. Highlevel languages,
erected on a machinelanguage substrate, hide concerns about the rep
resentation of data as collections of bits and the representation of pro
grams as sequences of primitive instructions. ese languages have means
of combination and abstraction, such as procedure deﬁnition, that are
appropriate to the largerscale organization of systems.
Metalinguistic abstraction—establishing new languages—plays an im
portant role in all branches of engineering design. It is particularly im
portant to computer programming, because in programming not only
can we formulate new languages but we can also implement these lan
guages by constructing evaluators. An evaluator (or interpreter) for a
programming language is a procedure that, when applied to an expres
sion of the language, performs the actions required to evaluate that ex
pression.
It is no exaggeration to regard this as the most fundamental idea in
programming:
e evaluator, which determines the meaning of expres
sions in a programming language, is just another program.
To appreciate this point is to change our images of ourselves as pro
grammers. We come to see ourselves as designers of languages, rather
than only users of languages designed by others.
In fact, we can regard almost any program as the evaluator for some
language. For instance, the polynomial manipulation system of Section
489
2.5.3 embodies the rules of polynomial arithmetic and implements them
in terms of operations on liststructured data. If we augment this system
with procedures to read and print polynomial expressions, we have the
core of a specialpurpose language for dealing with problems in sym
bolic mathematics. e digitallogic simulator of Section 3.3.4 and the
constraint propagator of Section 3.3.5 are legitimate languages in their
own right, each with its own primitives, means of combination, and
means of abstraction. Seen from this perspective, the technology for
coping with largescale computer systems merges with the technology
for building new computer languages, and computer science itself be
comes no more (and no less) than the discipline of constructing appro
priate descriptive languages.
We now embark on a tour of the technology by which languages are
established in terms of other languages. In this chapter we shall use Lisp
as a base, implementing evaluators as Lisp procedures. Lisp is particu
larly well suited to this task, because of its ability to represent and ma
nipulate symbolic expressions. We will take the ﬁrst step in understand
ing how languages are implemented by building an evaluator for Lisp
itself. e language implemented by our evaluator will be a subset of the
Scheme dialect of Lisp that we use in this book. Although the evaluator
described in this chapter is wrien for a particular dialect of Lisp, it con
tains the essential structure of an evaluator for any expressionoriented
language designed for writing programs for a sequential machine. (In
fact, most language processors contain, deep within them, a lile “Lisp”
evaluator.) e evaluator has been simpliﬁed for the purposes of illus
tration and discussion, and some features have been le out that would
be important to include in a productionquality Lisp system. Neverthe
less, this simple evaluator is adequate to execute most of the programs
490
in this book.2
An important advantage of making the evaluator accessible as a
Lisp program is that we can implement alternative evaluation rules by
describing these as modiﬁcations to the evaluator program. One place
where we can use this power to good eﬀect is to gain extra control over
the ways in which computational models embody the notion of time,
which was so central to the discussion in Chapter 3. ere, we mitigated
some of the complexities of state and assignment by using streams to
decouple the representation of time in the world from time in the com
puter. Our stream programs, however, were sometimes cumbersome,
because they were constrained by the applicativeorder evaluation of
Scheme. In Section 4.2, we’ll change the underlying language to provide
for a more elegant approach, by modifying the evaluator to provide for
normalorder evaluation.
Section 4.3 implements a more ambitious linguistic change, whereby
expressions have many values, rather than just a single value. In this
language of nondeterministic computing, it is natural to express processes
that generate all possible values for expressions and then search for
those values that satisfy certain constraints. In terms of models of com
putation and time, this is like having time branch into a set of “possible
futures” and then searching for appropriate time lines. With our nonde
terministic evaluator, keeping track of multiple values and performing
searches are handled automatically by the underlying mechanism of the
language.
In Section 4.4 we implement a logicprogramming language in which
2e most important features that our evaluator leaves out are mechanisms for han
dling errors and supporting debugging. For a more extensive discussion of evaluators,
see Friedman et al. 1992, which gives an exposition of programming languages that
proceeds via a sequence of evaluators wrien in Scheme.
491
knowledge is expressed in terms of relations, rather than in terms of
computations with inputs and outputs. Even though this makes the lan
guage drastically diﬀerent from Lisp, or indeed from any conventional
language, we will see that the logicprogramming evaluator shares the
essential structure of the Lisp evaluator.
4.1 The Metacircular Evaluator
Our evaluator for Lisp will be implemented as a Lisp program. It may
seem circular to think about evaluating Lisp programs using an evalua
tor that is itself implemented in Lisp. However, evaluation is a process,
so it is appropriate to describe the evaluation process using Lisp, which,
aer all, is our tool for describing processes.3 An evaluator that is writ
ten in the same language that it evaluates is said to be metacircular.
e metacircular evaluator is essentially a Scheme formulation of
the environment model of evaluation described in Section 3.2. Recall
that the model has two basic parts:
1. To evaluate a combination (a compound expression other than
a special form), evaluate the subexpressions and then apply the
value of the operator subexpression to the values of the operand
subexpressions.
2. To apply a compound procedure to a set of arguments, evaluate
the body of the procedure in a new environment. To construct
3Even so, there will remain important aspects of the evaluation process that are not
elucidated by our evaluator. e most important of these are the detailed mechanisms
by which procedures call other procedures and return values to their callers. We will
address these issues in Chapter 5, where we take a closer look at the evaluation process
by implementing the evaluator as a simple register machine.
492
this environment, extend the environment part of the procedure
object by a frame in which the formal parameters of the procedure
are bound to the arguments to which the procedure is applied.
ese two rules describe the essence of the evaluation process, a basic
cycle in which expressions to be evaluated in environments are reduced
to procedures to be applied to arguments, which in turn are reduced to
new expressions to be evaluated in new environments, and so on, un
til we get down to symbols, whose values are looked up in the envi
ronment, and to primitive procedures, which are applied directly (see
Figure 4.1).4 is evaluation cycle will be embodied by the interplay
between the two critical procedures in the evaluator, eval and apply,
which are described in Section 4.1.1 (see Figure 4.1).
e implementation of the evaluator will depend upon procedures
4If we grant ourselves the ability to apply primitives, then what remains for us to
implement in the evaluator? e job of the evaluator is not to specify the primitives of
the language, but rather to provide the connective tissue—the means of combination
and the means of abstraction—that binds a collection of primitives to form a language.
Speciﬁcally:
(cid:15) e evaluator enables us to deal with nested expressions. For example, although
simply applying primitives would suﬃce for evaluating the expression (+ 1 6), it is not
adequate for handling (+ 1 (* 2 3)). As far as the primitive procedure + is concerned,
its arguments must be numbers, and it would choke if we passed it the expression (*
2 3) as an argument. One important role of the evaluator is to choreograph procedure
composition so that (* 2 3) is reduced to 6 before being passed as an argument to +.
(cid:15) e evaluator allows us to use variables. For example, the primitive procedure for
addition has no way to deal with expressions such as (+ x 1). We need an evaluator to
keep track of variables and obtain their values before invoking the primitive procedures.
(cid:15) e evaluator allows us to deﬁne compound procedures. is involves keeping
track of procedure deﬁnitions, knowing how to use these deﬁnitions in evaluating ex
pressions, and providing a mechanism that enables procedures to accept arguments.
(cid:15) e evaluator provides the special forms, which must be evaluated diﬀerently from
procedure calls.
493
Figure 4.1: e evalapply cycle exposes the essence of a
computer language.
that deﬁne the syntax of the expressions to be evaluated. We will use
data abstraction to make the evaluator independent of the representa
tion of the language. For example, rather than commiing to a choice
that an assignment is to be represented by a list beginning with the
symbol set! we use an abstract predicate assignment? to test for an
assignment, and we use abstract selectors assignmentvariable and
assignmentvalue to access the parts of an assignment. Implementa
tion of expressions will be described in detail in Section 4.1.2. ere are
also operations, described in Section 4.1.3, that specify the represen
tation of procedures and environments. For example, makeprocedure
constructs compound procedures, lookupvariablevalue accesses the
values of variables, and applyprimitiveprocedure applies a primi
tive procedure to a given list of arguments.
494
EvalApplyProcedure,ArgumentsExpression,Environment4.1.1 The Core of the Evaluator
e evaluation process can be described as the interplay between two
procedures: eval and apply.
Eval
eval takes as arguments an expression and an environment. It classi
ﬁes the expression and directs its evaluation. eval is structured as a case
analysis of the syntactic type of the expression to be evaluated. In or
der to keep the procedure general, we express the determination of the
type of an expression abstractly, making no commitment to any partic
ular representation for the various types of expressions. Each type of
expression has a predicate that tests for it and an abstract means for
selecting its parts. is abstract syntax makes it easy to see how we can
change the syntax of the language by using the same evaluator, but with
a diﬀerent collection of syntax procedures.
Primitive expressions
• For selfevaluating expressions, such as numbers, eval returns
the expression itself.
• eval must look up variables in the environment to ﬁnd their val
ues.
Special forms
• For quoted expressions, eval returns the expression that was quoted.
• An assignment to (or a deﬁnition o) a variable must recursively
call eval to compute the new value to be associated with the vari
able. e environment must be modiﬁed to change (or create) the
binding of the variable.
495
• An if expression requires special processing of its parts, so as to
evaluate the consequent if the predicate is true, and otherwise to
evaluate the alternative.
• A lambda expression must be transformed into an applicable pro
cedure by packaging together the parameters and body speciﬁed
by the lambda expression with the environment of the evaluation.
• A begin expression requires evaluating its sequence of expres
sions in the order in which they appear.
• A case analysis (cond) is transformed into a nest of if expressions
and then evaluated.
Combinations
• For a procedure application, eval must recursively evaluate the
operator part and the operands of the combination. e resulting
procedure and arguments are passed to apply, which handles the
actual procedure application.
Here is the deﬁnition of eval:
(define (eval exp env)
(cond ((selfevaluating? exp) exp)
((variable? exp) (lookupvariablevalue exp env))
((quoted? exp) (textofquotation exp))
((assignment? exp) (evalassignment exp env))
((definition? exp) (evaldefinition exp env))
((if? exp) (evalif exp env))
((lambda? exp) (makeprocedure (lambdaparameters exp)
(lambdabody exp)
env))
496
((begin? exp)
(evalsequence (beginactions exp) env))
((cond? exp) (eval (cond>if exp) env))
((application? exp)
(apply (eval (operator exp) env)
(listofvalues (operands exp) env)))
(else
(error "Unknown expression type: EVAL" exp))))
For clarity, eval has been implemented as a case analysis using cond.
e disadvantage of this is that our procedure handles only a few distin
guishable types of expressions, and no new ones can be deﬁned without
editing the deﬁnition of eval. In most Lisp implementations, dispatch
ing on the type of an expression is done in a datadirected style. is
allows a user to add new types of expressions that eval can distinguish,
without modifying the deﬁnition of eval itself. (See Exercise 4.3.)
Apply
apply takes two arguments, a procedure and a list of arguments to
which the procedure should be applied. apply classiﬁes procedures into
two kinds: It calls applyprimitiveprocedure to apply primitives; it
applies compound procedures by sequentially evaluating the expres
sions that make up the body of the procedure. e environment for
the evaluation of the body of a compound procedure is constructed by
extending the base environment carried by the procedure to include a
frame that binds the parameters of the procedure to the arguments to
which the procedure is to be applied. Here is the deﬁnition of apply:
(define (apply procedure arguments)
(cond ((primitiveprocedure? procedure)
(applyprimitiveprocedure procedure arguments))
497
((compoundprocedure? procedure)
(evalsequence
(procedurebody procedure)
(extendenvironment
(procedureparameters procedure)
arguments
(procedureenvironment procedure))))
(else
(error
"Unknown procedure type: APPLY" procedure))))
Procedure arguments
When eval processes a procedure application, it uses listofvalues
to produce the list of arguments to which the procedure is to be applied.
listofvalues takes as an argument the operands of the combina
tion. It evaluates each operand and returns a list of the corresponding
values:5
(define (listofvalues exps env)
(if (nooperands? exps)
'()
(cons (eval (firstoperand exps) env)
(listofvalues (restoperands exps) env))))
5We could have simpliﬁed the application? clause in eval by using map (and stip
ulating that operands returns a list) rather than writing an explicit listofvalues
procedure. We chose not to use map here to emphasize the fact that the evaluator can
be implemented without any use of higherorder procedures (and thus could be writ
ten in a language that doesn’t have higherorder procedures), even though the language
that it supports will include higherorder procedures.
498
Conditionals
evalif evaluates the predicate part of an if expression in the given
environment. If the result is true, evalif evaluates the consequent,
otherwise it evaluates the alternative:
(define (evalif exp env)
(if (true? (eval (ifpredicate exp) env))
(eval (ifconsequent exp) env)
(eval (ifalternative exp) env)))
e use of true? in evalif highlights the issue of the connection be
tween an implemented language and an implementation language. e
ifpredicate is evaluated in the language being implemented and thus
yields a value in that language. e interpreter predicate true? trans
lates that value into a value that can be tested by the if in the imple
mentation language: e metacircular representation of truth might not
be the same as that of the underlying Scheme.6
Sequences
evalsequence is used by apply to evaluate the sequence of expressions
in a procedure body and by eval to evaluate the sequence of expressions
in a begin expression. It takes as arguments a sequence of expressions
and an environment, and evaluates the expressions in the order in which
they occur. e value returned is the value of the ﬁnal expression.
(define (evalsequence exps env)
(cond ((lastexp? exps)
(eval (firstexp exps) env))
6In this case, the language being implemented and the implementation language are
the same. Contemplation of the meaning of true? here yields expansion of conscious
ness without the abuse of substance.
499
(else
(eval (firstexp exps) env)
(evalsequence (restexps exps) env))))
Assignments and definitions
e following procedure handles assignments to variables. It calls eval
to ﬁnd the value to be assigned and transmits the variable and the re
sulting value to setvariablevalue! to be installed in the designated
environment.
(define (evalassignment exp env)
(setvariablevalue! (assignmentvariable exp)
(eval (assignmentvalue exp) env)
env)
'ok)
Deﬁnitions of variables are handled in a similar manner.7
(define (evaldefinition exp env)
(definevariable! (definitionvariable exp)
(eval (definitionvalue exp) env)
env)
'ok)
We have chosen here to return the symbol ok as the value of an assign
ment or a deﬁnition.8
Exercise 4.1: Notice that we cannot tell whether the metacir
cular evaluator evaluates operands from le to right or from
7is implementation of define ignores a subtle issue in the handling of internal
deﬁnitions, although it works correctly in most cases. We will see what the problem is
and how to solve it in Section 4.1.6.
8As we said when we introduced define and set!, these values are implementation
dependent in Scheme—that is, the implementor can choose what value to return.
500
right to le. Its evaluation order is inherited from the un
derlying Lisp: If the arguments to cons in listofvalues
are evaluated from le to right, then listofvalues will
evaluate operands from le to right; and if the arguments to
cons are evaluated from right to le, then listofvalues
will evaluate operands from right to le.
Write a version of listofvalues that evaluates operands
from le to right regardless of the order of evaluation in the
underlying Lisp. Also write a version of listofvalues
that evaluates operands from right to le.
4.1.2 Representing Expressions
e evaluator is reminiscent of the symbolic diﬀerentiation program
discussed in Section 2.3.2. Both programs operate on symbolic expres
sions. In both programs, the result of operating on a compound expres
sion is determined by operating recursively on the pieces of the expres
sion and combining the results in a way that depends on the type of
the expression. In both programs we used data abstraction to decouple
the general rules of operation from the details of how expressions are
represented. In the diﬀerentiation program this meant that the same
diﬀerentiation procedure could deal with algebraic expressions in pre
ﬁx form, in inﬁx form, or in some other form. For the evaluator, this
means that the syntax of the language being evaluated is determined
solely by the procedures that classify and extract pieces of expressions.
Here is the speciﬁcation of the syntax of our language:
• e only selfevaluating items are numbers and strings:
(define (selfevaluating? exp)
(cond ((number? exp) true)
501
((string? exp) true)
(else false)))
• Variables are represented by symbols:
(define (variable? exp) (symbol? exp))
• otations have the form (quote ⟨textofquotation⟩):9
(define (quoted? exp) (taggedlist? exp 'quote))
(define (textofquotation exp) (cadr exp))
quoted? is deﬁned in terms of the procedure taggedlist?, which
identiﬁes lists beginning with a designated symbol:
(define (taggedlist? exp tag)
(if (pair? exp)
(eq? (car exp) tag)
false))
• Assignments have the form (set! ⟨var⟩ ⟨value⟩):
(define (assignment? exp) (taggedlist? exp 'set!))
(define (assignmentvariable exp) (cadr exp))
(define (assignmentvalue exp) (caddr exp))
• Deﬁnitions have the form
(define ⟨var⟩ ⟨value⟩)
or the form
9As mentioned in Section 2.3.1, the evaluator sees a quoted expression as a list begin
ning with quote, even if the expression is typed with the quotation mark. For example,
the expression 'a would be seen by the evaluator as (quote a). See Exercise 2.55.
502
(define (⟨var⟩ ⟨parameter1⟩ : : : ⟨parametern⟩)
⟨body⟩)
e laer form (standard procedure deﬁnition) is syntactic sugar
for
(define ⟨var⟩
(lambda (⟨parameter1⟩ : : : ⟨parametern⟩)
⟨body⟩))
e corresponding syntax procedures are the following:
(define (definition? exp) (taggedlist? exp 'define))
(define (definitionvariable exp)
(if (symbol? (cadr exp))
(cadr exp)
(caadr exp)))
(define (definitionvalue exp)
(if (symbol? (cadr exp))
(caddr exp)
(makelambda (cdadr exp)
(cddr exp))))
; formal parameters
; body
• lambda expressions are lists that begin with the symbol lambda:
(define (lambda? exp) (taggedlist? exp 'lambda))
(define (lambdaparameters exp) (cadr exp))
(define (lambdabody exp) (cddr exp))
We also provide a constructor for lambda expressions, which is
used by definitionvalue, above:
(define (makelambda parameters body)
(cons 'lambda (cons parameters body)))
503
• Conditionals begin with if and have a predicate, a consequent,
and an (optional) alternative. If the expression has no alternative
part, we provide false as the alternative.10
(define (if? exp) (taggedlist? exp 'if))
(define (ifpredicate exp) (cadr exp))
(define (ifconsequent exp) (caddr exp))
(define (ifalternative exp)
(if (not (null? (cdddr exp)))
(cadddr exp)
'false))
We also provide a constructor for if expressions, to be used by
cond>if to transform cond expressions into if expressions:
(define (makeif predicate consequent alternative)
(list 'if predicate consequent alternative))
• begin packages a sequence of expressions into a single expres
sion. We include syntax operations on begin expressions to ex
tract the actual sequence from the begin expression, as well as
selectors that return the ﬁrst expression and the rest of the ex
pressions in the sequence.11
(define (begin? exp) (taggedlist? exp 'begin))
(define (beginactions exp) (cdr exp))
10e value of an if expression when the predicate is false and there is no alternative
is unspeciﬁed in Scheme; we have chosen here to make it false. We will support the use
of the variables true and false in expressions to be evaluated by binding them in the
global environment. See Section 4.1.4.
11ese selectors for a list of expressions—and the corresponding ones for a list of
operands—are not intended as a data abstraction. ey are introduced as mnemonic
names for the basic list operations in order to make it easier to understand the explicit
control evaluator in Section 5.4.
504
(define (lastexp? seq) (null? (cdr seq)))
(define (firstexp seq) (car seq))
(define (restexps seq) (cdr seq))
We also include a constructor sequence>exp (for use by cond
>if) that transforms a sequence into a single expression, using
begin if necessary:
(define (sequence>exp seq)
(cond ((null? seq) seq)
((lastexp? seq) (firstexp seq))
(else (makebegin seq))))
(define (makebegin seq) (cons 'begin seq))
• A procedure application is any compound expression that is not
one of the above expression types. e car of the expression is
the operator, and the cdr is the list of operands:
(define (application? exp) (pair? exp))
(define (operator exp) (car exp))
(define (operands exp) (cdr exp))
(define (nooperands? ops) (null? ops))
(define (firstoperand ops) (car ops))
(define (restoperands ops) (cdr ops))
Derived expressions
Some special forms in our language can be deﬁned in terms of expres
sions involving other special forms, rather than being implemented di
rectly. One example is cond, which can be implemented as a nest of if
expressions. For example, we can reduce the problem of evaluating the
expression
505
(cond ((> x 0) x)
((= x 0) (display 'zero) 0)
(else ( x)))
to the problem of evaluating the following expression involving if and
begin expressions:
(if (> x 0)
x
(if (= x 0)
(begin (display 'zero) 0)
( x)))
Implementing the evaluation of cond in this way simpliﬁes the evalua
tor because it reduces the number of special forms for which the evalu
ation process must be explicitly speciﬁed.
We include syntax procedures that extract the parts of a cond ex
pression, and a procedure cond>if that transforms cond expressions
into if expressions. A case analysis begins with cond and has a list of
predicateaction clauses. A clause is an else clause if its predicate is the
symbol else.12
(define (cond? exp) (taggedlist? exp 'cond))
(define (condclauses exp) (cdr exp))
(define (condelseclause? clause)
(eq? (condpredicate clause) 'else))
(define (condpredicate clause) (car clause))
(define (condactions clause) (cdr clause))
(define (cond>if exp) (expandclauses (condclauses exp)))
(define (expandclauses clauses)
(if (null? clauses)
'false
; no else clause
12e value of a cond expression when all the predicates are false and there is no
else clause is unspeciﬁed in Scheme; we have chosen here to make it false.
506
(let ((first (car clauses))
(rest (cdr clauses)))
(if (condelseclause? first)
(if (null? rest)
(sequence>exp (condactions first))
(error "ELSE clause isn't last: COND>IF"
clauses))
(makeif (condpredicate first)
(sequence>exp (condactions first))
(expandclauses rest))))))
Expressions (such as cond) that we choose to implement as syntactic
transformations are called derived expressions. let expressions are also
derived expressions (see Exercise 4.6).13
Exercise 4.2: Louis Reasoner plans to reorder the cond clauses
in eval so that the clause for procedure applications ap
pears before the clause for assignments. He argues that this
will make the interpreter more eﬃcient: Since programs
usually contain more applications than assignments, def
initions, and so on, his modiﬁed eval will usually check
fewer clauses than the original eval before identifying the
type of an expression.
a. What is wrong with Louis’s plan? (Hint: What will
13Practical Lisp systems provide a mechanism that allows a user to add new de
rived expressions and specify their implementation as syntactic transformations with
out modifying the evaluator. Such a userdeﬁned transformation is called a macro. Al
though it is easy to add an elementary mechanism for deﬁning macros, the result
ing language has subtle nameconﬂict problems. ere has been much research on
mechanisms for macro deﬁnition that do not cause these diﬃculties. See, for example,
Kohlbecker 1986, Clinger and Rees 1991, and Hanson 1991.
507
Louis’s evaluator do with the expression (define x
3)?)
b. Louis is upset that his plan didn’t work. He is will
ing to go to any lengths to make his evaluator recog
nize procedure applications before it checks for most
other kinds of expressions. Help him by changing the
syntax of the evaluated language so that procedure
applications start with call. For example, instead of
(factorial 3) we will now have to write (call factorial
3) and instead of (+ 1 2) we will have to write (call
+ 1 2).
Exercise 4.3: Rewrite eval so that the dispatch is done
in datadirected style. Compare this with the datadirected
diﬀerentiation procedure of Exercise 2.73. (You may use the
car of a compound expression as the type of the expres
sion, as is appropriate for the syntax implemented in this
section.)
Exercise 4.4: Recall the deﬁnitions of the special forms and
and or from Chapter 1:
• and: e expressions are evaluated from le to right.
If any expression evaluates to false, false is returned;
any remaining expressions are not evaluated. If all the
expressions evaluate to true values, the value of the
last expression is returned. If there are no expressions
then true is returned.
• or: e expressions are evaluated from le to right.
If any expression evaluates to a true value, that value
508
is returned; any remaining expressions are not evalu
ated. If all expressions evaluate to false, or if there are
no expressions, then false is returned.
Install and and or as new special forms for the evaluator by
deﬁning appropriate syntax procedures and evaluation pro
cedures evaland and evalor. Alternatively, show how to
implement and and or as derived expressions.
Exercise 4.5: Scheme allows an additional syntax for cond
clauses, (⟨test⟩ => ⟨recipient⟩). If ⟨test⟩ evaluates to a
true value, then ⟨recipient⟩ is evaluated. Its value must be a
procedure of one argument; this procedure is then invoked
on the value of the ⟨test⟩, and the result is returned as the
value of the cond expression. For example
(cond ((assoc 'b '((a 1) (b 2))) => cadr)
(else false))
returns 2. Modify the handling of cond so that it supports
this extended syntax.
Exercise 4.6: let expressions are derived expressions, be
cause
(let ((⟨var1⟩ ⟨exp1⟩) : : : (⟨varn⟩ ⟨expn⟩))
⟨body⟩)
is equivalent to
((lambda (⟨var1⟩ : : : ⟨varn⟩)
⟨body⟩)
⟨exp1⟩
: : :⟨expn⟩)
509
Implement a syntactic transformation let>combination
that reduces evaluating let expressions to evaluating com
binations of the type shown above, and add the appropriate
clause to eval to handle let expressions.
Exercise 4.7: let* is similar to let, except that the bind
ings of the let* variables are performed sequentially from
le to right, and each binding is made in an environment in
which all of the preceding bindings are visible. For example
(let* ((x 3)
(y (+ x 2)) (z (+ x y 5)))
(* x z))
returns 39. Explain how a let* expression can be rewrien
as a set of nested let expressions, and write a procedure
let*>nestedlets that performs this transformation. If
we have already implemented let (Exercise 4.6) and we
want to extend the evaluator to handle let*, is it suﬃcient
to add a clause to eval whose action is
(eval (let*>nestedlets exp) env)
or must we explicitly expand let* in terms of nonderived
expressions?
Exercise 4.8: “Named let” is a variant of let that has the
form
(let ⟨var⟩ ⟨bindings⟩ ⟨body⟩)
e ⟨bindings⟩ and ⟨body⟩ are just as in ordinary let, ex
cept that⟨var⟩ is bound within⟨body⟩ to a procedure whose
body is ⟨body⟩ and whose parameters are the variables in
510
the ⟨bindings⟩. us, one can repeatedly execute the ⟨body⟩
by invoking the procedure named ⟨var⟩. For example, the
iterative Fibonacci procedure (Section 1.2.2) can be rewrit
ten using named let as follows:
(define (fib n)
(let fibiter ((a 1)
(b 0)
(count n))
(if (= count 0)
b
(fibiter (+ a b) a ( count 1)))))
Modify let>combination of Exercise 4.6 to also support
named let.
Exercise 4.9: Many languages support a variety of iteration
constructs, such as do, for, while, and until. In Scheme,
iterative processes can be expressed in terms of ordinary
procedure calls, so special iteration constructs provide no
essential gain in computational power. On the other hand,
such constructs are oen convenient. Design some itera
tion constructs, give examples of their use, and show how
to implement them as derived expressions.
Exercise 4.10: By using data abstraction, we were able to
write an eval procedure that is independent of the particu
lar syntax of the language to be evaluated. To illustrate this,
design and implement a new syntax for Scheme by modify
ing the procedures in this section, without changing eval
or apply.
511
4.1.3 Evaluator Data Structures
In addition to deﬁning the external syntax of expressions, the evaluator
implementation must also deﬁne the data structures that the evaluator
manipulates internally, as part of the execution of a program, such as the
representation of procedures and environments and the representation
of true and false.
Testing of predicates
For conditionals, we accept anything to be true that is not the explicit
false object.
(define (true? x) (not (eq? x false)))
(define (false? x) (eq? x false))
Representing procedures
To handle primitives, we assume that we have available the following
procedures:
• (applyprimitiveprocedure ⟨proc⟩ ⟨args⟩)
applies the given primitive procedure to the argument values in
the list ⟨args⟩ and returns the result of the application.
• (primitiveprocedure? ⟨proc⟩)
tests whether ⟨proc⟩ is a primitive procedure.
ese mechanisms for handling primitives are further described in Sec
tion 4.1.4.
Compound procedures are constructed from parameters, procedure
bodies, and environments using the constructor makeprocedure:
512
(define (makeprocedure parameters body env)
(list 'procedure parameters body env))
(define (compoundprocedure? p)
(taggedlist? p 'procedure))
(define (procedureparameters p) (cadr p))
(define (procedurebody p) (caddr p))
(define (procedureenvironment p) (cadddr p))
Operations on Environments
e evaluator needs operations for manipulating environments. As ex
plained in Section 3.2, an environment is a sequence of frames, where
each frame is a table of bindings that associate variables with their cor
responding values. We use the following operations for manipulating
environments:
• (lookupvariablevalue ⟨var⟩ ⟨env⟩)
returns the value that is bound to the symbol ⟨var⟩ in the envi
ronment ⟨env⟩, or signals an error if the variable is unbound.
• (extendenvironment ⟨variables⟩ ⟨values⟩ ⟨baseenv⟩)
returns a new environment, consisting of a new frame in which
the symbols in the list ⟨variables⟩ are bound to the corresponding
elements in the list ⟨values⟩, where the enclosing environment is
the environment ⟨baseenv⟩.
• (definevariable! ⟨var⟩ ⟨value⟩ ⟨env⟩)
adds to the ﬁrst frame in the environment ⟨env⟩ a new binding
that associates the variable ⟨var⟩ with the value ⟨value⟩.
513
• (setvariablevalue! ⟨var⟩ ⟨value⟩ ⟨env⟩)
changes the binding of the variable⟨var⟩ in the environment⟨env⟩
so that the variable is now bound to the value ⟨value⟩, or signals
an error if the variable is unbound.
To implement these operations we represent an environment as a list of
frames. e enclosing environment of an environment is the cdr of the
list. e empty environment is simply the empty list.
(define (enclosingenvironment env) (cdr env))
(define (firstframe env) (car env))
(define theemptyenvironment '())
Each frame of an environment is represented as a pair of lists: a list of
the variables bound in that frame and a list of the associated values.14
(define (makeframe variables values)
(cons variables values))
(define (framevariables frame) (car frame))
(define (framevalues frame) (cdr frame))
(define (addbindingtoframe! var val frame)
(setcar! frame (cons var (car frame)))
(setcdr! frame (cons val (cdr frame))))
To extend an environment by a new frame that associates variables with
values, we make a frame consisting of the list of variables and the list
of values, and we adjoin this to the environment. We signal an error if
the number of variables does not match the number of values.
14Frames are not really a data abstraction in the following code: setvariable
value! and definevariable! use setcar! to directly modify the values in a frame.
e purpose of the frame procedures is to make the environmentmanipulation proce
dures easy to read.
514
(define (extendenvironment vars vals baseenv)
(if (= (length vars) (length vals))
(cons (makeframe vars vals) baseenv)
(if (< (length vars) (length vals))
(error "Too many arguments supplied" vars vals)
(error "Too few arguments supplied" vars vals))))
To look up a variable in an environment, we scan the list of variables
in the ﬁrst frame. If we ﬁnd the desired variable, we return the corre
sponding element in the list of values. If we do not ﬁnd the variable
in the current frame, we search the enclosing environment, and so on.
If we reach the empty environment, we signal an “unbound variable”
error.
(define (lookupvariablevalue var env)
(define (envloop env)
(define (scan vars vals)
(cond ((null? vars)
(envloop (enclosingenvironment env)))
((eq? var (car vars)) (car vals))
(else (scan (cdr vars) (cdr vals)))))
(if (eq? env theemptyenvironment)
(error "Unbound variable" var)
(let ((frame (firstframe env)))
(scan (framevariables frame)
(framevalues frame)))))
(envloop env))
To set a variable to a new value in a speciﬁed environment, we scan for
the variable, just as in lookupvariablevalue, and change the corre
sponding value when we ﬁnd it.
(define (setvariablevalue! var val env)
(define (envloop env)
515
(define (scan vars vals)
(cond ((null? vars)
(envloop (enclosingenvironment env)))
((eq? var (car vars)) (setcar! vals val))
(else (scan (cdr vars) (cdr vals)))))
(if (eq? env theemptyenvironment)
(error "Unbound variable: SET!" var)
(let ((frame (firstframe env)))
(scan (framevariables frame)
(framevalues frame)))))
(envloop env))
To deﬁne a variable, we search the ﬁrst frame for a binding for the
variable, and change the binding if it exists (just as in setvariable
value!). If no such binding exists, we adjoin one to the ﬁrst frame.
(define (definevariable! var val env)
(let ((frame (firstframe env)))
(define (scan vars vals)
(cond ((null? vars)
(addbindingtoframe! var val frame))
((eq? var (car vars)) (setcar! vals val))
(else (scan (cdr vars) (cdr vals)))))
(scan (framevariables frame) (framevalues frame))))
e method described here is only one of many plausible ways to rep
resent environments. Since we used data abstraction to isolate the rest
of the evaluator from the detailed choice of representation, we could
change the environment representation if we wanted to. (See Exercise
4.11.) In a productionquality Lisp system, the speed of the evaluator’s
environment operations—especially that of variable lookup—has a ma
jor impact on the performance of the system. e representation de
scribed here, although conceptually simple, is not eﬃcient and would
516
not ordinarily be used in a production system.15
Exercise 4.11: Instead of representing a frame as a pair of
lists, we can represent a frame as a list of bindings, where
each binding is a namevalue pair. Rewrite the environment
operations to use this alternative representation.
Exercise 4.12: e procedures setvariablevalue!, define
variable! and lookupvariablevalue can be expressed
in terms of more abstract procedures for traversing the en
vironment structure. Deﬁne abstractions that capture the
common paerns and redeﬁne the three procedures in terms
of these abstractions.
Exercise 4.13: Scheme allows us to create new bindings for
variables by means of define, but provides no way to get
rid of bindings. Implement for the evaluator a special form
makeunbound! that removes the binding of a given symbol
from the environment in which the makeunbound! expres
sion is evaluated. is problem is not completely speciﬁed.
For example, should we remove only the binding in the ﬁrst
frame of the environment? Complete the speciﬁcation and
justify any choices you make.
15e drawback of this representation (as well as the variant in Exercise 4.11) is that
the evaluator may have to search through many frames in order to ﬁnd the binding for
a given variable. (Such an approach is referred to as deep binding.) One way to avoid this
ineﬃciency is to make use of a strategy called lexical addressing, which will be discussed
in Section 5.5.6.
517
4.1.4 Running the Evaluator as a Program
Given the evaluator, we have in our hands a description (expressed in
Lisp) of the process by which Lisp expressions are evaluated. One ad
vantage of expressing the evaluator as a program is that we can run the
program. is gives us, running within Lisp, a working model of how
Lisp itself evaluates expressions. is can serve as a framework for ex
perimenting with evaluation rules, as we shall do later in this chapter.
Our evaluator program reduces expressions ultimately to the appli
cation of primitive procedures. erefore, all that we need to run the
evaluator is to create a mechanism that calls on the underlying Lisp
system to model the application of primitive procedures.
ere must be a binding for each primitive procedure name, so that
when eval evaluates the operator of an application of a primitive, it will
ﬁnd an object to pass to apply. We thus set up a global environment that
associates unique objects with the names of the primitive procedures
that can appear in the expressions we will be evaluating. e global
environment also includes bindings for the symbols true and false, so
that they can be used as variables in expressions to be evaluated.
(define (setupenvironment)
(let ((initialenv
(extendenvironment (primitiveprocedurenames)
(primitiveprocedureobjects)
theemptyenvironment)))
(definevariable! 'true true initialenv)
(definevariable! 'false false initialenv)
initialenv))
(define theglobalenvironment (setupenvironment))
It does not maer how we represent the primitive procedure objects,
so long as apply can identify and apply them by using the procedures
518
primitiveprocedure? and applyprimitiveprocedure. We have cho
sen to represent a primitive procedure as a list beginning with the sym
bol primitive and containing a procedure in the underlying Lisp that
implements that primitive.
(define (primitiveprocedure? proc)
(taggedlist? proc 'primitive))
(define (primitiveimplementation proc) (cadr proc))
setupenvironment will get the primitive names and implementation
procedures from a list:16
(define primitiveprocedures
(list (list 'car car)
(list 'cdr cdr)
(list 'cons cons)
(list 'null? null?)
⟨more primitives⟩ ))
(define (primitiveprocedurenames)
(map car primitiveprocedures))
(define (primitiveprocedureobjects)
(map (lambda (proc) (list 'primitive (cadr proc)))
primitiveprocedures))
To apply a primitive procedure, we simply apply the implementation
procedure to the arguments, using the underlying Lisp system:17
16Any procedure deﬁned in the underlying Lisp can be used as a primitive for the
metacircular evaluator. e name of a primitive installed in the evaluator need not
be the same as the name of its implementation in the underlying Lisp; the names are
the same here because the metacircular evaluator implements Scheme itself. us, for
example, we could put (list 'first car) or (list 'square (lambda (x) (* x
x))) in the list of primitiveprocedures.
17applyinunderlyingscheme is the apply procedure we have used in earlier
chapters. e metacircular evaluator’s apply procedure (Section 4.1.1) models the
519
(define (applyprimitiveprocedure proc args)
(applyinunderlyingscheme
(primitiveimplementation proc) args))
For convenience in running the metacircular evaluator, we provide a
driver loop that models the readevalprint loop of the underlying Lisp
system. It prints a prompt, reads an input expression, evaluates this ex
pression in the global environment, and prints the result. We precede
each printed result by an output prompt so as to distinguish the value of
the expression from other output that may be printed.18
(define inputprompt ";;; MEval input:")
(define outputprompt ";;; MEval value:")
(define (driverloop)
(promptforinput inputprompt)
(let ((input (read)))
(let ((output (eval input theglobalenvironment)))
(announceoutput outputprompt)
(userprint output)))
(driverloop))
working of this primitive. Having two diﬀerent things called apply leads to a tech
nical problem in running the metacircular evaluator, because deﬁning the metacircular
evaluator’s apply will mask the deﬁnition of the primitive. One way around this is to
rename the metacircular apply to avoid conﬂict with the name of the primitive proce
dure. We have assumed instead that we have saved a reference to the underlying apply
by doing
(define applyinunderlyingscheme apply)
before deﬁning the metacircular apply. is allows us to access the original version of
apply under a diﬀerent name.
18e primitive procedure read waits for input from the user, and returns the next
complete expression that is typed. For example, if the user types (+ 23 x), read returns
a threeelement list containing the symbol +, the number 23, and the symbol x. If the
user types 'x, read returns a twoelement list containing the symbol quote and the
symbol x.
520
(define (promptforinput string)
(newline) (newline) (display string) (newline))
(define (announceoutput string)
(newline) (display string) (newline))
We use a special printing procedure, userprint, to avoid printing the
environment part of a compound procedure, which may be a very long
list (or may even contain cycles).
(define (userprint object)
(if (compoundprocedure? object)
(display (list 'compoundprocedure
(procedureparameters object)
(procedurebody object)
'))
(display object)))
Now all we need to do to run the evaluator is to initialize the global
environment and start the driver loop. Here is a sample interaction:
(define theglobalenvironment (setupenvironment))
(driverloop)
;;; MEval input:
(define (append x y)
(if (null? x)
y
(cons (car x) (append (cdr x) y))))
;;; MEval value:
ok
;;; MEval input:
(append '(a b c) '(d e f))
;;; MEval value:
(a b c d e f)
521
Exercise 4.14: Eva Lu Ator and Louis Reasoner are each
experimenting with the metacircular evaluator. Eva types
in the deﬁnition of map, and runs some test programs that
use it. ey work ﬁne. Louis, in contrast, has installed the
system version of map as a primitive for the metacircular
evaluator. When he tries it, things go terribly wrong. Ex
plain why Louis’s map fails even though Eva’s works.
4.1.5 Data as Programs
In thinking about a Lisp program that evaluates Lisp expressions, an
analogy might be helpful. One operational view of the meaning of a
program is that a program is a description of an abstract (perhaps in
ﬁnitely large) machine. For example, consider the familiar program to
compute factorials:
(define (factorial n)
(if (= n 1) 1 (* (factorial ( n 1)) n)))
We may regard this program as the description of a machine contain
ing parts that decrement, multiply, and test for equality, together with
a twoposition switch and another factorial machine. (e factorial ma
chine is inﬁnite because it contains another factorial machine within it.)
Figure 4.2 is a ﬂow diagram for the factorial machine, showing how the
parts are wired together.
In a similar way, we can regard the evaluator as a very special ma
chine that takes as input a description of a machine. Given this input,
the evaluator conﬁgures itself to emulate the machine described. For ex
ample, if we feed our evaluator the deﬁnition of factorial, as shown
in Figure 4.3, the evaluator will be able to compute factorials.
522
Figure 4.2: e factorial program, viewed as an abstract
machine.
From this perspective, our evaluator is seen to be a universal ma
chine. It mimics other machines when these are described as Lisp pro
grams.19 is is striking. Try to imagine an analogous evaluator for
19e fact that the machines are described in Lisp is inessential. If we give our eval
uator a Lisp program that behaves as an evaluator for some other language, say C,
the Lisp evaluator will emulate the C evaluator, which in turn can emulate any ma
chine described as a C program. Similarly, writing a Lisp evaluator in C produces a C
program that can execute any Lisp program. e deep idea here is that any evaluator
can emulate any other. us, the notion of “what can in principle be computed” (ig
noring practicalities of time and memory required) is independent of the language or
the computer, and instead reﬂects an underlying notion of computability. is was ﬁrst
demonstrated in a clear way by Alan M. Turing (19121954), whose 1936 paper laid the
foundations for theoretical computer science. In the paper, Turing presented a simple
computational model—now known as a Turing machine—and argued that any “eﬀective
process” can be formulated as a program for such a machine. (is argument is known
523
=factorial*factorial6720111Figure 4.3: e evaluator emulating a factorial machine.
electrical circuits. is would be a circuit that takes as input a signal
encoding the plans for some other circuit, such as a ﬁlter. Given this in
put, the circuit evaluator would then behave like a ﬁlter with the same
description. Such a universal electrical circuit is almost unimaginably
complex. It is remarkable that the program evaluator is a rather simple
program.20
as the ChurchTuring thesis.) Turing then implemented a universal machine, i.e., a Tur
ing machine that behaves as an evaluator for Turingmachine programs. He used this
framework to demonstrate that there are wellposed problems that cannot be computed
by Turing machines (see Exercise 4.15), and so by implication cannot be formulated as
“eﬀective processes.” Turing went on to make fundamental contributions to practical
computer science as well. For example, he invented the idea of structuring programs
using generalpurpose subroutines. See Hodges 1983 for a biography of Turing.
20Some people ﬁnd it counterintuitive that an evaluator, which is implemented by
a relatively simple procedure, can emulate programs that are more complex than the
evaluator itself. e existence of a universal evaluator machine is a deep and wonderful
property of computation. Recursion theory, a branch of mathematical logic, is concerned
with logical limits of computation. Douglas Hofstadter’s beautiful book Gödel, Escher,
Bach explores some of these ideas (Hofstadter 1979).
524
(define (factorial n) (if (= n 1) 1 (* (factorial ( n 1)) n)))eval6720Another striking aspect of the evaluator is that it acts as a bridge
between the data objects that are manipulated by our programming lan
guage and the programming language itself. Imagine that the evaluator
program (implemented in Lisp) is running, and that a user is typing ex
pressions to the evaluator and observing the results. From the perspec
tive of the user, an input expression such as (* x x) is an expression in
the programming language, which the evaluator should execute. From
the perspective of the evaluator, however, the expression is simply a list
(in this case, a list of three symbols: *, x, and x) that is to be manipulated
according to a welldeﬁned set of rules.
at the user’s programs are the evaluator’s data need not be a
source of confusion. In fact, it is sometimes convenient to ignore this
distinction, and to give the user the ability to explicitly evaluate a data
object as a Lisp expression, by making eval available for use in pro
grams. Many Lisp dialects provide a primitive eval procedure that takes
as arguments an expression and an environment and evaluates the ex
pression relative to the environment.21 us,
(eval '(* 5 5) userinitialenvironment)
and
(eval (cons '* (list 5 5)) userinitialenvironment)
will both return 25.22
21Warning: is eval primitive is not identical to the eval procedure we imple
mented in Section 4.1.1, because it uses actual Scheme environments rather than the
sample environment structures we built in Section 4.1.3. ese actual environments
cannot be manipulated by the user as ordinary lists; they must be accessed via eval or
other special operations. Similarly, the apply primitive we saw earlier is not identical
to the metacircular apply, because it uses actual Scheme procedures rather than the
procedure objects we constructed in Section 4.1.3 and Section 4.1.4.
22e implementation of Scheme includes eval, as well as a symbol user
initialenvironment that is bound to the initial environment in which the user’s in
525
Exercise 4.15: Given a oneargument procedure p and an
object a, p is said to “halt” on a if evaluating the expres
sion (p a) returns a value (as opposed to terminating with
an error message or running forever). Show that it is im
possible to write a procedure halts? that correctly deter
mines whether p halts on a for any procedure p and object
a. Use the following reasoning: If you had such a procedure
halts?, you could implement the following program:
(define (runforever) (runforever))
(define (try p)
(if (halts? p p) (runforever) 'halted))
Now consider evaluating the expression (try try) and
show that any possible outcome (either halting or running
forever) violates the intended behavior of halts?.23
4.1.6 Internal Definitions
Our environment model of evaluation and our metacircular evaluator
execute deﬁnitions in sequence, extending the environment frame one
deﬁnition at a time. is is particularly convenient for interactive pro
gram development, in which the programmer needs to freely mix the
application of procedures with the deﬁnition of new procedures. How
ever, if we think carefully about the internal deﬁnitions used to im
plement block structure (introduced in Section 1.1.8), we will ﬁnd that
put expressions are evaluated.
23Although we stipulated that halts? is given a procedure object, notice that this
reasoning still applies even if halts? can gain access to the procedure’s text and its
environment. is is Turing’s celebrated Halting eorem, which gave the ﬁrst clear
example of a noncomputable problem, i.e., a wellposed task that cannot be carried out
as a computational procedure.
526
namebyname extension of the environment may not be the best way
to deﬁne local variables.
Consider a procedure with internal deﬁnitions, such as
(define (f x)
(odd?
(define (even? n) (if (= n 0) true
( n 1))))
(define (odd? n) (if (= n 0) false (even? ( n 1))))
⟨rest of body of f⟩)
Our intention here is that the name odd? in the body of the procedure
even? should refer to the procedure odd? that is deﬁned aer even?.
e scope of the name odd? is the entire body of f, not just the portion
of the body of f starting at the point where the define for odd? occurs.
Indeed, when we consider that odd? is itself deﬁned in terms of even?—
so that even? and odd? are mutually recursive procedures—we see that
the only satisfactory interpretation of the two defines is to regard them
as if the names even? and odd? were being added to the environment
simultaneously. More generally, in block structure, the scope of a local
name is the entire procedure body in which the define is evaluated.
As it happens, our interpreter will evaluate calls to f correctly, but
for an “accidental” reason: Since the deﬁnitions of the internal proce
dures come ﬁrst, no calls to these procedures will be evaluated until
all of them have been deﬁned. Hence, odd? will have been deﬁned by
the time even? is executed. In fact, our sequential evaluation mecha
nism will give the same result as a mechanism that directly implements
simultaneous deﬁnition for any procedure in which the internal deﬁni
tions come ﬁrst in a body and evaluation of the value expressions for
the deﬁned variables doesn’t actually use any of the deﬁned variables.
(For an example of a procedure that doesn’t obey these restrictions, so
that sequential deﬁnition isn’t equivalent to simultaneous deﬁnition,
527
see Exercise 4.19.)24
ere is, however, a simple way to treat deﬁnitions so that inter
nally deﬁned names have truly simultaneous scope—just create all local
variables that will be in the current environment before evaluating any
of the value expressions. One way to do this is by a syntax transfor
mation on lambda expressions. Before evaluating the body of a lambda
expression, we “scan out” and eliminate all the internal deﬁnitions in
the body. e internally deﬁned variables will be created with a let
and then set to their values by assignment. For example, the procedure
(lambda ⟨vars⟩
(define u ⟨e1⟩)
(define v ⟨e2⟩)
⟨e3⟩)
would be transformed into
(lambda ⟨vars⟩
(let ((u '*unassigned*)
(v '*unassigned*))
(set! u ⟨e1⟩)
(set! v ⟨e2⟩)
⟨e3⟩))
24Wanting programs to not depend on this evaluation mechanism is the reason for
the “management is not responsible” remark in Footnote 28 of Chapter 1. By insisting
that internal deﬁnitions come ﬁrst and do not use each other while the deﬁnitions are
being evaluated, the standard for Scheme leaves implementors some choice in
the mechanism used to evaluate these deﬁnitions. e choice of one evaluation rule
rather than another here may seem like a small issue, aﬀecting only the interpretation
of “badly formed” programs. However, we will see in Section 5.5.6 that moving to a
model of simultaneous scoping for internal deﬁnitions avoids some nasty diﬃculties
that would otherwise arise in implementing a compiler.
528
where *unassigned* is a special symbol that causes looking up a vari
able to signal an error if an aempt is made to use the value of the
notyetassigned variable.
An alternative strategy for scanning out internal deﬁnitions is shown
in Exercise 4.18. Unlike the transformation shown above, this enforces
the restriction that the deﬁned variables’ values can be evaluated with
out using any of the variables’ values.25
Exercise 4.16: In this exercise we implement the method
just described for interpreting internal deﬁnitions. We as
sume that the evaluator supports let (see Exercise 4.6).
a. Change lookupvariablevalue (Section 4.1.3) to sig
nal an error if the value it ﬁnds is the symbol *unassigned*.
b. Write a procedure scanoutdefines that takes a pro
cedure body and returns an equivalent one that has
no internal deﬁnitions, by making the transformation
described above.
c. Install scanoutdefines in the interpreter, either in
makeprocedure or in procedurebody (see Section
4.1.3). Which place is beer? Why?
Exercise 4.17: Draw diagrams of the environment in eﬀect
when evaluating the expression⟨e3⟩ in the procedure in the
25e standard for Scheme allows for diﬀerent implementation strategies by
specifying that it is up to the programmer to obey this restriction, not up to the imple
mentation to enforce it. Some Scheme implementations, including Scheme, use the
transformation shown above. us, some programs that don’t obey this restriction will
in fact run in such implementations.
529
text, comparing how this will be structured when deﬁni
tions are interpreted sequentially with how it will be struc
tured if deﬁnitions are scanned out as described. Why is
there an extra frame in the transformed program? Explain
why this diﬀerence in environment structure can never make
a diﬀerence in the behavior of a correct program. Design a
way to make the interpreter implement the “simultaneous”
scope rule for internal deﬁnitions without constructing the
extra frame.
Exercise 4.18: Consider an alternative strategy for scan
ning out deﬁnitions that translates the example in the text
to
(lambda ⟨vars⟩
(let ((u '*unassigned*) (v '*unassigned*))
(let ((a ⟨e1⟩) (b ⟨e2⟩))
(set! u a)
(set! v b))
⟨e3⟩))
Here a and b are meant to represent new variable names,
created by the interpreter, that do not appear in the user’s
program. Consider the solve procedure from Section 3.5.4:
(define (solve f y0 dt)
y (integral (delay dy) y0 dt))
(define
(define dy (streammap f y))
y)
Will this procedure work if internal deﬁnitions are scanned
out as shown in this exercise? What if they are scanned out
as shown in the text? Explain.
530
Exercise 4.19: Ben Bitdiddle, Alyssa P. Hacker, and Eva Lu
Ator are arguing about the desired result of evaluating the
expression
(let ((a 1))
(define (f x)
(define b (+ a x))
(define a 5)
(+ a b))
(f 10))
Ben asserts that the result should be obtained using the se
quential rule for define: b is deﬁned to be 11, then a is de
ﬁned to be 5, so the result is 16. Alyssa objects that mutual
recursion requires the simultaneous scope rule for internal
procedure deﬁnitions, and that it is unreasonable to treat
procedure names diﬀerently from other names. us, she
argues for the mechanism implemented in Exercise 4.16.
is would lead to a being unassigned at the time that the
value for b is to be computed. Hence, in Alyssa’s view the
procedure should produce an error. Eva has a third opinion.
She says that if the deﬁnitions of a and b are truly meant
to be simultaneous, then the value 5 for a should be used in
evaluating b. Hence, in Eva’s view a should be 5, b should be
15, and the result should be 20. Which (if any) of these view
points do you support? Can you devise a way to implement
internal deﬁnitions so that they behave as Eva prefers?26
26e implementors of Scheme support Alyssa on the following grounds: Eva is
in principle correct—the deﬁnitions should be regarded as simultaneous. But it seems
diﬃcult to implement a general, eﬃcient mechanism that does what Eva requires. In
the absence of such a mechanism, it is beer to generate an error in the diﬃcult cases
of simultaneous deﬁnitions (Alyssa’s notion) than to produce an incorrect answer (as
Ben would have it).
531
Exercise 4.20: Because internal deﬁnitions look sequen
tial but are actually simultaneous, some people prefer to
avoid them entirely, and use the special form letrec in
stead. letrec looks like let, so it is not surprising that the
variables it binds are bound simultaneously and have the
same scope as each other. e sample procedure f above
can be wrien without internal deﬁnitions, but with ex
actly the same meaning, as
(define (f x)
(letrec
((even? (lambda (n)
(if (= n 0) true
(odd? ( n 1)))))
(lambda (n)
(odd?
⟨rest of body of f⟩))
(if (= n 0) false (even? ( n 1))))))
letrec expressions, which have the form
(letrec ((⟨var1⟩ ⟨exp1⟩) : : : (⟨varn⟩ ⟨expn⟩))
⟨body⟩)
are a variation on let in which the expressions ⟨expk⟩ that
provide the initial values for the variables ⟨vark⟩ are eval
uated in an environment that includes all the letrec bind
ings. is permits recursion in the bindings, such as the
mutual recursion of even? and odd? in the example above,
or the evaluation of 10 factorial with
(letrec
((fact (lambda (n)
(if (= n 1) 1 (* n (fact ( n 1)))))))
(fact 10))
532
a. Implement letrec as a derived expression, by trans
forming a letrec expression into a let expression as
shown in the text above or in Exercise 4.18. at is,
the letrec variables should be created with a let and
then be assigned their values with set!.
b. Louis Reasoner is confused by all this fuss about inter
nal deﬁnitions. e way he sees it, if you don’t like to
use define inside a procedure, you can just use let.
Illustrate what is loose about his reasoning by draw
ing an environment diagram that shows the environ
ment in which the ⟨rest of body of f⟩ is evaluated dur
ing evaluation of the expression (f 5), with f deﬁned
as in this exercise. Draw an environment diagram for
the same evaluation, but with let in place of letrec
in the deﬁnition of f.
Exercise 4.21: Amazingly, Louis’s intuition in Exercise 4.20
is correct. It is indeed possible to specify recursive proce
dures without using letrec (or even define), although the
method for accomplishing this is much more subtle than
Louis imagined. e following expression computes 10 fac
torial by applying a recursive factorial procedure:27
((lambda (n)
((lambda (fact) (fact fact n))
(lambda (ft k) (if (= k 1) 1 (* k (ft ft ( k 1)))))))
10)
27is example illustrates a programming trick for formulating recursive procedures
without using define. e most general trick of this sort is the Y operator, which can be
used to give a “pure λcalculus” implementation of recursion. (See Stoy 1977 for details
on the λcalculus, and Gabriel 1988 for an exposition of the Y operator in Scheme.)
533
a. Check (by evaluating the expression) that this really
does compute factorials. Devise an analogous expres
sion for computing Fibonacci numbers.
b. Consider the following procedure, which includes mu
tually recursive internal deﬁnitions:
(define (f x)
(define (even? n)
(if (= n 0) true
(define (odd? n)
(odd? ( n 1))))
(if (= n 0) false (even? ( n 1))))
(even? x))
Fill in the missing expressions to complete an alterna
tive deﬁnition of f, which uses neither internal deﬁ
nitions nor letrec:
(define (f x)
((lambda (even? odd?) (even? even? odd? x))
(lambda (ev? od? n)
(if (= n 0) true (od? ⟨??⟩ ⟨??⟩ ⟨??⟩)))
(lambda (ev? od? n)
(if (= n 0) false (ev? ⟨??⟩ ⟨??⟩ ⟨??⟩)))))
4.1.7 Separating Syntactic Analysis from Execution
e evaluator implemented above is simple, but it is very ineﬃcient,
because the syntactic analysis of expressions is interleaved with their
execution. us if a program is executed many times, its syntax is an
alyzed many times. Consider, for example, evaluating (factorial 4)
using the following deﬁnition of factorial:
(define (factorial n)
(if (= n 1) 1 (* (factorial ( n 1)) n)))
534
Each time factorial is called, the evaluator must determine that the
body is an if expression and extract the predicate. Only then can it
evaluate the predicate and dispatch on its value. Each time it evaluates
the expression (* (factorial ( n 1)) n), or the subexpressions
(factorial ( n 1)) and ( n 1), the evaluator must perform the
case analysis in eval to determine that the expression is an application,
and must extract its operator and operands. is analysis is expensive.
Performing it repeatedly is wasteful.
We can transform the evaluator to be signiﬁcantly more eﬃcient
by arranging things so that syntactic analysis is performed only once.28
We split eval, which takes an expression and an environment, into two
parts. e procedure analyze takes only the expression. It performs the
syntactic analysis and returns a new procedure, the execution procedure,
that encapsulates the work to be done in executing the analyzed expres
sion. e execution procedure takes an environment as its argument
and completes the evaluation. is saves work because analyze will be
called only once on an expression, while the execution procedure may
be called many times.
With the separation into analysis and execution, eval now becomes
(define (eval exp env) ((analyze exp) env))
e result of calling analyze is the execution procedure to be applied
to the environment. e analyze procedure is the same case analysis as
performed by the original eval of Section 4.1.1, except that the proce
dures to which we dispatch perform only analysis, not full evaluation:
(define (analyze exp)
28is technique is an integral part of the compilation process, which we shall discuss
in Chapter 5. Jonathan Rees wrote a Scheme interpreter like this in about 1982 for the T
project (Rees and Adams 1982). Marc Feeley (1986) (see also Feeley and Lapalme 1987)
independently invented this technique in his master’s thesis.
535
(cond ((selfevaluating? exp) (analyzeselfevaluating exp))
((quoted? exp) (analyzequoted exp))
((variable? exp) (analyzevariable exp))
((assignment? exp) (analyzeassignment exp))
((definition? exp) (analyzedefinition exp))
((if? exp) (analyzeif exp))
((lambda? exp) (analyzelambda exp))
((begin? exp) (analyzesequence (beginactions exp)))
((cond? exp) (analyze (cond>if exp)))
((application? exp) (analyzeapplication exp))
(else (error "Unknown expression type: ANALYZE" exp))))
Here is the simplest syntactic analysis procedure, which handles self
evaluating expressions. It returns an execution procedure that ignores
its environment argument and just returns the expression:
(define (analyzeselfevaluating exp)
(lambda (env) exp))
For a quoted expression, we can gain a lile eﬃciency by extracting the
text of the quotation only once, in the analysis phase, rather than in the
execution phase.
(define (analyzequoted exp)
(let ((qval (textofquotation exp)))
(lambda (env) qval)))
Looking up a variable value must still be done in the execution phase,
since this depends upon knowing the environment.29
(define (analyzevariable exp)
(lambda (env) (lookupvariablevalue exp env)))
29ere is, however, an important part of the variable search that can be done as
part of the syntactic analysis. As we will show in Section 5.5.6, one can determine the
position in the environment structure where the value of the variable will be found, thus
obviating the need to scan the environment for the entry that matches the variable.
536
analyzeassignment also must defer actually seing the variable un
til the execution, when the environment has been supplied. However,
the fact that the assignmentvalue expression can be analyzed (re
cursively) during analysis is a major gain in eﬃciency, because the
assignmentvalue expression will now be analyzed only once. e same
holds true for deﬁnitions.
(define (analyzeassignment exp)
(let ((var (assignmentvariable exp))
(vproc (analyze (assignmentvalue exp))))
(lambda (env)
(setvariablevalue! var (vproc env) env)
'ok)))
(define (analyzedefinition exp)
(let ((var (definitionvariable exp))
(vproc (analyze (definitionvalue exp))))
(lambda (env)
(definevariable! var (vproc env) env)
'ok)))
For if expressions, we extract and analyze the predicate, consequent,
and alternative at analysis time.
(define (analyzeif exp)
(let ((pproc (analyze (ifpredicate exp)))
(cproc (analyze (ifconsequent exp)))
(aproc (analyze (ifalternative exp))))
(lambda (env) (if (true? (pproc env))
(cproc env)
(aproc env)))))
Analyzing a lambda expression also achieves a major gain in eﬃciency:
We analyze the lambda body only once, even though procedures result
ing from evaluation of the lambda may be applied many times.
537
(define (analyzelambda exp)
(let ((vars (lambdaparameters exp))
(bproc (analyzesequence (lambdabody exp))))
(lambda (env) (makeprocedure vars bproc env))))
Analysis of a sequence of expressions (as in a begin or the body of a
lambda expression) is more involved.30 Each expression in the sequence
is analyzed, yielding an execution procedure. ese execution proce
dures are combined to produce an execution procedure that takes an
environment as argument and sequentially calls each individual execu
tion procedure with the environment as argument.
(define (analyzesequence exps)
(define (sequentially proc1 proc2)
(lambda (env) (proc1 env) (proc2 env)))
(define (loop firstproc restprocs)
(if (null? restprocs)
firstproc
(loop (sequentially firstproc (car restprocs))
(cdr restprocs))))
(let ((procs (map analyze exps)))
(if (null? procs) (error "Empty sequence: ANALYZE"))
(loop (car procs) (cdr procs))))
To analyze an application, we analyze the operator and operands and
construct an execution procedure that calls the operator execution pro
cedure (to obtain the actual procedure to be applied) and the operand
execution procedures (to obtain the actual arguments). We then pass
these to executeapplication, which is the analog of apply in Section
4.1.1. executeapplication diﬀers from apply in that the procedure
body for a compound procedure has already been analyzed, so there is
30See Exercise 4.23 for some insight into the processing of sequences.
538
no need to do further analysis. Instead, we just call the execution pro
cedure for the body on the extended environment.
(define (analyzeapplication exp)
(let ((fproc (analyze (operator exp)))
(aprocs (map analyze (operands exp))))
(lambda (env)
(executeapplication
(fproc env)
(map (lambda (aproc) (aproc env))
aprocs)))))
(define (executeapplication proc args)
(cond ((primitiveprocedure? proc)
(applyprimitiveprocedure proc args))
((compoundprocedure? proc)
((procedurebody proc)
(extendenvironment
(procedureparameters proc)
args
(procedureenvironment proc))))
(else
(error "Unknown procedure type: EXECUTEAPPLICATION"
proc))))
Our new evaluator uses the same data structures, syntax procedures,
and runtime support procedures as in sections Section 4.1.2, Section
4.1.3, and Section 4.1.4.
Exercise 4.22: Extend the evaluator in this section to sup
port the special form let. (See Exercise 4.6.)
Exercise 4.23: Alyssa P. Hacker doesn’t understand why
analyzesequence needs to be so complicated. All the other
analysis procedures are straightforward transformations of
539
the corresponding evaluation procedures (or eval clauses)
in Section 4.1.1. She expected analyzesequence to look
like this:
(define (analyzesequence exps)
(define (executesequence procs env)
(cond ((null? (cdr procs))
((car procs) env))
(else
((car procs) env)
(executesequence (cdr procs) env))))
(let ((procs (map analyze exps)))
(if (null? procs)
(error "Empty sequence: ANALYZE"))
(lambda (env)
(executesequence procs env))))
Eva Lu Ator explains to Alyssa that the version in the text
does more of the work of evaluating a sequence at analysis
time. Alyssa’s sequenceexecution procedure, rather than
having the calls to the individual execution procedures built
in, loops through the procedures in order to call them: In
eﬀect, although the individual expressions in the sequence
have been analyzed, the sequence itself has not been.
Compare the two versions of analyzesequence. For ex
ample, consider the common case (typical of procedure bod
ies) where the sequence has just one expression. What work
will the execution procedure produced by Alyssa’s program
do? What about the execution procedure produced by the
program in the text above? How do the two versions com
pare for a sequence with two expressions?
540
Exercise 4.24: Design and carry out some experiments to
compare the speed of the original metacircular evaluator
with the version in this section. Use your results to esti
mate the fraction of time that is spent in analysis versus
execution for various procedures.
4.2 Variations on a Scheme — Lazy Evaluation
Now that we have an evaluator expressed as a Lisp program, we can
experiment with alternative choices in language design simply by mod
ifying the evaluator. Indeed, new languages are oen invented by ﬁrst
writing an evaluator that embeds the new language within an exist
ing highlevel language. For example, if we wish to discuss some aspect
of a proposed modiﬁcation to Lisp with another member of the Lisp
community, we can supply an evaluator that embodies the change. e
recipient can then experiment with the new evaluator and send back
comments as further modiﬁcations. Not only does the highlevel imple
mentation base make it easier to test and debug the evaluator; in addi
tion, the embedding enables the designer to snarf 31 features from the
underlying language, just as our embedded Lisp evaluator uses primi
tives and control structure from the underlying Lisp. Only later (if ever)
need the designer go to the trouble of building a complete implemen
tation in a lowlevel language or in hardware. In this section and the
next we explore some variations on Scheme that provide signiﬁcant ad
ditional expressive power.
31Snarf: “To grab, especially a large document or ﬁle for the purpose of using it ei
ther with or without the owner’s permission.” Snarf down: “To snarf, sometimes with
the connotation of absorbing, processing, or understanding.” (ese deﬁnitions were
snarfed from Steele et al. 1983. See also Raymond 1993.)
541
4.2.1 Normal Order and Applicative Order
In Section 1.1, where we began our discussion of models of evaluation,
we noted that Scheme is an applicativeorder language, namely, that all
the arguments to Scheme procedures are evaluated when the procedure
is applied. In contrast, normalorder languages delay evaluation of pro
cedure arguments until the actual argument values are needed. Delay
ing evaluation of procedure arguments until the last possible moment
(e.g., until they are required by a primitive operation) is called lazy eval
uation.32 Consider the procedure
(define (try a b) (if (= a 0) 1 b))
Evaluating (try 0 (/ 1 0)) generates an error in Scheme. With lazy
evaluation, there would be no error. Evaluating the expression would
return 1, because the argument (/ 1 0) would never be evaluated.
An example that exploits lazy evaluation is the deﬁnition of a pro
cedure unless
(define (unless condition usualvalue exceptionalvalue)
(if condition exceptionalvalue usualvalue))
that can be used in expressions such as
(unless (= b 0)
(/ a b)
(begin (display "exception: returning 0") 0))
is won’t work in an applicativeorder language because both the usual
value and the exceptional value will be evaluated before unless is called
32e diﬀerence between the “lazy” terminology and the “normalorder” terminol
ogy is somewhat fuzzy. Generally, “lazy” refers to the mechanisms of particular eval
uators, while “normalorder” refers to the semantics of languages, independent of any
particular evaluation strategy. But this is not a hardandfast distinction, and the two
terminologies are oen used interchangeably.
542
(compare Exercise 1.6). An advantage of lazy evaluation is that some
procedures, such as unless, can do useful computation even if evalu
ation of some of their arguments would produce errors or would not
terminate.
If the body of a procedure is entered before an argument has been
evaluated we say that the procedure is nonstrict in that argument. If the
argument is evaluated before the body of the procedure is entered we
say that the procedure is strict in that argument.33 In a purely applicative
order language, all procedures are strict in each argument. In a purely
normalorder language, all compound procedures are nonstrict in each
argument, and primitive procedures may be either strict or nonstrict.
ere are also languages (see Exercise 4.31) that give programmers de
tailed control over the strictness of the procedures they deﬁne.
A striking example of a procedure that can usefully be made non
strict is cons (or, in general, almost any constructor for data structures).
One can do useful computation, combining elements to form data struc
tures and operating on the resulting data structures, even if the values
of the elements are not known. It makes perfect sense, for instance, to
compute the length of a list without knowing the values of the indi
vidual elements in the list. We will exploit this idea in Section 4.2.3 to
implement the streams of Chapter 3 as lists formed of nonstrict cons
pairs.
Exercise 4.25: Suppose that (in ordinary applicativeorder
Scheme) we deﬁne unless as shown above and then deﬁne
33e “strict” versus “nonstrict” terminology means essentially the same thing as
“applicativeorder” versus “normalorder,” except that it refers to individual procedures
and arguments rather than to the language as a whole. At a conference on programming
languages you might hear someone say, “e normalorder language Hassle has certain
strict primitives. Other procedures take their arguments by lazy evaluation.”
543
factorial in terms of unless as
(define (factorial n)
(unless (= n 1)
(* n (factorial ( n 1)))
1))
What happens if we aempt to evaluate (factorial 5)?
Will our deﬁnitions work in a normalorder language?
Exercise 4.26: Ben Bitdiddle and Alyssa P. Hacker disagree
over the importance of lazy evaluation for implementing
things such as unless. Ben points out that it’s possible to
implement unless in applicative order as a special form.
Alyssa counters that, if one did that, unless would be merely
syntax, not a procedure that could be used in conjunction
with higherorder procedures. Fill in the details on both
sides of the argument. Show how to implement unless as
a derived expression (like cond or let), and give an exam
ple of a situation where it might be useful to have unless
available as a procedure, rather than as a special form.
4.2.2 An Interpreter with Lazy Evaluation
In this section we will implement a normalorder language that is the
same as Scheme except that compound procedures are nonstrict in each
argument. Primitive procedures will still be strict. It is not diﬃcult to
modify the evaluator of Section 4.1.1 so that the language it interprets
behaves this way. Almost all the required changes center around pro
cedure application.
e basic idea is that, when applying a procedure, the interpreter
must determine which arguments are to be evaluated and which are to
544
be delayed. e delayed arguments are not evaluated; instead, they are
transformed into objects called thunks.34 e thunk must contain the
information required to produce the value of the argument when it is
needed, as if it had been evaluated at the time of the application. us,
the thunk must contain the argument expression and the environment
in which the procedure application is being evaluated.
e process of evaluating the expression in a thunk is called forc
ing.35 In general, a thunk will be forced only when its value is needed:
when it is passed to a primitive procedure that will use the value of the
thunk; when it is the value of a predicate of a conditional; and when it is
the value of an operator that is about to be applied as a procedure. One
design choice we have available is whether or not to memoize thunks, as
we did with delayed objects in Section 3.5.1. With memoization, the ﬁrst
time a thunk is forced, it stores the value that is computed. Subsequent
forcings simply return the stored value without repeating the computa
tion. We’ll make our interpreter memoize, because this is more eﬃcient
for many applications. ere are tricky considerations here, however.36
34e word thunk was invented by an informal working group that was discussing
the implementation of callbyname in Algol 60. ey observed that most of the analysis
of (“thinking about”) the expression could be done at compile time; thus, at run time,
the expression would already have been “thunk” about (Ingerman et al. 1960).
35is is analogous to the use of force on the delayed objects that were introduced
in Chapter 3 to represent streams. e critical diﬀerence between what we are doing
here and what we did in Chapter 3 is that we are building delaying and forcing into the
evaluator, and thus making this uniform and automatic throughout the language.
36Lazy evaluation combined with memoization is sometimes referred to as callby
need argument passing, in contrast to callbyname argument passing. (Callbyname,
introduced in Algol 60, is similar to nonmemoized lazy evaluation.) As language de
signers, we can build our evaluator to memoize, not to memoize, or leave this an option
for programmers (Exercise 4.31). As you might expect from Chapter 3, these choices
raise issues that become both subtle and confusing in the presence of assignments. (See
Exercise 4.27 and Exercise 4.29.) An excellent article by Clinger (1982) aempts to clar
545
Modifying the evaluator
e main diﬀerence between the lazy evaluator and the one in Section
4.1 is in the handling of procedure applications in eval and apply.
e application? clause of eval becomes
((application? exp)
(apply (actualvalue (operator exp) env)
(operands exp)
env))
is is almost the same as the application? clause of eval in Sec
tion 4.1.1. For lazy evaluation, however, we call apply with the operand
expressions, rather than the arguments produced by evaluating them.
Since we will need the environment to construct thunks if the argu
ments are to be delayed, we must pass this as well. We still evaluate
the operator, because apply needs the actual procedure to be applied in
order to dispatch on its type (primitive versus compound) and apply it.
Whenever we need the actual value of an expression, we use
(define (actualvalue exp env)
(forceit (eval exp env)))
instead of just eval, so that if the expression’s value is a thunk, it will
be forced.
Our new version of apply is also almost the same as the version
in Section 4.1.1. e diﬀerence is that eval has passed in unevaluated
operand expressions: For primitive procedures (which are strict), we
evaluate all the arguments before applying the primitive; for compound
procedures (which are nonstrict) we delay all the arguments before ap
plying the procedure.
ify the multiple dimensions of confusion that arise here.
546
(define (apply procedure arguments env)
(cond ((primitiveprocedure? procedure)
(applyprimitiveprocedure
procedure
(listofargvalues arguments env)))
; changed
((compoundprocedure? procedure)
(evalsequence
(procedurebody procedure)
(extendenvironment
(procedureparameters procedure)
(listofdelayedargs arguments env) ; changed
(procedureenvironment procedure))))
(else (error "Unknown procedure type: APPLY"
procedure))))
e procedures that process the arguments are just like listofvalues
from Section 4.1.1, except that listofdelayedargs delays the argu
ments instead of evaluating them, and listofargvalues uses actual
value instead of eval:
(define (listofargvalues exps env)
(if (nooperands? exps)
'()
(cons (actualvalue (firstoperand exps)
env)
(listofargvalues (restoperands exps)
env))))
(define (listofdelayedargs exps env)
(if (nooperands? exps)
'()
(cons (delayit (firstoperand exps)
env)
(listofdelayedargs (restoperands exps)
env))))
547
e other place we must change the evaluator is in the handling of if,
where we must use actualvalue instead of eval to get the value of
the predicate expression before testing whether it is true or false:
(define (evalif exp env)
(if (true? (actualvalue (ifpredicate exp) env))
(eval (ifconsequent exp) env)
(eval (ifalternative exp) env)))
Finally, we must change the driverloop procedure (Section 4.1.4) to
use actualvalue instead of eval, so that if a delayed value is prop
agated back to the readevalprint loop, it will be forced before being
printed. We also change the prompts to indicate that this is the lazy
evaluator:
(define inputprompt ";;; LEval input:")
(define outputprompt ";;; LEval value:")
(define (driverloop)
(promptforinput inputprompt)
(let ((input (read)))
(let ((output
(actualvalue
input theglobalenvironment)))
(announceoutput outputprompt)
(userprint output)))
(driverloop))
With these changes made, we can start the evaluator and test it. e
successful evaluation of the try expression discussed in Section 4.2.1
indicates that the interpreter is performing lazy evaluation:
(define theglobalenvironment (setupenvironment))
(driverloop)
;;; LEval input:
(define (try a b) (if (= a 0) 1 b))
548
;;; LEval value:
ok
;;; LEval input:
(try 0 (/ 1 0))
;;; LEval value:
1
Representing thunks
Our evaluator must arrange to create thunks when procedures are ap
plied to arguments and to force these thunks later. A thunk must pack
age an expression together with the environment, so that the argument
can be produced later. To force the thunk, we simply extract the ex
pression and environment from the thunk and evaluate the expression
in the environment. We use actualvalue rather than eval so that in
case the value of the expression is itself a thunk, we will force that, and
so on, until we reach something that is not a thunk:
(define (forceit obj)
(if (thunk? obj)
(actualvalue (thunkexp obj) (thunkenv obj))
obj))
One easy way to package an expression with an environment is to make
a list containing the expression and the environment. us, we create a
thunk as follows:
(define (delayit exp env)
(list 'thunk exp env))
(define (thunk? obj)
(taggedlist? obj 'thunk))
(define (thunkexp thunk) (cadr thunk))
(define (thunkenv thunk) (caddr thunk))
549
Actually, what we want for our interpreter is not quite this, but rather
thunks that have been memoized. When a thunk is forced, we will turn
it into an evaluated thunk by replacing the stored expression with its
value and changing the thunk tag so that it can be recognized as already
evaluated.37
(define (evaluatedthunk? obj)
(taggedlist? obj 'evaluatedthunk))
(define (thunkvalue evaluatedthunk)
(cadr evaluatedthunk))
(define (forceit obj)
(cond ((thunk? obj)
(let ((result (actualvalue (thunkexp obj)
(thunkenv obj))))
(setcar! obj 'evaluatedthunk)
(setcar! (cdr obj)
result)
; replace exp with its value
(setcdr! (cdr obj)
'())
; forget unneeded env
result))
((evaluatedthunk? obj) (thunkvalue obj))
(else obj)))
Notice that the same delayit procedure works both with and without
memoization.
37Notice that we also erase the env from the thunk once the expression’s value has
been computed. is makes no diﬀerence in the values returned by the interpreter. It
does help save space, however, because removing the reference from the thunk to the
env once it is no longer needed allows this structure to be garbagecollected and its space
recycled, as we will discuss in Section 5.3.
Similarly, we could have allowed unneeded environments in the memoized delayed
objects of Section 3.5.1 to be garbagecollected, by having memoproc do something like
(set! proc '()) to discard the procedure proc (which includes the environment in
which the delay was evaluated) aer storing its value.
550
Exercise 4.27: Suppose we type in the following deﬁnitions
to the lazy evaluator:
(define count 0)
(define (id x) (set! count (+ count 1)) x)
Give the missing values in the following sequence of inter
actions, and explain your answers.38
(define w (id (id 10)))
;;; LEval input:
count
;;; LEval value:
⟨response⟩
;;; LEval input:
w
;;; LEval value:
⟨response⟩
;;; LEval input:
count
;;; LEval value:
⟨response⟩
Exercise 4.28: eval uses actualvalue rather than eval
to evaluate the operator before passing it to apply, in or
der to force the value of the operator. Give an example that
demonstrates the need for this forcing.
Exercise 4.29: Exhibit a program that you would expect
to run much more slowly without memoization than with
38is exercise demonstrates that the interaction between lazy evaluation and side
eﬀects can be very confusing. is is just what you might expect from the discussion
in Chapter 3.
551
memoization. Also, consider the following interaction, where
the id procedure is deﬁned as in Exercise 4.27 and count
starts at 0:
(define (square x) (* x x))
;;; LEval input:
(square (id 10))
;;; LEval value:
⟨response⟩
;;; LEval input:
count
;;; LEval value:
⟨response⟩
Give the responses both when the evaluator memoizes and
when it does not.
Exercise 4.30: Cy D. Fect, a reformed C programmer, is
worried that some side eﬀects may never take place, be
cause the lazy evaluator doesn’t force the expressions in a
sequence. Since the value of an expression in a sequence
other than the last one is not used (the expression is there
only for its eﬀect, such as assigning to a variable or print
ing), there can be no subsequent use of this value (e.g., as an
argument to a primitive procedure) that will cause it to be
forced. Cy thus thinks that when evaluating sequences, we
must force all expressions in the sequence except the ﬁnal
one. He proposes to modify evalsequence from Section
4.1.1 to use actualvalue rather than eval:
(define (evalsequence exps env)
(cond ((lastexp? exps) (eval (firstexp exps) env))
(else (actualvalue (firstexp exps) env)
552
(evalsequence (restexps exps) env))))
a. Ben Bitdiddle thinks Cy is wrong. He shows Cy the
foreach procedure described in Exercise 2.23, which
gives an important example of a sequence with side
eﬀects:
(define (foreach proc items)
(if (null? items)
'done
(begin (proc (car items))
(foreach proc (cdr items)))))
He claims that the evaluator in the text (with the orig
inal evalsequence) handles this correctly:
;;; LEval input:
(foreach (lambda (x) (newline) (display x))
(list 57 321 88))
57
321
88
;;; LEval value:
done
Explain why Ben is right about the behavior of for
each.
b. Cy agrees that Ben is right about the foreach exam
ple, but says that that’s not the kind of program he
was thinking about when he proposed his change to
evalsequence. He deﬁnes the following two proce
dures in the lazy evaluator:
553
(define (p1 x)
(set! x (cons x '(2)))
x)
(define (p2 x)
(define (p e)
e
x)
(p (set! x (cons x '(2)))))
What are the values of (p1 1) and (p2 1) with the
original evalsequence? What would the values be
with Cy’s proposed change to evalsequence?
c. Cy also points out that changing evalsequence as he
proposes does not aﬀect the behavior of the example
in part a. Explain why this is true.
d. How do you think sequences ought to be treated in
the lazy evaluator? Do you like Cy’s approach, the ap
proach in the text, or some other approach?
Exercise 4.31: e approach taken in this section is some
what unpleasant, because it makes an incompatible change
to Scheme. It might be nicer to implement lazy evaluation
as an upwardcompatible extension, that is, so that ordinary
Scheme programs will work as before. We can do this by
extending the syntax of procedure declarations to let the
user control whether or not arguments are to be delayed.
While we’re at it, we may as well also give the user the
choice between delaying with and without memoization.
For example, the deﬁnition
(define (f a (b lazy) c (d lazymemo))
: : :)
554
would deﬁne f to be a procedure of four arguments, where
the ﬁrst and third arguments are evaluated when the pro
cedure is called, the second argument is delayed, and the
fourth argument is both delayed and memoized. us, or
dinary procedure deﬁnitions will produce the same behav
ior as ordinary Scheme, while adding the lazymemo dec
laration to each parameter of every compound procedure
will produce the behavior of the lazy evaluator deﬁned in
this section. Design and implement the changes required
to produce such an extension to Scheme. You will have to
implement new syntax procedures to handle the new syn
tax for define. You must also arrange for eval or apply to
determine when arguments are to be delayed, and to force
or delay arguments accordingly, and you must arrange for
forcing to memoize or not, as appropriate.
4.2.3 Streams as Lazy Lists
In Section 3.5.1, we showed how to implement streams as delayed lists.
We introduced special forms delay and consstream, which allowed
us to construct a “promise” to compute the cdr of a stream, without
actually fulﬁlling that promise until later. We could use this general
technique of introducing special forms whenever we need more control
over the evaluation process, but this is awkward. For one thing, a spe
cial form is not a ﬁrstclass object like a procedure, so we cannot use it
together with higherorder procedures.39 Additionally, we were forced
to create streams as a new kind of data object similar but not identical to
lists, and this required us to reimplement many ordinary list operations
39is is precisely the issue with the unless procedure, as in Exercise 4.26.
555
(map, append, and so on) for use with streams.
With lazy evaluation, streams and lists can be identical, so there is
no need for special forms or for separate list and stream operations. All
we need to do is to arrange maers so that cons is nonstrict. One way
to accomplish this is to extend the lazy evaluator to allow for nonstrict
primitives, and to implement cons as one of these. An easier way is to re
call (Section 2.1.3) that there is no fundamental need to implement cons
as a primitive at all. Instead, we can represent pairs as procedures:40
(define (cons x y) (lambda (m) (m x y)))
(define (car z) (z (lambda (p q) p)))
(define (cdr z) (z (lambda (p q) q)))
In terms of these basic operations, the standard deﬁnitions of the list
operations will work with inﬁnite lists (streams) as well as ﬁnite ones,
and the stream operations can be implemented as list operations. Here
are some examples:
(define (listref items n)
(if (= n 0)
(car items)
(listref (cdr items) ( n 1))))
(define (map proc items)
(if (null? items)
'()
(cons (proc (car items)) (map proc (cdr items)))))
(define (scalelist items factor)
(map (lambda (x) (* x factor)) items))
40is is the procedural representation described in Exercise 2.4. Essentially any pro
cedural representation (e.g., a messagepassing implementation) would do as well. No
tice that we can install these deﬁnitions in the lazy evaluator simply by typing them
at the driver loop. If we had originally included cons, car, and cdr as primitives in the
global environment, they will be redeﬁned. (Also see Exercise 4.33 and Exercise 4.34.)
556
(define (addlists list1 list2)
(cond ((null? list1) list2)
((null? list2) list1)
(else (cons (+ (car list1) (car list2))
(addlists (cdr list1) (cdr list2))))))
(define ones (cons 1 ones))
(define integers (cons 1 (addlists ones integers)))
;;; LEval input:
(listref integers 17)
;;; LEval value:
18
Note that these lazy lists are even lazier than the streams of Chapter 3:
e car of the list, as well as the cdr, is delayed.41 In fact, even accessing
the car or cdr of a lazy pair need not force the value of a list element.
e value will be forced only when it is really needed—e.g., for use as
the argument of a primitive, or to be printed as an answer.
Lazy pairs also help with the problem that arose with streams in Sec
tion 3.5.4, where we found that formulating stream models of systems
with loops may require us to sprinkle our programs with explicit delay
operations, beyond the ones supplied by consstream. With lazy evalu
ation, all arguments to procedures are delayed uniformly. For instance,
we can implement procedures to integrate lists and solve diﬀerential
equations as we originally intended in Section 3.5.4:
(define (integral integrand initialvalue dt)
(define int
(cons initialvalue
(addlists (scalelist integrand dt) int)))
int)
41is permits us to create delayed versions of more general kinds of list structures,
not just sequences. Hughes 1990 discusses some applications of “lazy trees.”
557
(define (solve f y0 dt)
y (integral dy y0 dt))
(define
(define dy (map f y))
y)
;;; LEval input:
(listref (solve (lambda (x) x) 1 0.001) 1000)
;;; LEval value:
2.716924
Exercise 4.32: Give some examples that illustrate the dif
ference between the streams of Chapter 3 and the “lazier”
lazy lists described in this section. How can you take ad
vantage of this extra laziness?
Exercise 4.33: Ben Bitdiddle tests the lazy list implemen
tation given above by evaluating the expression:
(car '(a b c))
To his surprise, this produces an error. Aer some thought,
he realizes that the “lists” obtained by reading in quoted
expressions are diﬀerent from the lists manipulated by the
new deﬁnitions of cons, car, and cdr. Modify the evalua
tor’s treatment of quoted expressions so that quoted lists
typed at the driver loop will produce true lazy lists.
Exercise 4.34: Modify the driver loop for the evaluator so
that lazy pairs and lists will print in some reasonable way.
(What are you going to do about inﬁnite lists?) You may
also need to modify the representation of lazy pairs so that
the evaluator can identify them in order to print them.
558
4.3 Variations on a Scheme — Nondeterministic
Computing
In this section, we extend the Scheme evaluator to support a program
ming paradigm called nondeterministic computing by building into the
evaluator a facility to support automatic search. is is a much more
profound change to the language than the introduction of lazy evalua
tion in Section 4.2.
Nondeterministic computing, like stream processing, is useful for
“generate and test” applications. Consider the task of starting with two
lists of positive integers and ﬁnding a pair of integers—one from the ﬁrst
list and one from the second list—whose sum is prime. We saw how to
handle this with ﬁnite sequence operations in Section 2.2.3 and with
inﬁnite streams in Section 3.5.3. Our approach was to generate the se
quence of all possible pairs and ﬁlter these to select the pairs whose sum
is prime. Whether we actually generate the entire sequence of pairs ﬁrst
as in Chapter 2, or interleave the generating and ﬁltering as in Chap
ter 3, is immaterial to the essential image of how the computation is
organized.
e nondeterministic approach evokes a diﬀerent image. Imagine
simply that we choose (in some way) a number from the ﬁrst list and a
number from the second list and require (using some mechanism) that
their sum be prime. is is expressed by following procedure:
(define (primesumpair list1 list2)
(let ((a (anelementof list1))
(b (anelementof list2)))
(require (prime? (+ a b)))
(list a b)))
It might seem as if this procedure merely restates the problem, rather
than specifying a way to solve it. Nevertheless, this is a legitimate non
559
deterministic program.42
e key idea here is that expressions in a nondeterministic language
can have more than one possible value. For instance, anelementof
might return any element of the given list. Our nondeterministic pro
gram evaluator will work by automatically choosing a possible value
and keeping track of the choice. If a subsequent requirement is not met,
the evaluator will try a diﬀerent choice, and it will keep trying new
choices until the evaluation succeeds, or until we run out of choices.
Just as the lazy evaluator freed the programmer from the details of how
values are delayed and forced, the nondeterministic program evaluator
will free the programmer from the details of how choices are made.
It is instructive to contrast the diﬀerent images of time evoked by
nondeterministic evaluation and stream processing. Stream processing
uses lazy evaluation to decouple the time when the stream of possible
answers is assembled from the time when the actual stream elements are
produced. e evaluator supports the illusion that all the possible an
swers are laid out before us in a timeless sequence. With nondetermin
istic evaluation, an expression represents the exploration of a set of pos
sible worlds, each determined by a set of choices. Some of the possible
worlds lead to dead ends, while others have useful values. e nonde
terministic program evaluator supports the illusion that time branches,
and that our programs have diﬀerent possible execution histories. When
42We assume that we have previously deﬁned a procedure prime? that tests whether
numbers are prime. Even with prime? deﬁned, the primesumpair procedure may
look suspiciously like the unhelpful “pseudoLisp” aempt to deﬁne the squareroot
function, which we described at the beginning of Section 1.1.7. In fact, a squareroot
procedure along those lines can actually be formulated as a nondeterministic program.
By incorporating a search mechanism into the evaluator, we are eroding the distinc
tion between purely declarative descriptions and imperative speciﬁcations of how to
compute answers. We’ll go even farther in this direction in Section 4.4.
560
we reach a dead end, we can revisit a previous choice point and proceed
along a diﬀerent branch.
e nondeterministic program evaluator implemented below is called
the amb evaluator because it is based on a new special form called amb.
We can type the above deﬁnition of primesumpair at the amb evalu
ator driver loop (along with deﬁnitions of prime?, anelementof, and
require) and run the procedure as follows:
;;; AmbEval input:
(primesumpair '(1 3 5 8) '(20 35 110))
;;; Starting a new problem
;;; AmbEval value:
(3 20)
e value returned was obtained aer the evaluator repeatedly chose
elements from each of the lists, until a successful choice was made.
Section 4.3.1 introduces amb and explains how it supports nondeter
minism through the evaluator’s automatic search mechanism. Section
4.3.2 presents examples of nondeterministic programs, and Section 4.3.3
gives the details of how to implement the amb evaluator by modifying
the ordinary Scheme evaluator.
4.3.1 Amb and Search
To extend Scheme to support nondeterminism, we introduce a new spe
cial form called amb.43 e expression
(amb ⟨e1⟩ ⟨e2⟩ : : : ⟨en⟩)
returns the value of one of the n expressions ⟨ei⟩ “ambiguously.” For
example, the expression
43e idea of amb for nondeterministic programming was ﬁrst described in 1961 by
John McCarthy (see McCarthy 1963).
561
(list (amb 1 2 3) (amb 'a 'b))
can have six possible values:
(1 a) (1 b) (2 a) (2 b) (3 a) (3 b)
amb with a single choice produces an ordinary (single) value.
amb with no choices—the expression (amb)—is an expression with
no acceptable values. Operationally, we can think of (amb) as an expres
sion that when evaluated causes the computation to “fail”: e compu
tation aborts and no value is produced. Using this idea, we can express
the requirement that a particular predicate expression p must be true as
follows:
(define (require p) (if (not p) (amb)))
With amb and require, we can implement the anelementof proce
dure used above:
(define (anelementof items)
(require (not (null? items)))
(amb (car items) (anelementof (cdr items))))
anelementof fails if the list is empty. Otherwise it ambiguously re
turns either the ﬁrst element of the list or an element chosen from the
rest of the list.
We can also express inﬁnite ranges of choices. e following proce
dure potentially returns any integer greater than or equal to some given
n:
(define (anintegerstartingfrom n)
(amb n (anintegerstartingfrom (+ n 1))))
is is like the stream procedure integersstartingfrom described
in Section 3.5.2, but with an important diﬀerence: e stream procedure
562
returns an object that represents the sequence of all integers beginning
with n, whereas the amb procedure returns a single integer.44
Abstractly, we can imagine that evaluating an amb expression causes
time to split into branches, where the computation continues on each
branch with one of the possible values of the expression. We say that
amb represents a nondeterministic choice point. If we had a machine with a
suﬃcient number of processors that could be dynamically allocated, we
could implement the search in a straightforward way. Execution would
proceed as in a sequential machine, until an amb expression is encoun
tered. At this point, more processors would be allocated and initialized
to continue all of the parallel executions implied by the choice. Each
processor would proceed sequentially as if it were the only choice, until
it either terminates by encountering a failure, or it further subdivides,
or it ﬁnishes.45
On the other hand, if we have a machine that can execute only one
process (or a few concurrent processes), we must consider the alterna
tives sequentially. One could imagine modifying an evaluator to pick
at random a branch to follow whenever it encounters a choice point.
44In actuality, the distinction between nondeterministically returning a single choice
and returning all choices depends somewhat on our point of view. From the perspective
of the code that uses the value, the nondeterministic choice returns a single value. From
the perspective of the programmer designing the code, the nondeterministic choice
potentially returns all possible values, and the computation branches so that each value
is investigated separately.
45One might object that this is a hopelessly ineﬃcient mechanism. It might require
millions of processors to solve some easily stated problem this way, and most of the
time most of those processors would be idle. is objection should be taken in the
context of history. Memory used to be considered just such an expensive commodity.
In 1964 a megabyte of cost about $400,000. Now every personal computer has
many megabytes of , and most of the time most of that is unused. It is hard
to underestimate the cost of massproduced electronics.
563
Random choice, however, can easily lead to failing values. We might
try running the evaluator over and over, making random choices and
hoping to ﬁnd a nonfailing value, but it is beer to systematically search
all possible execution paths. e amb evaluator that we will develop and
work with in this section implements a systematic search as follows:
When the evaluator encounters an application of amb, it initially selects
the ﬁrst alternative. is selection may itself lead to a further choice. e
evaluator will always initially choose the ﬁrst alternative at each choice
point. If a choice results in a failure, then the evaluator automagically46
backtracks to the most recent choice point and tries the next alternative.
If it runs out of alternatives at any choice point, the evaluator will back
up to the previous choice point and resume from there. is process
leads to a search strategy known as depthﬁrst search or chronological
backtracking.47
46Automagically: “Automatically, but in a way which, for some reason (typically be
cause it is too complicated, or too ugly, or perhaps even too trivial), the speaker doesn’t
feel like explaining.” (Steele et al. 1983, Raymond 1993)
47e integration of automatic search strategies into programming languages has
had a long and checkered history. e ﬁrst suggestions that nondeterministic algo
rithms might be elegantly encoded in a programming language with search and au
tomatic backtracking came from Robert Floyd (1967). Carl Hewi (1969) invented a
programming language called Planner that explicitly supported automatic chronolog
ical backtracking, providing for a builtin depthﬁrst search strategy. Sussman et al.
(1971) implemented a subset of this language, called MicroPlanner, which was used
to support work in problem solving and robot planning. Similar ideas, arising from
logic and theorem proving, led to the genesis in Edinburgh and Marseille of the ele
gant language Prolog (which we will discuss in Section 4.4). Aer suﬃcient frustration
with automatic search, McDermo and Sussman (1972) developed a language called
Conniver, which included mechanisms for placing the search strategy under program
mer control. is proved unwieldy, however, and Sussman and Stallman 1975 found a
more tractable approach while investigating methods of symbolic analysis for electrical
circuits. ey developed a nonchronological backtracking scheme that was based on
564
Driver loop
e driver loop for the amb evaluator has some unusual properties. It
reads an expression and prints the value of the ﬁrst nonfailing execu
tion, as in the primesumpair example shown above. If we want to see
the value of the next successful execution, we can ask the interpreter to
backtrack and aempt to generate a second nonfailing execution. is
is signaled by typing the symbol tryagain. If any expression except
tryagain is given, the interpreter will start a new problem, discarding
the unexplored alternatives in the previous problem. Here is a sample
interaction:
;;; AmbEval input:
(primesumpair '(1 3 5 8) '(20 35 110))
;;; Starting a new problem
;;; AmbEval value:
(3 20)
;;; AmbEval input:
tryagain
;;; AmbEval value:
tracing out the logical dependencies connecting facts, a technique that has come to be
known as dependencydirected backtracking. Although their method was complex, it pro
duced reasonably eﬃcient programs because it did lile redundant search. Doyle (1979)
and McAllester (1978; 1980) generalized and clariﬁed the methods of Stallman and Suss
man, developing a new paradigm for formulating search that is now called truth main
tenance. Modern problemsolving systems all use some form of truthmaintenance sys
tem as a substrate. See Forbus and deKleer 1993 for a discussion of elegant ways to
build truthmaintenance systems and applications using truth maintenance. Zabih et
al. 1987 describes a nondeterministic extension to Scheme that is based on amb; it is
similar to the interpreter described in this section, but more sophisticated, because it
uses dependencydirected backtracking rather than chronological backtracking. Win
ston 1992 gives an introduction to both kinds of backtracking.
565
(3 110)
;;; AmbEval input:
tryagain
;;; AmbEval value:
(8 35)
;;; AmbEval input:
tryagain
;;; There are no more values of
(primesumpair (quote (1 3 5 8)) (quote (20 35 110)))
;;; AmbEval input:
(primesumpair '(19 27 30) '(11 36 58))
;;; Starting a new problem
;;; AmbEval value:
(30 11)
Exercise 4.35: Write a procedure anintegerbetween that
returns an integer between two given bounds. is can be
used to implement a procedure that ﬁnds Pythagorean triples,
i.e., triples of integers (i; j; k) between the given bounds
such that i (cid:20) j and i2 + j2 = k2, as follows:
(define (apythagoreantriplebetween low high)
(let ((i (anintegerbetween low high)))
(let ((j (anintegerbetween i high)))
(let ((k (anintegerbetween j high)))
(require (= (+ (* i i) (* j j)) (* k k)))
(list i j k)))))
Exercise 4.36: Exercise 3.69 discussed how to generate the
stream of all Pythagorean triples, with no upper bound on
566
the size of the integers to be searched. Explain why simply
replacing anintegerbetween by anintegerstarting
from in the procedure in Exercise 4.35 is not an adequate
way to generate arbitrary Pythagorean triples. Write a pro
cedure that actually will accomplish this. (at is, write a
procedure for which repeatedly typing tryagain would in
principle eventually generate all Pythagorean triples.)
Exercise 4.37: Ben Bitdiddle claims that the following method
for generating Pythagorean triples is more eﬃcient than
the one in Exercise 4.35. Is he correct? (Hint: Consider the
number of possibilities that must be explored.)
(define (apythagoreantriplebetween low high)
(let ((i (anintegerbetween low high))
(hsq (* high high)))
(let ((j (anintegerbetween i high)))
(let ((ksq (+ (* i i) (* j j))))
(require (>= hsq ksq))
(let ((k (sqrt ksq)))
(require (integer? k))
(list i j k))))))
4.3.2 Examples of Nondeterministic Programs
Section 4.3.3 describes the implementation of the amb evaluator. First,
however, we give some examples of how it can be used. e advantage
of nondeterministic programming is that we can suppress the details of
how search is carried out, thereby expressing our programs at a higher
level of abstraction.
567
Logic Puzzles
e following puzzle (taken from Dinesman 1968) is typical of a large
class of simple logic puzzles:
Baker, Cooper, Fletcher, Miller, and Smith live on diﬀer
ent ﬂoors of an apartment house that contains only ﬁve
ﬂoors. Baker does not live on the top ﬂoor. Cooper does
not live on the boom ﬂoor. Fletcher does not live on ei
ther the top or the boom ﬂoor. Miller lives on a higher
ﬂoor than does Cooper. Smith does not live on a ﬂoor adja
cent to Fletcher’s. Fletcher does not live on a ﬂoor adjacent
to Cooper’s. Where does everyone live?
We can determine who lives on each ﬂoor in a straightforward way by
enumerating all the possibilities and imposing the given restrictions:48
(define (multipledwelling)
(let ((baker
(amb 1 2 3 4 5)) (cooper (amb 1 2 3 4 5))
(fletcher (amb 1 2 3 4 5)) (miller (amb 1 2 3 4 5))
(smith
(amb 1 2 3 4 5)))
(require
(distinct? (list baker cooper fletcher miller smith)))
(require (not (= baker 5)))
48Our program uses the following procedure to determine if the elements of a list
are distinct:
(define (distinct? items)
(cond ((null? items) true)
((null? (cdr items)) true)
((member (car items) (cdr items)) false)
(else (distinct? (cdr items)))))
member is like memq except that it uses equal? instead of eq? to test for equality.
568
(require (not (= cooper 1)))
(require (not (= fletcher 5)))
(require (not (= fletcher 1)))
(require (> miller cooper))
(require (not (= (abs ( smith fletcher)) 1)))
(require (not (= (abs ( fletcher cooper)) 1)))
(list (list 'baker baker)
(list 'cooper cooper)
(list 'fletcher fletcher) (list 'miller miller)
(list 'smith smith))))
Evaluating the expression (multipledwelling) produces the result
((baker 3) (cooper 2) (fletcher 4) (miller 5) (smith 1))
Although this simple procedure works, it is very slow. Exercise 4.39 and
Exercise 4.40 discuss some possible improvements.
Exercise 4.38: Modify the multipledwelling procedure to
omit the requirement that Smith and Fletcher do not live
on adjacent ﬂoors. How many solutions are there to this
modiﬁed puzzle?
Exercise 4.39: Does the order of the restrictions in the multiple
dwelling procedure aﬀect the answer? Does it aﬀect the
time to ﬁnd an answer? If you think it maers, demonstrate
a faster program obtained from the given one by reordering
the restrictions. If you think it does not maer, argue your
case.
Exercise 4.40: In the multiple dwelling problem, how many
sets of assignments are there of people to ﬂoors, both be
fore and aer the requirement that ﬂoor assignments be
distinct? It is very ineﬃcient to generate all possible assign
ments of people to ﬂoors and then leave it to backtracking
569
to eliminate them. For example, most of the restrictions de
pend on only one or two of the personﬂoor variables, and
can thus be imposed before ﬂoors have been selected for
all the people. Write and demonstrate a much more eﬃ
cient nondeterministic procedure that solves this problem
based upon generating only those possibilities that are not
already ruled out by previous restrictions. (Hint: is will
require a nest of let expressions.)
Exercise 4.41: Write an ordinary Scheme program to solve
the multiple dwelling puzzle.
Exercise 4.42: Solve the following “Liars” puzzle (from Phillips
1934):
Five schoolgirls sat for an examination. eir parents—so
they thought—showed an undue degree of interest in the
result. ey therefore agreed that, in writing home about
the examination, each girl should make one true statement
and one untrue one. e following are the relevant passages
from their leers:
• Bey: “Kiy was second in the examination. I was
only third.”
• Ethel: “You’ll be glad to hear that I was on top. Joan
was 2nd.”
• Joan: “I was third, and poor old Ethel was boom.”
• Kiy: “I came out second. Mary was only fourth.”
• Mary: “I was fourth. Top place was taken by Bey.”
570
What in fact was the order in which the ﬁve girls were
placed?
Exercise 4.43: Use the amb evaluator to solve the following
puzzle:49
Mary Ann Moore’s father has a yacht and so has each of
his four friends: Colonel Downing, Mr. Hall, Sir Barnacle
Hood, and Dr. Parker. Each of the ﬁve also has one daugh
ter and each has named his yacht aer a daughter of one of
the others. Sir Barnacle’s yacht is the Gabrielle, Mr. Moore
owns the Lorna; Mr. Hall the Rosalind. e Melissa, owned
by Colonel Downing, is named aer Sir Barnacle’s daugh
ter. Gabrielle’s father owns the yacht that is named aer
Dr. Parker’s daughter. Who is Lorna’s father?
Try to write the program so that it runs eﬃciently (see Ex
ercise 4.40). Also determine how many solutions there are
if we are not told that Mary Ann’s last name is Moore.
Exercise 4.44: Exercise 2.42 described the “eightqueens
puzzle” of placing queens on a chessboard so that no two at
tack each other. Write a nondeterministic program to solve
this puzzle.
Parsing natural language
Programs designed to accept natural language as input usually start by
aempting to parse the input, that is, to match the input against some
grammatical structure. For example, we might try to recognize simple
49is is taken from a booklet called “Problematical Recreations,” published in the
1960s by Lion Industries, where it is aributed to the Kansas State Engineer.
571
sentences consisting of an article followed by a noun followed by a verb,
such as “e cat eats.” To accomplish such an analysis, we must be able
to identify the parts of speech of individual words. We could start with
some lists that classify various words:50
(define nouns '(noun student professor cat class))
(define verbs '(verb studies lectures eats sleeps))
(define articles '(article the a))
We also need a grammar, that is, a set of rules describing how gram
matical elements are composed from simpler elements. A very simple
grammar might stipulate that a sentence always consists of two pieces—
a noun phrase followed by a verb—and that a noun phrase consists of
an article followed by a noun. With this grammar, the sentence “e cat
eats” is parsed as follows:
(sentence (nounphrase (article the) (noun cat))
(verb eats))
We can generate such a parse with a simple program that has separate
procedures for each of the grammatical rules. To parse a sentence, we
identify its two constituent pieces and return a list of these two ele
ments, tagged with the symbol sentence:
(define (parsesentence)
(list 'sentence
(parsenounphrase)
(parseword verbs)))
A noun phrase, similarly, is parsed by ﬁnding an article followed by a
noun:
50Here we use the convention that the ﬁrst element of each list designates the part
of speech for the rest of the words in the list.
572
(define (parsenounphrase)
(list 'nounphrase
(parseword articles)
(parseword nouns)))
At the lowest level, parsing boils down to repeatedly checking that the
next unparsed word is a member of the list of words for the required part
of speech. To implement this, we maintain a global variable *unparsed*,
which is the input that has not yet been parsed. Each time we check a
word, we require that *unparsed* must be nonempty and that it should
begin with a word from the designated list. If so, we remove that word
from *unparsed* and return the word together with its part of speech
(which is found at the head of the list):51
(define (parseword wordlist)
(require (not (null? *unparsed*)))
(require (memq (car *unparsed*) (cdr wordlist)))
(let ((foundword (car *unparsed*)))
(set! *unparsed* (cdr *unparsed*))
(list (car wordlist) foundword)))
To start the parsing, all we need to do is set *unparsed* to be the entire
input, try to parse a sentence, and check that nothing is le over:
(define *unparsed* '())
(define (parse input)
(set! *unparsed* input)
(let ((sent (parsesentence)))
(require (null? *unparsed*)) sent))
We can now try the parser and verify that it works for our simple test
sentence:
51Notice that parseword uses set! to modify the unparsed input list. For this to
work, our amb evaluator must undo the eﬀects of set! operations when it backtracks.
573
;;; AmbEval input:
(parse '(the cat eats))
;;; Starting a new problem
;;; AmbEval value:
(sentence (nounphrase (article the) (noun cat)) (verb eats))
e amb evaluator is useful here because it is convenient to express
the parsing constraints with the aid of require. Automatic search and
backtracking really pay oﬀ, however, when we consider more complex
grammars where there are choices for how the units can be decom
posed.
Let’s add to our grammar a list of prepositions:
(define prepositions '(prep for to in by with))
and deﬁne a prepositional phrase (e.g., “for the cat”) to be a preposition
followed by a noun phrase:
(define (parseprepositionalphrase)
(list 'prepphrase
(parseword prepositions)
(parsenounphrase)))
Now we can deﬁne a sentence to be a noun phrase followed by a verb
phrase, where a verb phrase can be either a verb or a verb phrase ex
tended by a prepositional phrase:52
(define (parsesentence)
(list 'sentence (parsenounphrase) (parseverbphrase)))
(define (parseverbphrase)
(define (maybeextend verbphrase)
(amb verbphrase
52Observe that this deﬁnition is recursive—a verb may be followed by any number
of prepositional phrases.
574
(maybeextend
(list 'verbphrase
verbphrase
(parseprepositionalphrase)))))
(maybeextend (parseword verbs)))
While we’re at it, we can also elaborate the deﬁnition of noun phrases
to permit such things as “a cat in the class.” What we used to call a
noun phrase, we’ll now call a simple noun phrase, and a noun phrase
will now be either a simple noun phrase or a noun phrase extended by
a prepositional phrase:
(define (parsesimplenounphrase)
(list 'simplenounphrase
(parseword articles)
(parseword nouns)))
(define (parsenounphrase)
(define (maybeextend nounphrase)
(amb nounphrase
(maybeextend
(list 'nounphrase
nounphrase
(parseprepositionalphrase)))))
(maybeextend (parsesimplenounphrase)))
Our new grammar lets us parse more complex sentences. For example
(parse '(the student with the cat sleeps in the class))
produces
(sentence
(nounphrase
(simplenounphrase (article the) (noun student))
(prepphrase
(prep with)
575
(simplenounphrase (article the) (noun cat))))
(verbphrase
(verb sleeps)
(prepphrase
(prep in)
(simplenounphrase (article the) (noun class)))))
Observe that a given input may have more than one legal parse. In the
sentence “e professor lectures to the student with the cat,” it may be
that the professor is lecturing with the cat, or that the student has the
cat. Our nondeterministic program ﬁnds both possibilities:
(parse '(the professor lectures to the student with the cat))
produces
(sentence
(simplenounphrase (article the) (noun professor))
(verbphrase
(verbphrase
(verb lectures)
(prepphrase
(prep to)
(simplenounphrase (article the) (noun student))))
(prepphrase
(prep with)
(simplenounphrase (article the) (noun cat)))))
Asking the evaluator to try again yields
(sentence
(simplenounphrase (article the) (noun professor))
(verbphrase
(verb lectures)
(prepphrase
(prep to)
576
(nounphrase
(simplenounphrase (article the) (noun student))
(prepphrase
(prep with)
(simplenounphrase (article the) (noun cat)))))))
Exercise 4.45: With the grammar given above, the follow
ing sentence can be parsed in ﬁve diﬀerent ways: “e pro
fessor lectures to the student in the class with the cat.” Give
the ﬁve parses and explain the diﬀerences in shades of mean
ing among them.
Exercise 4.46: e evaluators in Section 4.1 and Section 4.2
do not determine what order operands are evaluated in. We
will see that the amb evaluator evaluates them from le to
right. Explain why our parsing program wouldn’t work if
the operands were evaluated in some other order.
Exercise 4.47: Louis Reasoner suggests that, since a verb
phrase is either a verb or a verb phrase followed by a prepo
sitional phrase, it would be much more straightforward to
deﬁne the procedure parseverbphrase as follows (and
similarly for noun phrases):
(define (parseverbphrase)
(amb (parseword verbs)
(list 'verbphrase
(parseverbphrase)
(parseprepositionalphrase))))
Does this work? Does the program’s behavior change if we
interchange the order of expressions in the amb?
577
Exercise 4.48: Extend the grammar given above to handle
more complex sentences. For example, you could extend
noun phrases and verb phrases to include adjectives and
adverbs, or you could handle compound sentences.53
Exercise 4.49: Alyssa P. Hacker is more interested in gen
erating interesting sentences than in parsing them. She rea
sons that by simply changing the procedure parseword so
that it ignores the “input sentence” and instead always suc
ceeds and generates an appropriate word, we can use the
programs we had built for parsing to do generation instead.
Implement Alyssa’s idea, and show the ﬁrst halfdozen or
so sentences generated.54
4.3.3 Implementing the amb Evaluator
e evaluation of an ordinary Scheme expression may return a value,
may never terminate, or may signal an error. In nondeterministic Scheme
the evaluation of an expression may in addition result in the discovery
of a dead end, in which case evaluation must backtrack to a previous
53is kind of grammar can become arbitrarily complex, but it is only a toy as
far as real language understanding is concerned. Real naturallanguage understand
ing by computer requires an elaborate mixture of syntactic analysis and interpretation
of meaning. On the other hand, even toy parsers can be useful in supporting ﬂexi
ble command languages for programs such as informationretrieval systems. Winston
1992 discusses computational approaches to real language understanding and also the
applications of simple grammars to command languages.
54Although Alyssa’s idea works just ﬁne (and is surprisingly simple), the sentences
that it generates are a bit boring—they don’t sample the possible sentences of this lan
guage in a very interesting way. In fact, the grammar is highly recursive in many places,
and Alyssa’s technique “falls into” one of these recursions and gets stuck. See Exercise
4.50 for a way to deal with this.
578
choice point. e interpretation of nondeterministic Scheme is compli
cated by this extra case.
We will construct the amb evaluator for nondeterministic Scheme by
modifying the analyzing evaluator of Section 4.1.7.55 As in the analyz
ing evaluator, evaluation of an expression is accomplished by calling an
execution procedure produced by analysis of that expression. e dif
ference between the interpretation of ordinary Scheme and the inter
pretation of nondeterministic Scheme will be entirely in the execution
procedures.
Execution procedures and continuations
Recall that the execution procedures for the ordinary evaluator take one
argument: the environment of execution. In contrast, the execution pro
cedures in the amb evaluator take three arguments: the environment,
and two procedures called continuation procedures. e evaluation of
an expression will ﬁnish by calling one of these two continuations: If
the evaluation results in a value, the success continuation is called with
that value; if the evaluation results in the discovery of a dead end, the
failure continuation is called. Constructing and calling appropriate con
tinuations is the mechanism by which the nondeterministic evaluator
implements backtracking.
It is the job of the success continuation to receive a value and pro
ceed with the computation. Along with that value, the success contin
uation is passed another failure continuation, which is to be called sub
sequently if the use of that value leads to a dead end.
55We chose to implement the lazy evaluator in Section 4.2 as a modiﬁcation of the
ordinary metacircular evaluator of Section 4.1.1. In contrast, we will base the amb eval
uator on the analyzing evaluator of Section 4.1.7, because the execution procedures in
that evaluator provide a convenient framework for implementing backtracking.
579
It is the job of the failure continuation to try another branch of the
nondeterministic process. e essence of the nondeterministic language
is in the fact that expressions may represent choices among alternatives.
e evaluation of such an expression must proceed with one of the indi
cated alternative choices, even though it is not known in advance which
choices will lead to acceptable results. To deal with this, the evaluator
picks one of the alternatives and passes this value to the success con
tinuation. Together with this value, the evaluator constructs and passes
along a failure continuation that can be called later to choose a diﬀerent
alternative.
A failure is triggered during evaluation (that is, a failure continua
tion is called) when a user program explicitly rejects the current line of
aack (for example, a call to require may result in execution of (amb),
an expression that always fails—see Section 4.3.1). e failure continu
ation in hand at that point will cause the most recent choice point to
choose another alternative. If there are no more alternatives to be con
sidered at that choice point, a failure at an earlier choice point is trig
gered, and so on. Failure continuations are also invoked by the driver
loop in response to a tryagain request, to ﬁnd another value of the
expression.
In addition, if a sideeﬀect operation (such as assignment to a vari
able) occurs on a branch of the process resulting from a choice, it may be
necessary, when the process ﬁnds a dead end, to undo the side eﬀect be
fore making a new choice. is is accomplished by having the sideeﬀect
operation produce a failure continuation that undoes the side eﬀect and
propagates the failure.
In summary, failure continuations are constructed by
• amb expressions—to provide a mechanism to make alternative choices
if the current choice made by the amb expression leads to a dead
end;
580
• the toplevel driver—to provide a mechanism to report failure
when the choices are exhausted;
• assignments—to intercept failures and undo assignments during
backtracking.
Failures are initiated only when a dead end is encountered. is occurs
• if the user program executes (amb);
• if the user types tryagain at the toplevel driver.
Failure continuations are also called during processing of a failure:
• When the failure continuation created by an assignment ﬁnishes
undoing a side eﬀect, it calls the failure continuation it inter
cepted, in order to propagate the failure back to the choice point
that led to this assignment or to the top level.
• When the failure continuation for an amb runs out of choices, it
calls the failure continuation that was originally given to the amb,
in order to propagate the failure back to the previous choice point
or to the top level.
Structure of the evaluator
e syntax and datarepresentation procedures for the amb evaluator,
and also the basic analyze procedure, are identical to those in the eval
uator of Section 4.1.7, except for the fact that we need additional syntax
procedures to recognize the amb special form:56
56We assume that the evaluator supports let (see Exercise 4.22), which we have used
in our nondeterministic programs.
581
(define (amb? exp) (taggedlist? exp 'amb))
(define (ambchoices exp) (cdr exp))
We must also add to the dispatch in analyze a clause that will recognize
this special form and generate an appropriate execution procedure:
((amb? exp) (analyzeamb exp))
e toplevel procedure ambeval (similar to the version of eval given
in Section 4.1.7) analyzes the given expression and applies the resulting
execution procedure to the given environment, together with two given
continuations:
(define (ambeval exp env succeed fail)
((analyze exp) env succeed fail))
A success continuation is a procedure of two arguments: the value just
obtained and another failure continuation to be used if that value leads
to a subsequent failure. A failure continuation is a procedure of no ar
guments. So the general form of an execution procedure is
(lambda (env succeed fail)
;; succeed is (lambda (value fail) : : :)
;; fail is (lambda () : : :)
: : :)
For example, executing
(ambeval ⟨exp⟩
theglobalenvironment
(lambda (value fail) value)
(lambda () 'failed))
will aempt to evaluate the given expression and will return either the
expression’s value (if the evaluation succeeds) or the symbol failed (if
the evaluation fails). e call to ambeval in the driver loop shown below
582
uses much more complicated continuation procedures, which continue
the loop and support the tryagain request.
Most of the complexity of the amb evaluator results from the me
chanics of passing the continuations around as the execution proce
dures call each other. In going through the following code, you should
compare each of the execution procedures with the corresponding pro
cedure for the ordinary evaluator given in Section 4.1.7.
Simple expressions
e execution procedures for the simplest kinds of expressions are es
sentially the same as those for the ordinary evaluator, except for the
need to manage the continuations. e execution procedures simply
succeed with the value of the expression, passing along the failure con
tinuation that was passed to them.
(define (analyzeselfevaluating exp)
(lambda (env succeed fail)
(succeed exp fail)))
(define (analyzequoted exp)
(let ((qval (textofquotation exp)))
(lambda (env succeed fail)
(succeed qval fail))))
(define (analyzevariable exp)
(lambda (env succeed fail)
(succeed (lookupvariablevalue exp env) fail)))
(define (analyzelambda exp)
(let ((vars (lambdaparameters exp))
(bproc (analyzesequence (lambdabody exp))))
(lambda (env succeed fail)
(succeed (makeprocedure vars bproc env) fail))))
583
Notice that looking up a variable always ‘succeeds.’ If lookupvariable
value fails to ﬁnd the variable, it signals an error, as usual. Such a “fail
ure” indicates a program bug—a reference to an unbound variable; it is
not an indication that we should try another nondeterministic choice
instead of the one that is currently being tried.
Conditionals and sequences
Conditionals are also handled in a similar way as in the ordinary eval
uator. e execution procedure generated by analyzeif invokes the
predicate execution procedure pproc with a success continuation that
checks whether the predicate value is true and goes on to execute ei
ther the consequent or the alternative. If the execution of pproc fails,
the original failure continuation for the if expression is called.
(define (analyzeif exp)
(let ((pproc (analyze (ifpredicate exp)))
(cproc (analyze (ifconsequent exp)))
(aproc (analyze (ifalternative exp))))
(lambda (env succeed fail)
(pproc env
;; success continuation for evaluating the predicate
;; to obtain predvalue
(lambda (predvalue fail2)
(if (true? predvalue)
(cproc env succeed fail2)
(aproc env succeed fail2)))
;; failure continuation for evaluating the predicate
fail))))
Sequences are also handled in the same way as in the previous evaluator,
except for the machinations in the subprocedure sequentially that are
required for passing the continuations. Namely, to sequentially execute
584
a and then b, we call a with a success continuation that calls b.
(define (analyzesequence exps)
(define (sequentially a b)
(lambda (env succeed fail)
(a env
;; success continuation for calling a
(lambda (avalue fail2)
(b env succeed fail2))
;; failure continuation for calling a
fail)))
(define (loop firstproc restprocs)
(if (null? restprocs)
firstproc
(loop (sequentially firstproc
(car restprocs))
(cdr restprocs))))
(let ((procs (map analyze exps)))
(if (null? procs)
(error "Empty sequence: ANALYZE"))
(loop (car procs) (cdr procs))))
Definitions and assignments
Deﬁnitions are another case where we must go to some trouble to man
age the continuations, because it is necessary to evaluate the deﬁnition
value expression before actually deﬁning the new variable. To accom
plish this, the deﬁnitionvalue execution procedure vproc is called with
the environment, a success continuation, and the failure continuation.
If the execution of vproc succeeds, obtaining a value val for the deﬁned
variable, the variable is deﬁned and the success is propagated:
(define (analyzedefinition exp)
585
(let ((var (definitionvariable exp))
(vproc (analyze (definitionvalue exp))))
(lambda (env succeed fail)
(vproc env
(lambda (val fail2)
(definevariable! var val env)
(succeed 'ok fail2))
fail))))
Assignments are more interesting. is is the ﬁrst place where we really
use the continuations, rather than just passing them around. e exe
cution procedure for assignments starts out like the one for deﬁnitions.
It ﬁrst aempts to obtain the new value to be assigned to the variable.
If this evaluation of vproc fails, the assignment fails.
If vproc succeeds, however, and we go on to make the assignment,
we must consider the possibility that this branch of the computation
might later fail, which will require us to backtrack out of the assign
ment. us, we must arrange to undo the assignment as part of the
backtracking process.57
is is accomplished by giving vproc a success continuation (marked
with the comment “*1*” below) that saves the old value of the variable
before assigning the new value to the variable and proceeding from the
assignment. e failure continuation that is passed along with the value
of the assignment (marked with the comment “*2*” below) restores the
old value of the variable before continuing the failure. at is, a suc
cessful assignment provides a failure continuation that will intercept a
subsequent failure; whatever failure would otherwise have called fail2
calls this procedure instead, to undo the assignment before actually call
ing fail2.
57We didn’t worry about undoing deﬁnitions, since we can assume that internal def
initions are scanned out (Section 4.1.6).
586
(define (analyzeassignment exp)
(let ((var (assignmentvariable exp))
(vproc (analyze (assignmentvalue exp))))
(lambda (env succeed fail)
(vproc env
(lambda (val fail2)
(let ((oldvalue
; *1*
(lookupvariablevalue var env)))
(setvariablevalue! var val env)
(succeed 'ok
(lambda ()
; *2*
(setvariablevalue!
var oldvalue env)
(fail2)))))
fail))))
Procedure applications
e execution procedure for applications contains no new ideas except
for the technical complexity of managing the continuations. is com
plexity arises in analyzeapplication, due to the need to keep track of
the success and failure continuations as we evaluate the operands. We
use a procedure getargs to evaluate the list of operands, rather than
a simple map as in the ordinary evaluator.
(define (analyzeapplication exp)
(let ((fproc (analyze (operator exp)))
(aprocs (map analyze (operands exp))))
(lambda (env succeed fail)
(fproc env
(lambda (proc fail2)
(getargs aprocs
env
587
(lambda (args fail3)
(executeapplication
proc args succeed fail3))
fail2))
fail))))
In getargs, notice how cdring down the list of aproc execution pro
cedures and consing up the resulting list of args is accomplished by
calling each aproc in the list with a success continuation that recur
sively calls getargs. Each of these recursive calls to getargs has a
success continuation whose value is the cons of the newly obtained ar
gument onto the list of accumulated arguments:
(define (getargs aprocs env succeed fail)
(if (null? aprocs)
(succeed '() fail)
((car aprocs)
env
;; success continuation for this aproc
(lambda (arg fail2)
(getargs
(cdr aprocs)
env
;; success continuation for
;; recursive call to getargs
(lambda (args fail3)
(succeed (cons arg args) fail3))
fail2))
fail)))
e actual procedure application, which is performed by executeappli
cation, is accomplished in the same way as for the ordinary evaluator,
except for the need to manage the continuations.
588
(define (executeapplication proc args succeed fail)
(cond ((primitiveprocedure? proc)
(succeed (applyprimitiveprocedure proc args)
fail))
((compoundprocedure? proc)
((procedurebody proc)
(extendenvironment
(procedureparameters proc)
args
(procedureenvironment proc))
succeed
fail))
(else
(error "Unknown procedure type: EXECUTEAPPLICATION"
proc))))
Evaluating amb expressions
e amb special form is the key element in the nondeterministic lan
guage. Here we see the essence of the interpretation process and the
reason for keeping track of the continuations. e execution procedure
for amb deﬁnes a loop trynext that cycles through the execution pro
cedures for all the possible values of the amb expression. Each execution
procedure is called with a failure continuation that will try the next one.
When there are no more alternatives to try, the entire amb expression
fails.
(define (analyzeamb exp)
(let ((cprocs (map analyze (ambchoices exp))))
(lambda (env succeed fail)
(define (trynext choices)
(if (null? choices)
(fail)
589
((car choices)
env
succeed
(lambda () (trynext (cdr choices))))))
(trynext cprocs))))
Driver loop
e driver loop for the amb evaluator is complex, due to the mecha
nism that permits the user to try again in evaluating an expression. e
driver uses a procedure called internalloop, which takes as argument
a procedure tryagain. e intent is that calling tryagain should go
on to the next untried alternative in the nondeterministic evaluation.
internalloop either calls tryagain in response to the user typing
tryagain at the driver loop, or else starts a new evaluation by calling
ambeval.
e failure continuation for this call to ambeval informs the user
that there are no more values and reinvokes the driver loop.
e success continuation for the call to ambeval is more subtle.
We print the obtained value and then invoke the internal loop again
with a tryagain procedure that will be able to try the next alterna
tive. is nextalternative procedure is the second argument that was
passed to the success continuation. Ordinarily, we think of this second
argument as a failure continuation to be used if the current evaluation
branch later fails. In this case, however, we have completed a successful
evaluation, so we can invoke the “failure” alternative branch in order to
search for additional successful evaluations.
(define inputprompt ";;; AmbEval input:")
(define outputprompt ";;; AmbEval value:")
590
(define (driverloop)
(define (internalloop tryagain)
(promptforinput inputprompt)
(let ((input (read)))
(if (eq? input 'tryagain)
(tryagain)
(begin
(newline) (display ";;; Starting a new problem ")
(ambeval
input
theglobalenvironment
;; ambeval success
(lambda (val nextalternative)
(announceoutput outputprompt)
(userprint val)
(internalloop nextalternative))
;; ambeval failure
(lambda ()
(announceoutput
";;; There are no more values of")
(userprint input)
(driverloop)))))))
(internalloop
(lambda ()
(newline) (display ";;; There is no current problem")
(driverloop))))
e initial call to internalloop uses a tryagain procedure that com
plains that there is no current problem and restarts the driver loop. is
is the behavior that will happen if the user types tryagain when there
is no evaluation in progress.
Exercise 4.50: Implement a new special form ramb that is
591
like amb except that it searches alternatives in a random or
der, rather than from le to right. Show how this can help
with Alyssa’s problem in Exercise 4.49.
Exercise 4.51: Implement a new kind of assignment called
permanentset! that is not undone upon failure. For ex
ample, we can choose two distinct elements from a list and
count the number of trials required to make a successful
choice as follows:
(define count 0)
(let ((x (anelementof '(a b c)))
(y (anelementof '(a b c))))
(permanentset! count (+ count 1))
(require (not (eq? x y)))
(list x y count))
;;; Starting a new problem
;;; AmbEval value:
(a b 2)
;;; AmbEval input:
tryagain
;;; AmbEval value:
(a c 3)
What values would have been displayed if we had used
set! here rather than permanentset! ?
Exercise 4.52: Implement a new construct called iffail
that permits the user to catch the failure of an expression.
iffail takes two expressions. It evaluates the ﬁrst expres
sion as usual and returns as usual if the evaluation suc
ceeds. If the evaluation fails, however, the value of the sec
ond expression is returned, as in the following example:
592
;;; AmbEval input:
(iffail (let ((x (anelementof '(1 3 5))))
(require (even? x))
x)
'allodd)
;;; Starting a new problem
;;; AmbEval value:
allodd
;;; AmbEval input:
(iffail (let ((x (anelementof '(1 3 5 8))))
(require (even? x))
x)
'allodd)
;;; Starting a new problem
;;; AmbEval value:
8
Exercise 4.53: With permanentset! as described in Exer
cise 4.51 and iffail as in Exercise 4.52, what will be the
result of evaluating
(let ((pairs '()))
(iffail
(let ((p (primesumpair '(1 3 5 8)
'(20 35 110))))
(permanentset! pairs (cons p pairs))
(amb))
pairs))
Exercise 4.54: If we had not realized that require could be
implemented as an ordinary procedure that uses amb, to be
deﬁned by the user as part of a nondeterministic program,
593
we would have had to implement it as a special form. is
would require syntax procedures
(define (require? exp)
(taggedlist? exp 'require))
(define (requirepredicate exp)
(cadr exp))
and a new clause in the dispatch in analyze
((require? exp) (analyzerequire exp))
as well the procedure analyzerequire that handles require
expressions. Complete the following deﬁnition of analyze
require.
(define (analyzerequire exp)
(let ((pproc (analyze (requirepredicate exp))))
(lambda (env succeed fail)
(pproc env
(lambda (predvalue fail2)
(if ⟨??⟩
⟨??⟩
(succeed 'ok fail2)))
fail))))
4.4 Logic Programming
In Chapter 1 we stressed that computer science deals with imperative
(how to) knowledge, whereas mathematics deals with declarative (what
is) knowledge. Indeed, programming languages require that the pro
grammer express knowledge in a form that indicates the stepbystep
methods for solving particular problems. On the other hand, highlevel
594
languages provide, as part of the language implementation, a substantial
amount of methodological knowledge that frees the user from concern
with numerous details of how a speciﬁed computation will progress.
Most programming languages, including Lisp, are organized around
computing the values of mathematical functions. Expressionoriented
languages (such as Lisp, Fortran, and Algol) capitalize on the “pun” that
an expression that describes the value of a function may also be inter
preted as a means of computing that value. Because of this, most pro
gramming languages are strongly biased toward unidirectional compu
tations (computations with welldeﬁned inputs and outputs). ere are,
however, radically diﬀerent programming languages that relax this bias.
We saw one such example in Section 3.3.5, where the objects of compu
tation were arithmetic constraints. In a constraint system the direction
and the order of computation are not so well speciﬁed; in carrying out a
computation the system must therefore provide more detailed “how to”
knowledge than would be the case with an ordinary arithmetic compu
tation. is does not mean, however, that the user is released altogether
from the responsibility of providing imperative knowledge. ere are
many constraint networks that implement the same set of constraints,
and the user must choose from the set of mathematically equivalent
networks a suitable network to specify a particular computation.
e nondeterministic program evaluator of Section 4.3 also moves
away from the view that programming is about constructing algorithms
for computing unidirectional functions. In a nondeterministic language,
expressions can have more than one value, and, as a result, the compu
tation is dealing with relations rather than with singlevalued functions.
Logic programming extends this idea by combining a relational vision
of programming with a powerful kind of symbolic paern matching
595
called uniﬁcation.58
is approach, when it works, can be a very powerful way to write
programs. Part of the power comes from the fact that a single “what is”
fact can be used to solve a number of diﬀerent problems that would have
diﬀerent “how to” components. As an example, consider the append op
eration, which takes two lists as arguments and combines their elements
to form a single list. In a procedural language such as Lisp, we could
deﬁne append in terms of the basic list constructor cons, as we did in
Section 2.2.1:
58Logic programming has grown out of a long history of research in automatic the
orem proving. Early theoremproving programs could accomplish very lile, because
they exhaustively searched the space of possible proofs. e major breakthrough that
made such a search plausible was the discovery in the early 1960s of the uniﬁcation
algorithm and the resolution principle (Robinson 1965). Resolution was used, for exam
ple, by Green and Raphael (1968) (see also Green 1969) as the basis for a deductive
questionanswering system. During most of this period, researchers concentrated on
algorithms that are guaranteed to ﬁnd a proof if one exists. Such algorithms were dif
ﬁcult to control and to direct toward a proof. Hewi (1969) recognized the possibility
of merging the control structure of a programming language with the operations of a
logicmanipulation system, leading to the work in automatic search mentioned in Sec
tion 4.3.1 (Footnote 4.47). At the same time that this was being done, Colmerauer, in
Marseille, was developing rulebased systems for manipulating natural language (see
Colmerauer et al. 1973). He invented a programming language called Prolog for repre
senting those rules. Kowalski (1973; 1979), in Edinburgh, recognized that execution of
a Prolog program could be interpreted as proving theorems (using a proof technique
called linear Hornclause resolution). e merging of the last two strands led to the
logicprogramming movement. us, in assigning credit for the development of logic
programming, the French can point to Prolog’s genesis at the University of Marseille,
while the British can highlight the work at the University of Edinburgh. According to
people at , logic programming was developed by these groups in an aempt to ﬁg
ure out what Hewi was talking about in his brilliant but impenetrable Ph.D. thesis.
For a history of logic programming, see Robinson 1983.
596
(define (append x y)
(if (null? x) y (cons (car x) (append (cdr x) y))))
is procedure can be regarded as a translation into Lisp of the follow
ing two rules, the ﬁrst of which covers the case where the ﬁrst list is
empty and the second of which handles the case of a nonempty list,
which is a cons of two parts:
• For any list y, the empty list and y append to form y.
• For any u, v, y, and z, (cons u v) and y append to form (cons u
z) if v and y append to form z.59
Using the append procedure, we can answer questions such as
Find the append of (a b) and (c d).
But the same two rules are also suﬃcient for answering the following
sorts of questions, which the procedure can’t answer:
Find a list y that appends with (a b) to produce (a b c d).
Find all x and y that append to form (a b c d).
In a logic programming language, the programmer writes an append
“procedure” by stating the two rules about append given above. “How
to” knowledge is provided automatically by the interpreter to allow this
59To see the correspondence between the rules and the procedure, let x in the pro
cedure (where x is nonempty) correspond to (cons u v) in the rule. en z in the rule
corresponds to the append of (cdr x) and y.
597
single pair of rules to be used to answer all three types of questions
about append.60
Contemporary logic programming languages (including the one we
implement here) have substantial deﬁciencies, in that their general “how
to” methods can lead them into spurious inﬁnite loops or other unde
sirable behavior. Logic programming is an active ﬁeld of research in
computer science.61
Earlier in this chapter we explored the technology of implementing
interpreters and described the elements that are essential to an inter
preter for a Lisplike language (indeed, to an interpreter for any con
ventional language). Now we will apply these ideas to discuss an in
terpreter for a logic programming language. We call this language the
query language, because it is very useful for retrieving information from
data bases by formulating queries, or questions, expressed in the lan
guage. Even though the query language is very diﬀerent from Lisp, we
60is certainly does not relieve the user of the entire problem of how to compute
the answer. ere are many diﬀerent mathematically equivalent sets of rules for for
mulating the append relation, only some of which can be turned into eﬀective devices
for computing in any direction. In addition, sometimes “what is” information gives no
clue “how to” compute an answer. For example, consider the problem of computing the
y such that y2 = x.
61Interest in logic programming peaked during the early 80s when the Japanese gov
ernment began an ambitious project aimed at building superfast computers optimized
to run logic programming languages. e speed of such computers was to be measured
in LIPS (Logical Inferences Per Second) rather than the usual FLOPS (FLoatingpoint
Operations Per Second). Although the project succeeded in developing hardware and
soware as originally planned, the international computer industry moved in a dif
ferent direction. See Feigenbaum and Shrobe 1993 for an overview evaluation of the
Japanese project. e logic programming community has also moved on to consider
relational programming based on techniques other than simple paern matching, such
as the ability to deal with numerical constraints such as the ones illustrated in the
constraintpropagation system of Section 3.3.5.
598
will ﬁnd it convenient to describe the language in terms of the same gen
eral framework we have been using all along: as a collection of primitive
elements, together with means of combination that enable us to com
bine simple elements to create more complex elements and means of ab
straction that enable us to regard complex elements as single conceptual
units. An interpreter for a logic programming language is considerably
more complex than an interpreter for a language like Lisp. Neverthe
less, we will see that our querylanguage interpreter contains many of
the same elements found in the interpreter of Section 4.1. In particu
lar, there will be an “eval” part that classiﬁes expressions according to
type and an “apply” part that implements the language’s abstraction
mechanism (procedures in the case of Lisp, and rules in the case of logic
programming). Also, a central role is played in the implementation by
a frame data structure, which determines the correspondence between
symbols and their associated values. One additional interesting aspect
of our querylanguage implementation is that we make substantial use
of streams, which were introduced in Chapter 3.
4.4.1 Deductive Information Retrieval
Logic programming excels in providing interfaces to data bases for in
formation retrieval. e query language we shall implement in this chap
ter is designed to be used in this way.
In order to illustrate what the query system does, we will show how
it can be used to manage the data base of personnel records for Mi
crosha, a thriving hightechnology company in the Boston area. e
language provides paerndirected access to personnel information and
can also take advantage of general rules in order to make logical deduc
tions.
599
A sample data base
e personnel data base for Microsha contains assertions about com
pany personnel. Here is the information about Ben Bitdiddle, the resi
dent computer wizard:
(address (Bitdiddle Ben) (Slumerville (Ridge Road) 10))
(job (Bitdiddle Ben) (computer wizard))
(salary (Bitdiddle Ben) 60000)
Each assertion is a list (in this case a triple) whose elements can them
selves be lists.
As resident wizard, Ben is in charge of the company’s computer
division, and he supervises two programmers and one technician. Here
is the information about them:
(address (Hacker Alyssa P) (Cambridge (Mass Ave) 78))
(job (Hacker Alyssa P) (computer programmer))
(salary (Hacker Alyssa P) 40000)
(supervisor (Hacker Alyssa P) (Bitdiddle Ben))
(address (Fect Cy D) (Cambridge (Ames Street) 3))
(job (Fect Cy D) (computer programmer))
(salary (Fect Cy D) 35000)
(supervisor (Fect Cy D) (Bitdiddle Ben))
(address (Tweakit Lem E) (Boston (Bay State Road) 22))
(job (Tweakit Lem E) (computer technician))
(salary (Tweakit Lem E) 25000)
(supervisor (Tweakit Lem E) (Bitdiddle Ben))
ere is also a programmer trainee, who is supervised by Alyssa:
(address (Reasoner Louis) (Slumerville (Pine Tree Road) 80))
(job (Reasoner Louis) (computer programmer trainee))
600
(salary (Reasoner Louis) 30000)
(supervisor (Reasoner Louis) (Hacker Alyssa P))
All of these people are in the computer division, as indicated by the
word computer as the ﬁrst item in their job descriptions.
Ben is a highlevel employee. His supervisor is the company’s big
wheel himself:
(supervisor (Bitdiddle Ben) (Warbucks Oliver))
(address (Warbucks Oliver) (Swellesley (Top Heap Road)))
(job (Warbucks Oliver) (administration big wheel))
(salary (Warbucks Oliver) 150000)
Besides the computer division supervised by Ben, the company has an
accounting division, consisting of a chief accountant and his assistant:
(address (Scrooge Eben) (Weston (Shady Lane) 10))
(job (Scrooge Eben) (accounting chief accountant))
(salary (Scrooge Eben) 75000)
(supervisor (Scrooge Eben) (Warbucks Oliver))
(address (Cratchet Robert) (Allston (N Harvard Street) 16))
(job (Cratchet Robert) (accounting scrivener))
(salary (Cratchet Robert) 18000)
(supervisor (Cratchet Robert) (Scrooge Eben))
ere is also a secretary for the big wheel:
(address (Aull DeWitt) (Slumerville (Onion Square) 5))
(job (Aull DeWitt) (administration secretary))
(salary (Aull DeWitt) 25000)
(supervisor (Aull DeWitt) (Warbucks Oliver))
e data base also contains assertions about which kinds of jobs can be
done by people holding other kinds of jobs. For instance, a computer
601
wizard can do the jobs of both a computer programmer and a computer
technician:
(candojob (computer wizard) (computer programmer))
(candojob (computer wizard) (computer technician))
A computer programmer could ﬁll in for a trainee:
(candojob (computer programmer)
(computer programmer trainee))
Also, as is well known,
(candojob (administration secretary)
(administration big wheel))
Simple queries
e query language allows users to retrieve information from the data
base by posing queries in response to the system’s prompt. For example,
to ﬁnd all computer programmers one can say
;;; Query input:
(job ?x (computer programmer))
e system will respond with the following items:
;;; Query results:
(job (Hacker Alyssa P) (computer programmer))
(job (Fect Cy D) (computer programmer))
e input query speciﬁes that we are looking for entries in the data base
that match a certain paern. In this example, the paern speciﬁes en
tries consisting of three items, of which the ﬁrst is the literal symbol job,
the second can be anything, and the third is the literal list (computer
programmer). e “anything” that can be the second item in the match
ing list is speciﬁed by a paern variable, ?x. e general form of a paern
602
variable is a symbol, taken to be the name of the variable, preceded by
a question mark. We will see below why it is useful to specify names
for paern variables rather than just puing ? into paerns to repre
sent “anything.” e system responds to a simple query by showing all
entries in the data base that match the speciﬁed paern.
A paern can have more than one variable. For example, the query
(address ?x ?y)
will list all the employees’ addresses.
A paern can have no variables, in which case the query simply
determines whether that paern is an entry in the data base. If so, there
will be one match; if not, there will be no matches.
e same paern variable can appear more than once in a query,
specifying that the same “anything” must appear in each position. is
is why variables have names. For example,
(supervisor ?x ?x)
ﬁnds all people who supervise themselves (though there are no such
assertions in our sample data base).
e query
(job ?x (computer ?type))
matches all job entries whose third item is a twoelement list whose ﬁrst
item is computer:
(job (Bitdiddle Ben) (computer wizard))
(job (Hacker Alyssa P) (computer programmer))
(job (Fect Cy D) (computer programmer))
(job (Tweakit Lem E) (computer technician))
is same paern does not match
(job (Reasoner Louis) (computer programmer trainee))
603
because the third item in the entry is a list of three elements, and the
paern’s third item speciﬁes that there should be two elements. If we
wanted to change the paern so that the third item could be any list
beginning with computer, we could specify62
(job ?x (computer . ?type))
For example,
(computer . ?type)
matches the data
(computer programmer trainee)
with ?type as the list (programmer trainee). It also matches the data
(computer programmer)
with ?type as the list (programmer), and matches the data
(computer)
with ?type as the empty list ().
We can describe the query language’s processing of simple queries
as follows:
• e system ﬁnds all assignments to variables in the query paern
that satisfy the paern—that is, all sets of values for the variables
such that if the paern variables are instantiated with (replaced
by) the values, the result is in the data base.
• e system responds to the query by listing all instantiations of
the query paern with the variable assignments that satisfy it.
62is uses the doedtail notation introduced in Exercise 2.20.
604
Note that if the paern has no variables, the query reduces to a deter
mination of whether that paern is in the data base. If so, the empty
assignment, which assigns no values to variables, satisﬁes that paern
for that data base.
Exercise 4.55: Give simple queries that retrieve the follow
ing information from the data base:
1. all people supervised by Ben Bitdiddle;
2. the names and jobs of all people in the accounting di
vision;
3. the names and addresses of all people who live in Slumerville.
Compound queries
Simple queries form the primitive operations of the query language.
In order to form compound operations, the query language provides
means of combination. One thing that makes the query language a logic
programming language is that the means of combination mirror the
means of combination used in forming logical expressions: and, or, and
not. (Here and, or, and not are not the Lisp primitives, but rather oper
ations built into the query language.)
We can use and as follows to ﬁnd the addresses of all the computer
programmers:
(and (job ?person (computer programmer))
(address ?person ?where))
e resulting output is
(and (job (Hacker Alyssa P) (computer programmer))
(address (Hacker Alyssa P) (Cambridge (Mass Ave) 78)))
605
(and (job (Fect Cy D) (computer programmer))
(address (Fect Cy D) (Cambridge (Ames Street) 3)))
In general,
(and ⟨query1⟩ ⟨query2⟩ : : : ⟨queryn⟩)
is satisﬁed by all sets of values for the paern variables that simultane
ously satisfy ⟨query1⟩ : : : ⟨queryn⟩.
As for simple queries, the system processes a compound query by
ﬁnding all assignments to the paern variables that satisfy the query,
then displaying instantiations of the query with those values.
Another means of constructing compound queries is through or.
For example,
(or (supervisor ?x (Bitdiddle Ben))
(supervisor ?x (Hacker Alyssa P)))
will ﬁnd all employees supervised by Ben Bitdiddle or Alyssa P. Hacker:
(or (supervisor (Hacker Alyssa P) (Bitdiddle Ben))
(supervisor (Hacker Alyssa P) (Hacker Alyssa P)))
(or (supervisor (Fect Cy D) (Bitdiddle Ben))
(supervisor (Fect Cy D) (Hacker Alyssa P)))
(or (supervisor (Tweakit Lem E) (Bitdiddle Ben))
(supervisor (Tweakit Lem E) (Hacker Alyssa P)))
(or (supervisor (Reasoner Louis) (Bitdiddle Ben))
(supervisor (Reasoner Louis) (Hacker Alyssa P)))
In general,
(or ⟨query1⟩ ⟨query2⟩ : : : ⟨queryn⟩)
is satisﬁed by all sets of values for the paern variables that satisfy at
least one of ⟨query1⟩ : : : ⟨queryn⟩.
Compound queries can also be formed with not. For example,
606
(and (supervisor ?x (Bitdiddle Ben))
(not (job ?x (computer programmer))))
ﬁnds all people supervised by Ben Bitdiddle who are not computer pro
grammers. In general,
(not ⟨query1⟩)
is satisﬁed by all assignments to the paern variables that do not satisfy
⟨query1⟩.63
e ﬁnal combining form is called lispvalue. When lispvalue
is the ﬁrst element of a paern, it speciﬁes that the next element is a
Lisp predicate to be applied to the rest of the (instantiated) elements as
arguments. In general,
(lispvalue ⟨predicate⟩ ⟨arg1⟩ : : : ⟨argn⟩)
will be satisﬁed by assignments to the paern variables for which the
⟨predicate⟩ applied to the instantiated ⟨arg1⟩ : : : ⟨argn⟩ is true. For ex
ample, to ﬁnd all people whose salary is greater than $30,000 we could
write64
(and (salary ?person ?amount) (lispvalue > ?amount 30000))
Exercise 4.56: Formulate compound queries that retrieve
the following information:
63Actually, this description of not is valid only for simple cases. e real behavior of
not is more complex. We will examine not’s peculiarities in sections Section 4.4.2 and
Section 4.4.3.
64lispvalue should be used only to perform an operation not provided in the query
language. In particular, it should not be used to test equality (since that is what the
matching in the query language is designed to do) or inequality (since that can be done
with the same rule shown below).
607
a. the names of all people who are supervised by Ben
Bitdiddle, together with their addresses;
b. all people whose salary is less than Ben Bitdiddle’s,
together with their salary and Ben Bitdiddle’s salary;
c. all people who are supervised by someone who is not
in the computer division, together with the supervi
sor’s name and job.
Rules
In addition to primitive queries and compound queries, the query lan
guage provides means for abstracting queries. ese are given by rules.
e rule
(rule (livesnear ?person1 ?person2)
(and (address ?person1 (?town . ?rest1))
(address ?person2 (?town . ?rest2))
(not (same ?person1 ?person2))))
speciﬁes that two people live near each other if they live in the same
town. e ﬁnal not clause prevents the rule from saying that all peo
ple live near themselves. e same relation is deﬁned by a very simple
rule:65
(rule (same ?x ?x))
65Notice that we do not need same in order to make two things be the same: We
just use the same paern variable for each—in eﬀect, we have one thing instead of two
things in the ﬁrst place. For example, see ?town in the livesnear rule and ?middle
manager in the wheel rule below. same is useful when we want to force two things to
be diﬀerent, such as ?person1 and ?person2 in the livesnear rule. Although using
the same paern variable in two parts of a query forces the same value to appear in
both places, using diﬀerent paern variables does not force diﬀerent values to appear.
(e values assigned to diﬀerent paern variables may be the same or diﬀerent.)
608
e following rule declares that a person is a “wheel” in an organization
if he supervises someone who is in turn a supervisor:
(rule (wheel ?person)
(and (supervisor ?middlemanager ?person)
(supervisor ?x ?middlemanager)))
e general form of a rule is
(rule ⟨conclusion⟩ ⟨body⟩)
where ⟨conclusion⟩ is a paern and ⟨body⟩ is any query.66 We can think
of a rule as representing a large (even inﬁnite) set of assertions, namely
all instantiations of the rule conclusion with variable assignments that
satisfy the rule body. When we described simple queries (paerns), we
said that an assignment to variables satisﬁes a paern if the instantiated
paern is in the data base. But the paern needn’t be explicitly in the
data base as an assertion. It can be an implicit assertion implied by a
rule. For example, the query
(livesnear ?x (Bitdiddle Ben))
results in
(livesnear (Reasoner Louis) (Bitdiddle Ben))
(livesnear (Aull DeWitt) (Bitdiddle Ben))
To ﬁnd all computer programmers who live near Ben Bitdiddle, we can
ask
(and (job ?x (computer programmer))
(livesnear ?x (Bitdiddle Ben)))
66We will also allow rules without bodies, as in same, and we will interpret such a
rule to mean that the rule conclusion is satisﬁed by any values of the variables.
609
As in the case of compound procedures, rules can be used as parts of
other rules (as we saw with the livesnear rule above) or even be de
ﬁned recursively. For instance, the rule
(rule (outrankedby ?staffperson ?boss)
(or (supervisor ?staffperson ?boss)
(and (supervisor ?staffperson ?middlemanager)
(outrankedby ?middlemanager ?boss))))
says that a staﬀ person is outranked by a boss in the organization if the
boss is the person’s supervisor or (recursively) if the person’s supervisor
is outranked by the boss.
Exercise 4.57: Deﬁne a rule that says that person 1 can re
place person 2 if either person 1 does the same job as person
2 or someone who does person 1’s job can also do person 2’s
job, and if person 1 and person 2 are not the same person.
Using your rule, give queries that ﬁnd the following:
a. all people who can replace Cy D. Fect;
b. all people who can replace someone who is being paid
more than they are, together with the two salaries.
Exercise 4.58: Deﬁne a rule that says that a person is a “big
shot” in a division if the person works in the division but
does not have a supervisor who works in the division.
Exercise 4.59: Ben Bitdiddle has missed one meeting too
many. Fearing that his habit of forgeing meetings could
cost him his job, Ben decides to do something about it. He
adds all the weekly meetings of the ﬁrm to the Microsha
data base by asserting the following:
610
(meeting accounting (Monday 9am))
(meeting administration (Monday 10am))
(meeting computer (Wednesday 3pm))
(meeting administration (Friday 1pm))
Each of the above assertions is for a meeting of an entire di
vision. Ben also adds an entry for the companywide meet
ing that spans all the divisions. All of the company’s em
ployees aend this meeting.
(meeting wholecompany (Wednesday 4pm))
a. On Friday morning, Ben wants to query the data base
for all the meetings that occur that day. What query
should he use?
b. Alyssa P. Hacker is unimpressed. She thinks it would
be much more useful to be able to ask for her meetings
by specifying her name. So she designs a rule that says
that a person’s meetings include all wholecompany
meetings plus all meetings of that person’s division.
Fill in the body of Alyssa’s rule.
(rule (meetingtime ?person ?dayandtime)
⟨rulebody⟩)
c. Alyssa arrives at work on Wednesday morning and
wonders what meetings she has to aend that day.
Having deﬁned the above rule, what query should she
make to ﬁnd this out?
Exercise 4.60: By giving the query
(livesnear ?person (Hacker Alyssa P))
611
Alyssa P. Hacker is able to ﬁnd people who live near her,
with whom she can ride to work. On the other hand, when
she tries to ﬁnd all pairs of people who live near each other
by querying
(livesnear ?person1 ?person2)
she notices that each pair of people who live near each
other is listed twice; for example,
(livesnear (Hacker Alyssa P) (Fect Cy D))
(livesnear (Fect Cy D) (Hacker Alyssa P))
Why does this happen? Is there a way to ﬁnd a list of people
who live near each other, in which each pair appears only
once? Explain.
Logic as programs
We can regard a rule as a kind of logical implication: If an assignment
of values to paern variables satisﬁes the body, then it satisﬁes the con
clusion. Consequently, we can regard the query language as having the
ability to perform logical deductions based upon the rules. As an exam
ple, consider the append operation described at the beginning of Section
4.4. As we said, append can be characterized by the following two rules:
• For any list y, the empty list and y append to form y.
• For any u, v, y, and z, (cons u v) and y append to form (cons u
z) if v and y append to form z.
To express this in our query language, we deﬁne two rules for a relation
(appendtoform x y z)
612
which we can interpret to mean “x and y append to form z”:
(rule (appendtoform () ?y ?y))
(rule (appendtoform (?u . ?v) ?y (?u . ?z))
(appendtoform ?v ?y ?z))
e ﬁrst rule has no body, which means that the conclusion holds for
any value of ?y. Note how the second rule makes use of doedtail no
tation to name the car and cdr of a list.
Given these two rules, we can formulate queries that compute the
append of two lists:
;;; Query input:
(appendtoform (a b) (c d) ?z)
;;; Query results:
(appendtoform (a b) (c d) (a b c d))
What is more striking, we can use the same rules to ask the question
“Which list, when appended to (a b), yields (a b c d)?” is is done
as follows:
;;; Query input:
(appendtoform (a b) ?y (a b c d))
;;; Query results:
(appendtoform (a b) (c d) (a b c d))
We can also ask for all pairs of lists that append to form (a b c d):
;;; Query input:
(appendtoform ?x ?y (a b c d))
;;; Query results:
(appendtoform () (a b c d) (a b c d))
(appendtoform (a) (b c d) (a b c d))
(appendtoform (a b) (c d) (a b c d))
(appendtoform (a b c) (d) (a b c d))
(appendtoform (a b c d) () (a b c d))
613
e query system may seem to exhibit quite a bit of intelligence in using
the rules to deduce the answers to the queries above. Actually, as we
will see in the next section, the system is following a welldetermined
algorithm in unraveling the rules. Unfortunately, although the system
works impressively in the append case, the general methods may break
down in more complex cases, as we will see in Section 4.4.3.
Exercise 4.61: e following rules implement a nextto
relation that ﬁnds adjacent elements of a list:
(rule (?x nextto ?y in (?x ?y . ?u)))
(rule (?x nextto ?y in (?v . ?z))
(?x nextto ?y in ?z))
What will the response be to the following queries?
(?x nextto ?y in (1 (2 3) 4))
(?x nextto 1 in (2 1 3 1))
Exercise 4.62: Deﬁne rules to implement the lastpair
operation of Exercise 2.17, which returns a list containing
the last element of a nonempty list. Check your rules on
queries such as (lastpair (3) ?x), (lastpair (1 2
3) ?x) and (lastpair (2 ?x) (3)). Do your rules work
correctly on queries such as (lastpair ?x (3)) ?
Exercise 4.63: e following data base (see Genesis 4) traces
the genealogy of the descendants of Ada back to Adam, by
way of Cain:
(son Adam Cain)
(son Cain Enoch)
(son Enoch Irad)
614
(son Irad Mehujael)
(son Mehujael Methushael)
(son Methushael Lamech)
(wife Lamech Ada)
(son Ada Jabal)
(son Ada Jubal)
Formulate rules such as “If S is the son of f , and f is the
son of G, then S is the grandson of G” and “If W is the wife
of M, and S is the son of W , then S is the son of M” (which
was supposedly more true in biblical times than today) that
will enable the query system to ﬁnd the grandson of Cain;
the sons of Lamech; the grandsons of Methushael. (See Ex
ercise 4.69 for some rules to deduce more complicated re
lationships.)
4.4.2 How the ery System Works
In Section 4.4.4 we will present an implementation of the query inter
preter as a collection of procedures. In this section we give an overview
that explains the general structure of the system independent of low
level implementation details. Aer describing the implementation of the
interpreter, we will be in a position to understand some of its limitations
and some of the subtle ways in which the query language’s logical op
erations diﬀer from the operations of mathematical logic.
It should be apparent that the query evaluator must perform some
kind of search in order to match queries against facts and rules in the
data base. One way to do this would be to implement the query system
as a nondeterministic program, using the amb evaluator of Section 4.3
(see Exercise 4.78). Another possibility is to manage the search with the
aid of streams. Our implementation follows this second approach.
615
e query system is organized around two central operations called
paern matching and uniﬁcation. We ﬁrst describe paern matching and
explain how this operation, together with the organization of informa
tion in terms of streams of frames, enables us to implement both simple
and compound queries. We next discuss uniﬁcation, a generalization of
paern matching needed to implement rules. Finally, we show how the
entire query interpreter ﬁts together through a procedure that classiﬁes
expressions in a manner analogous to the way eval classiﬁes expres
sions for the interpreter described in Section 4.1.
Paern matching
A paern matcher is a program that tests whether some datum ﬁts a
speciﬁed paern. For example, the data list ((a b) c (a b)) matches
the paern (?x c ?x) with the paern variable ?x bound to (a b).
e same data list matches the paern (?x ?y ?z) with ?x and ?z both
bound to (a b) and ?y bound to c. It also matches the paern ((?x ?y)
c (?x ?y)) with ?x bound to a and ?y bound to b. However, it does not
match the paern (?x a ?y), since that paern speciﬁes a list whose
second element is the symbol a.
e paern matcher used by the query system takes as inputs a
paern, a datum, and a frame that speciﬁes bindings for various paern
variables. It checks whether the datum matches the paern in a way that
is consistent with the bindings already in the frame. If so, it returns the
given frame augmented by any bindings that may have been determined
by the match. Otherwise, it indicates that the match has failed.
For example, using the paern (?x ?y ?x) to match (a b a) given
an empty frame will return a frame specifying that ?x is bound to a
and ?y is bound to b. Trying the match with the same paern, the same
datum, and a frame specifying that ?y is bound to a will fail. Trying the
616
match with the same paern, the same datum, and a frame in which ?y
is bound to b and ?x is unbound will return the given frame augmented
by a binding of ?x to a.
e paern matcher is all the mechanism that is needed to pro
cess simple queries that don’t involve rules. For instance, to process the
query
(job ?x (computer programmer))
we scan through all assertions in the data base and select those that
match the paern with respect to an initially empty frame. For each
match we ﬁnd, we use the frame returned by the match to instantiate
the paern with a value for ?x.
Streams of frames
e testing of paerns against frames is organized through the use of
streams. Given a single frame, the matching process runs through the
database entries one by one. For each database entry, the matcher gen
erates either a special symbol indicating that the match has failed or an
extension to the frame. e results for all the database entries are col
lected into a stream, which is passed through a ﬁlter to weed out the
failures. e result is a stream of all the frames that extend the given
frame via a match to some assertion in the data base.67
67Because matching is generally very expensive, we would like to avoid applying
the full matcher to every element of the data base. is is usually arranged by breaking
up the process into a fast, coarse match and the ﬁnal match. e coarse match ﬁlters
the data base to produce a small set of candidates for the ﬁnal match. With care, we
can arrange our data base so that some of the work of coarse matching can be done
when the data base is constructed rather then when we want to select the candidates.
is is called indexing the data base. ere is a vast technology built around database
indexing schemes. Our implementation, described in Section 4.4.4, contains a simple
minded form of such an optimization.
617
Figure 4.4: A query processes a stream of frames.
In our system, a query takes an input stream of frames and per
forms the above matching operation for every frame in the stream, as
indicated in Figure 4.4. at is, for each frame in the input stream, the
query generates a new stream consisting of all extensions to that frame
by matches to assertions in the data base. All these streams are then
combined to form one huge stream, which contains all possible exten
sions of every frame in the input stream. is stream is the output of
the query.
To answer a simple query, we use the query with an input stream
consisting of a single empty frame. e resulting output stream contains
all extensions to the empty frame (that is, all answers to our query).
is stream of frames is then used to generate a stream of copies of the
original query paern with the variables instantiated by the values in
each frame, and this is the stream that is ﬁnally printed.
Compound queries
e real elegance of the streamofframes implementation is evident
when we deal with compound queries. e processing of compound
618
input streamof framesoutput stream of frames,filtered and extendedquery(job ?x ?y)stream of assertionsfrom data baseFigure 4.5: e and combination of two queries is produced
by operating on the stream of frames in series.
queries makes use of the ability of our matcher to demand that a match
be consistent with a speciﬁed frame. For example, to handle the and of
two queries, such as
(and (candojob ?x (computer programmer trainee))
(job ?person ?x))
(informally, “Find all people who can do the job of a computer program
mer trainee”), we ﬁrst ﬁnd all entries that match the paern
(candojob ?x (computer programmer trainee))
is produces a stream of frames, each of which contains a binding for
?x. en for each frame in the stream we ﬁnd all entries that match
(job ?person ?x)
in a way that is consistent with the given binding for ?x. Each such
match will produce a frame containing bindings for ?x and ?person.
e and of two queries can be viewed as a series combination of the
two component queries, as shown in Figure 4.5. e frames that pass
619
(and A B)data baseinput streamof framesoutput streamof framesABFigure 4.6: e or combination of two queries is produced
by operating on the stream of frames in parallel and merg
ing the results.
through the ﬁrst query ﬁlter are ﬁltered and further extended by the
second query.
Figure 4.6 shows the analogous method for computing the or of two
queries as a parallel combination of the two component queries. e
input stream of frames is extended separately by each query. e two
resulting streams are then merged to produce the ﬁnal output stream.
Even from this highlevel description, it is apparent that the pro
cessing of compound queries can be slow. For example, since a query
may produce more than one output frame for each input frame, and
each query in an and gets its input frames from the previous query, an
and query could, in the worst case, have to perform a number of matches
620
mergeAB(or A B)data baseinput streamof framesoutput streamof framesthat is exponential in the number of queries (see Exercise 4.76).68 ough
systems for handling only simple queries are quite practical, dealing
with complex queries is extremely diﬃcult.69
From the streamofframes viewpoint, the not of some query acts
as a ﬁlter that removes all frames for which the query can be satisﬁed.
For instance, given the paern
(not (job ?x (computer programmer)))
we aempt, for each frame in the input stream, to produce extension
frames that satisfy (job ?x (computer programmer)). We remove
from the input stream all frames for which such extensions exist. e
result is a stream consisting of only those frames in which the binding
for ?x does not satisfy (job ?x (computer programmer)). For example,
in processing the query
(and (supervisor ?x ?y)
(not (job ?x (computer programmer))))
the ﬁrst clause will generate frames with bindings for ?x and ?y. e not
clause will then ﬁlter these by removing all frames in which the binding
for ?x satisﬁes the restriction that ?x is a computer programmer.70
e lispvalue special form is implemented as a similar ﬁlter on
frame streams. We use each frame in the stream to instantiate any vari
ables in the paern, then apply the Lisp predicate. We remove from the
input stream all frames for which the predicate fails.
68But this kind of exponential explosion is not common in and queries because the
added conditions tend to reduce rather than expand the number of frames produced.
69ere is a large literature on databasemanagement systems that is concerned with
how to handle complex queries eﬃciently.
70ere is a subtle diﬀerence between this ﬁlter implementation of not and the usual
meaning of not in mathematical logic. See Section 4.4.3.
621
Unification
In order to handle rules in the query language, we must be able to ﬁnd
the rules whose conclusions match a given query paern. Rule conclu
sions are like assertions except that they can contain variables, so we
will need a generalization of paern matching—called uniﬁcation—in
which both the “paern” and the “datum” may contain variables.
A uniﬁer takes two paerns, each containing constants and vari
ables, and determines whether it is possible to assign values to the vari
ables that will make the two paerns equal. If so, it returns a frame
containing these bindings. For example, unifying (?x a ?y) and (?y
?z a) will specify a frame in which ?x, ?y, and ?z must all be bound
to a. On the other hand, unifying (?x ?y a) and (?x b ?y) will fail,
because there is no value for ?y that can make the two paerns equal.
(For the second elements of the paerns to be equal, ?y would have to
be b; however, for the third elements to be equal, ?y would have to be
a.) e uniﬁer used in the query system, like the paern matcher, takes
a frame as input and performs uniﬁcations that are consistent with this
frame.
e uniﬁcation algorithm is the most technically diﬃcult part of the
query system. With complex paerns, performing uniﬁcation may seem
to require deduction. To unify (?x ?x) and ((a ?y c) (a b ?z)), for
example, the algorithm must infer that ?x should be (a b c), ?y should
be b, and ?z should be c. We may think of this process as solving a
set of equations among the paern components. In general, these are
simultaneous equations, which may require substantial manipulation
to solve.71 For example, unifying (?x ?x) and ((a ?y c) (a b ?z))
may be thought of as specifying the simultaneous equations
71In onesided paern matching, all the equations that contain paern variables are
explicit and already solved for the unknown (the paern variable).
622
?x
?x
= (a ?y c)
= (a b ?z)
ese equations imply that
(a ?y c) =
(a b ?z)
which in turn implies that
a
?y
c
= a,
= b,
= ?z,
and hence that
= (a b c)
?x
In a successful paern match, all paern variables become bound, and
the values to which they are bound contain only constants. is is also
true of all the examples of uniﬁcation we have seen so far. In general,
however, a successful uniﬁcation may not completely determine the
variable values; some variables may remain unbound and others may
be bound to values that contain variables.
Consider the uniﬁcation of (?x a) and ((b ?y) ?z). We can deduce
that ?x = (b ?y) and a = ?z, but we cannot further solve for ?x or
?y. e uniﬁcation doesn’t fail, since it is certainly possible to make the
two paerns equal by assigning values to ?x and ?y. Since this match
in no way restricts the values ?y can take on, no binding for ?y is put
into the result frame. e match does, however, restrict the value of ?x.
Whatever value ?y has, ?x must be (b ?y). A binding of ?x to the paern
(b ?y) is thus put into the frame. If a value for ?y is later determined and
added to the frame (by a paern match or uniﬁcation that is required
to be consistent with this frame), the previously bound ?x will refer to
this value.72
72Another way to think of uniﬁcation is that it generates the most general paern
623
Applying rules
Uniﬁcation is the key to the component of the query system that makes
inferences from rules. To see how this is accomplished, consider pro
cessing a query that involves applying a rule, such as
(livesnear ?x (Hacker Alyssa P))
To process this query, we ﬁrst use the ordinary paernmatch procedure
described above to see if there are any assertions in the data base that
match this paern. (ere will not be any in this case, since our data base
includes no direct assertions about who lives near whom.) e next step
is to aempt to unify the query paern with the conclusion of each rule.
We ﬁnd that the paern uniﬁes with the conclusion of the rule
(rule (livesnear ?person1 ?person2)
(and (address ?person1 (?town . ?rest1))
(address ?person2 (?town . ?rest2))
(not (same ?person1 ?person2))))
resulting in a frame specifying that ?person2 is bound to (Hacker
Alyssa P) and that ?x should be bound to (have the same value as)
?person1. Now, relative to this frame, we evaluate the compound query
given by the body of the rule. Successful matches will extend this frame
by providing a binding for ?person1, and consequently a value for ?x,
which we can use to instantiate the original query paern.
In general, the query evaluator uses the following method to apply
a rule when trying to establish a query paern in a frame that speciﬁes
bindings for some of the paern variables:
that is a specialization of the two input paerns. at is, the uniﬁcation of (?x a) and
((b ?y) ?z) is ((b ?y) a), and the uniﬁcation of (?x a ?y) and (?y ?z a), discussed
above, is (a a a). For our implementation, it is more convenient to think of the result
of uniﬁcation as a frame rather than a paern.
624
• Unify the query with the conclusion of the rule to form, if suc
cessful, an extension of the original frame.
• Relative to the extended frame, evaluate the query formed by the
body of the rule.
Notice how similar this is to the method for applying a procedure in the
eval/apply evaluator for Lisp:
• Bind the procedure’s parameters to its arguments to form a frame
that extends the original procedure environment.
• Relative to the extended environment, evaluate the expression
formed by the body of the procedure.
e similarity between the two evaluators should come as no surprise.
Just as procedure deﬁnitions are the means of abstraction in Lisp, rule
deﬁnitions are the means of abstraction in the query language. In each
case, we unwind the abstraction by creating appropriate bindings and
evaluating the rule or procedure body relative to these.
Simple queries
We saw earlier in this section how to evaluate simple queries in the
absence of rules. Now that we have seen how to apply rules, we can
describe how to evaluate simple queries by using both rules and asser
tions.
Given the query paern and a stream of frames, we produce, for
each frame in the input stream, two streams:
• a stream of extended frames obtained by matching the paern
against all assertions in the data base (using the paern matcher),
and
625
• a stream of extended frames obtained by applying all possible
rules (using the uniﬁer).73
Appending these two streams produces a stream that consists of all the
ways that the given paern can be satisﬁed consistent with the original
frame. ese streams (one for each frame in the input stream) are now
all combined to form one large stream, which therefore consists of all
the ways that any of the frames in the original input stream can be
extended to produce a match with the given paern.
The query evaluator and the driver loop
Despite the complexity of the underlying matching operations, the sys
tem is organized much like an evaluator for any language. e proce
dure that coordinates the matching operations is called qeval, and it
plays a role analogous to that of the eval procedure for Lisp. qeval
takes as inputs a query and a stream of frames. Its output is a stream of
frames, corresponding to successful matches to the query paern, that
extend some frame in the input stream, as indicated in Figure 4.4. Like
eval, qeval classiﬁes the diﬀerent types of expressions (queries) and
dispatches to an appropriate procedure for each. ere is a procedure
for each special form (and, or, not, and lispvalue) and one for simple
queries.
e driver loop, which is analogous to the driverloop procedure
for the other evaluators in this chapter, reads queries from the terminal.
For each query, it calls qeval with the query and a stream that consists
73Since uniﬁcation is a generalization of matching, we could simplify the system
by using the uniﬁer to produce both streams. Treating the easy case with the simple
matcher, however, illustrates how matching (as opposed to fullblown uniﬁcation) can
be useful in its own right.
626
of a single empty frame. is will produce the stream of all possible
matches (all possible extensions to the empty frame). For each frame in
the resulting stream, it instantiates the original query using the values
of the variables found in the frame. is stream of instantiated queries
is then printed.74
e driver also checks for the special command assert!, which sig
nals that the input is not a query but rather an assertion or rule to be
added to the data base. For instance,
(assert! (job (Bitdiddle Ben)
(computer wizard)))
(assert! (rule (wheel ?person)
(and (supervisor ?middlemanager ?person)
(supervisor ?x ?middlemanager))))
4.4.3 Is Logic Programming Mathematical Logic?
e means of combination used in the query language may at ﬁrst seem
identical to the operations and, or, and not of mathematical logic, and
the application of querylanguage rules is in fact accomplished through
a legitimate method of inference.75 is identiﬁcation of the query lan
guage with mathematical logic is not really valid, though, because the
74e reason we use streams (rather than lists) of frames is that the recursive appli
cation of rules can generate inﬁnite numbers of values that satisfy a query. e delayed
evaluation embodied in streams is crucial here: e system will print responses one by
one as they are generated, regardless of whether there are a ﬁnite or inﬁnite number
of responses.
75at a particular method of inference is legitimate is not a trivial assertion. One
must prove that if one starts with true premises, only true conclusions can be derived.
e method of inference represented by rule applications is modus ponens, the familiar
method of inference that says that if A is true and A implies B is true, then we may
conclude that B is true.
627
query language provides a control structure that interprets the logical
statements procedurally. We can oen take advantage of this control
structure. For example, to ﬁnd all of the supervisors of programmers
we could formulate a query in either of two logically equivalent forms:
(and (job ?x (computer programmer)) (supervisor ?x ?y))
or
(and (supervisor ?x ?y) (job ?x (computer programmer)))
If a company has many more supervisors than programmers (the usual
case), it is beer to use the ﬁrst form rather than the second because the
data base must be scanned for each intermediate result (frame) produced
by the ﬁrst clause of the and.
e aim of logic programming is to provide the programmer with
techniques for decomposing a computational problem into two separate
problems: “what” is to be computed, and “how” this should be computed.
is is accomplished by selecting a subset of the statements of mathe
matical logic that is powerful enough to be able to describe anything
one might want to compute, yet weak enough to have a controllable
procedural interpretation. e intention here is that, on the one hand, a
program speciﬁed in a logic programming language should be an eﬀec
tive program that can be carried out by a computer. Control (“how” to
compute) is eﬀected by using the order of evaluation of the language.
We should be able to arrange the order of clauses and the order of sub
goals within each clause so that the computation is done in an order
deemed to be eﬀective and eﬃcient. At the same time, we should be
able to view the result of the computation (“what” to compute) as a
simple consequence of the laws of logic.
Our query language can be regarded as just such a procedurally in
terpretable subset of mathematical logic. An assertion represents a sim
628
ple fact (an atomic proposition). A rule represents the implication that
the rule conclusion holds for those cases where the rule body holds. A
rule has a natural procedural interpretation: To establish the conclusion
of the rule, establish the body of the rule. Rules, therefore, specify com
putations. However, because rules can also be regarded as statements
of mathematical logic, we can justify any “inference” accomplished by
a logic program by asserting that the same result could be obtained by
working entirely within mathematical logic.76
Infinite loops
A consequence of the procedural interpretation of logic programs is that
it is possible to construct hopelessly ineﬃcient programs for solving
certain problems. An extreme case of ineﬃciency occurs when the sys
tem falls into inﬁnite loops in making deductions. As a simple example,
suppose we are seing up a data base of famous marriages, including
(assert! (married Minnie Mickey))
If we now ask
(married Mickey ?who)
76We must qualify this statement by agreeing that, in speaking of the “inference”
accomplished by a logic program, we assume that the computation terminates. Unfor
tunately, even this qualiﬁed statement is false for our implementation of the query lan
guage (and also false for programs in Prolog and most other current logic programming
languages) because of our use of not and lispvalue. As we will describe below, the
not implemented in the query language is not always consistent with the not of math
ematical logic, and lispvalue introduces additional complications. We could imple
ment a language consistent with mathematical logic by simply removing not and lisp
value from the language and agreeing to write programs using only simple queries, and,
and or. However, this would greatly restrict the expressive power of the language. One
of the major concerns of research in logic programming is to ﬁnd ways to achieve more
consistency with mathematical logic without unduly sacriﬁcing expressive power.
629
we will get no response, because the system doesn’t know that if A is
married to B, then B is married to A. So we assert the rule
(assert! (rule (married ?x ?y) (married ?y ?x)))
and again query
(married Mickey ?who)
Unfortunately, this will drive the system into an inﬁnite loop, as follows:
• e system ﬁnds that the married rule is applicable; that is, the
rule conclusion (married ?x ?y) successfully uniﬁes with the
query paern (married Mickey ?who) to produce a frame in
which ?x is bound to Mickey and ?y is bound to ?who. So the inter
preter proceeds to evaluate the rule body (married ?y ?x) in this
frame—in eﬀect, to process the query (married ?who Mickey).
• One answer appears directly as an assertion in the data base:
(married Minnie Mickey).
• e married rule is also applicable, so the interpreter again eval
uates the rule body, which this time is equivalent to (married
Mickey ?who).
e system is now in an inﬁnite loop. Indeed, whether the system will
ﬁnd the simple answer (married Minnie Mickey) before it goes into
the loop depends on implementation details concerning the order in
which the system checks the items in the data base. is is a very sim
ple example of the kinds of loops that can occur. Collections of interre
lated rules can lead to loops that are much harder to anticipate, and the
appearance of a loop can depend on the order of clauses in an and (see
630
Exercise 4.64) or on lowlevel details concerning the order in which the
system processes queries.77
Problems with not
Another quirk in the query system concerns not. Given the data base
of Section 4.4.1, consider the following two queries:
(and (supervisor ?x ?y)
(not (job ?x (computer programmer))))
(and (not (job ?x (computer programmer)))
(supervisor ?x ?y))
ese two queries do not produce the same result. e ﬁrst query begins
by ﬁnding all entries in the data base that match (supervisor ?x ?y),
and then ﬁlters the resulting frames by removing the ones in which the
value of ?x satisﬁes (job ?x (computer programmer)). e second
query begins by ﬁltering the incoming frames to remove those that can
satisfy (job ?x (computer programmer)). Since the only incoming
frame is empty, it checks the data base to see if there are any paerns
that satisfy (job ?x (computer programmer)). Since there generally
77is is not a problem of the logic but one of the procedural interpretation of the
logic provided by our interpreter. We could write an interpreter that would not fall
into a loop here. For example, we could enumerate all the proofs derivable from our
assertions and our rules in a breadthﬁrst rather than a depthﬁrst order. However,
such a system makes it more diﬃcult to take advantage of the order of deductions
in our programs. One aempt to build sophisticated control into such a program is
described in deKleer et al. 1977. Another technique, which does not lead to such serious
control problems, is to put in special knowledge, such as detectors for particular kinds of
loops (Exercise 4.67). However, there can be no general scheme for reliably preventing a
system from going down inﬁnite paths in performing deductions. Imagine a diabolical
rule of the form “To show P(x) is true, show that P(f (x)) is true,” for some suitably
chosen function f .
631
are entries of this form, the not clause ﬁlters out the empty frame and
returns an empty stream of frames. Consequently, the entire compound
query returns an empty stream.
e trouble is that our implementation of not really is meant to
serve as a ﬁlter on values for the variables. If a not clause is processed
with a frame in which some of the variables remain unbound (as does
?x in the example above), the system will produce unexpected results.
Similar problems occur with the use of lispvalue—the Lisp predicate
can’t work if some of its arguments are unbound. See Exercise 4.77.
ere is also a much more serious way in which the not of the query
language diﬀers from the not of mathematical logic. In logic, we inter
pret the statement “not P” to mean that P is not true. In the query sys
tem, however, “not P” means that P is not deducible from the knowledge
in the data base. For example, given the personnel data base of Section
4.4.1, the system would happily deduce all sorts of not statements, such
as that Ben Bitdiddle is not a baseball fan, that it is not raining outside,
and that 2 + 2 is not 4.78 In other words, the not of logic programming
languages reﬂects the socalled closed world assumption that all relevant
information has been included in the data base.79
Exercise 4.64: Louis Reasoner mistakenly deletes the outranked
by rule (Section 4.4.1) from the data base. When he real
izes this, he quickly reinstalls it. Unfortunately, he makes a
slight change in the rule, and types it in as
78Consider the query (not (baseballfan (Bitdiddle Ben))). e system ﬁnds
that (baseballfan (Bitdiddle Ben)) is not in the data base, so the empty frame
does not satisfy the paern and is not ﬁltered out of the initial stream of frames. e
result of the query is thus the empty frame, which is used to instantiate the input query
to produce (not (baseballfan (Bitdiddle Ben))).
79A discussion and justiﬁcation of this treatment of not can be found in the article
by Clark (1978).
632
(rule (outrankedby ?staffperson ?boss)
(or (supervisor ?staffperson ?boss)
(and (outrankedby ?middlemanager ?boss)
(supervisor ?staffperson
?middlemanager))))
Just aer Louis types this information into the system, De
Wi Aull comes by to ﬁnd out who outranks Ben Bitdiddle.
He issues the query
(outrankedby (Bitdiddle Ben) ?who)
Aer answering, the system goes into an inﬁnite loop. Ex
plain why.
Exercise 4.65: Cy D. Fect, looking forward to the day when
he will rise in the organization, gives a query to ﬁnd all the
wheels (using the wheel rule of Section 4.4.1):
(wheel ?who)
To his surprise, the system responds
;;; Query results:
(wheel (Warbucks Oliver))
(wheel (Bitdiddle Ben))
(wheel (Warbucks Oliver))
(wheel (Warbucks Oliver))
(wheel (Warbucks Oliver))
Why is Oliver Warbucks listed four times?
Exercise 4.66: Ben has been generalizing the query sys
tem to provide statistics about the company. For example,
633
to ﬁnd the total salaries of all the computer programmers
one will be able to say
(sum ?amount (and (job ?x (computer programmer))
(salary ?x ?amount)))
In general, Ben’s new system allows expressions of the form
(accumulationfunction ⟨variable⟩ ⟨query pattern⟩)
where accumulationfunction can be things like sum, average,
or maximum. Ben reasons that it should be a cinch to imple
ment this. He will simply feed the query paern to qeval.
is will produce a stream of frames. He will then pass this
stream through a mapping function that extracts the value
of the designated variable from each frame in the stream
and feed the resulting stream of values to the accumulation
function. Just as Ben completes the implementation and is
about to try it out, Cy walks by, still puzzling over the wheel
query result in Exercise 4.65. When Cy shows Ben the sys
tem’s response, Ben groans, “Oh, no, my simple accumula
tion scheme won’t work!”
What has Ben just realized? Outline a method he can use
to salvage the situation.
Exercise 4.67: Devise a way to install a loop detector in the
query system so as to avoid the kinds of simple loops illus
trated in the text and in Exercise 4.64. e general idea is
that the system should maintain some sort of history of its
current chain of deductions and should not begin process
ing a query that it is already working on. Describe what
kind of information (paerns and frames) is included in
634
this history, and how the check should be made. (Aer you
study the details of the querysystem implementation in
Section 4.4.4, you may want to modify the system to in
clude your loop detector.)
Exercise 4.68: Deﬁne rules to implement the reverse op
eration of Exercise 2.18, which returns a list containing the
same elements as a given list in reverse order. (Hint: Use
appendtoform.) Can your rules answer both (reverse
(1 2 3) ?x) and (reverse ?x (1 2 3)) ?
Exercise 4.69: Beginning with the data base and the rules
you formulated in Exercise 4.63, devise a rule for adding
“greats” to a grandson relationship. is should enable the
system to deduce that Irad is the greatgrandson of Adam,
or that Jabal and Jubal are the greatgreatgreatgreatgreat
grandsons of Adam. (Hint: Represent the fact about Irad, for
example, as ((great grandson) Adam Irad). Write rules
that determine if a list ends in the word grandson. Use this
to express a rule that allows one to derive the relationship
((great . ?rel) ?x ?y), where ?rel is a list ending in
grandson.) Check your rules on queries such as ((great
grandson) ?g ?ggs) and (?relationship Adam Irad).
4.4.4 Implementing the ery System
Section 4.4.2 described how the query system works. Now we ﬁll in the
details by presenting a complete implementation of the system.
635
4.4.4.1 The Driver Loop and Instantiation
e driver loop for the query system repeatedly reads input expressions.
If the expression is a rule or assertion to be added to the data base, then
the information is added. Otherwise the expression is assumed to be
a query. e driver passes this query to the evaluator qeval together
with an initial frame stream consisting of a single empty frame. e
result of the evaluation is a stream of frames generated by satisfying
the query with variable values found in the data base. ese frames are
used to form a new stream consisting of copies of the original query in
which the variables are instantiated with values supplied by the stream
of frames, and this ﬁnal stream is printed at the terminal:
(define inputprompt ";;; Query input:")
(define outputprompt ";;; Query results:")
(define (querydriverloop)
(promptforinput inputprompt)
(let ((q (querysyntaxprocess (read))))
(cond ((assertiontobeadded? q)
(addruleorassertion! (addassertionbody q))
(newline)
(display "Assertion added to data base.")
(querydriverloop))
(else
(newline)
(display outputprompt)
(displaystream
(streammap
(lambda (frame)
(instantiate
q
frame
636
(lambda (v f)
(contractquestionmark v))))
(qeval q (singletonstream '()))))
(querydriverloop)))))
Here, as in the other evaluators in this chapter, we use an abstract syn
tax for the expressions of the query language. e implementation of the
expression syntax, including the predicate assertiontobeadded?
and the selector addassertionbody, is given in Section 4.4.4.7. add
ruleorassertion! is deﬁned in Section 4.4.4.5.
Before doing any processing on an input expression, the driver loop
transforms it syntactically into a form that makes the processing more
eﬃcient. is involves changing the representation of paern variables.
When the query is instantiated, any variables that remain unbound
are transformed back to the input representation before being printed.
ese transformations are performed by the two procedures query
syntaxprocess and contractquestionmark (Section 4.4.4.7).
To instantiate an expression, we copy it, replacing any variables in
the expression by their values in a given frame. e values are them
selves instantiated, since they could contain variables (for example, if
?x in exp is bound to ?y as the result of uniﬁcation and ?y is in turn
bound to 5). e action to take if a variable cannot be instantiated is
given by a procedural argument to instantiate.
(define (instantiate exp frame unboundvarhandler)
(define (copy exp)
(cond ((var? exp)
(let ((binding (bindinginframe exp frame)))
(if binding
(copy (bindingvalue binding))
(unboundvarhandler exp frame))))
((pair? exp)
637
(cons (copy (car exp)) (copy (cdr exp))))
(else exp)))
(copy exp))
e procedures that manipulate bindings are deﬁned in Section 4.4.4.8.
4.4.4.2 The Evaluator
e qeval procedure, called by the querydriverloop, is the basic
evaluator of the query system. It takes as inputs a query and a stream of
frames, and it returns a stream of extended frames. It identiﬁes special
forms by a datadirected dispatch using get and put, just as we did in
implementing generic operations in Chapter 2. Any query that is not
identiﬁed as a special form is assumed to be a simple query, to be pro
cessed by simplequery.
(define (qeval query framestream)
(let ((qproc (get (type query) 'qeval)))
(if qproc
(qproc (contents query) framestream)
(simplequery query framestream))))
type and contents, deﬁned in Section 4.4.4.7, implement the abstract
syntax of the special forms.
Simple queries
e simplequery procedure handles simple queries. It takes as argu
ments a simple query (a paern) together with a stream of frames, and
it returns the stream formed by extending each frame by all database
matches of the query.
(define (simplequery querypattern framestream)
(streamflatmap
638
(lambda (frame)
(streamappenddelayed
(findassertions querypattern frame)
(delay (applyrules querypattern frame))))
framestream))
For each frame in the input stream, we use findassertions (Section
4.4.4.3) to match the paern against all assertions in the data base, pro
ducing a stream of extended frames, and we use applyrules (Sec
tion 4.4.4.4) to apply all possible rules, producing another stream of ex
tended frames. ese two streams are combined (using streamappend
delayed, Section 4.4.4.6) to make a stream of all the ways that the given
paern can be satisﬁed consistent with the original frame (see Exer
cise 4.71). e streams for the individual input frames are combined us
ing streamflatmap (Section 4.4.4.6) to form one large stream of all the
ways that any of the frames in the original input stream can be extended
to produce a match with the given paern.
Compound queries
and queries are handled as illustrated in Figure 4.5 by the conjoin pro
cedure. conjoin takes as inputs the conjuncts and the frame stream
and returns the stream of extended frames. First, conjoin processes the
stream of frames to ﬁnd the stream of all possible frame extensions that
satisfy the ﬁrst query in the conjunction. en, using this as the new
frame stream, it recursively applies conjoin to the rest of the queries.
(define (conjoin conjuncts framestream)
(if (emptyconjunction? conjuncts)
framestream
(conjoin (restconjuncts conjuncts)
(qeval (firstconjunct conjuncts) framestream))))
639
e expression
(put 'and 'qeval conjoin)
sets up qeval to dispatch to conjoin when an and form is encountered.
or queries are handled similarly, as shown in Figure 4.6. e output
streams for the various disjuncts of the or are computed separately and
merged using the interleavedelayed procedure from Section 4.4.4.6.
(See Exercise 4.71 and Exercise 4.72.)
(define (disjoin disjuncts framestream)
(if (emptydisjunction? disjuncts)
theemptystream
(interleavedelayed
(qeval (firstdisjunct disjuncts) framestream)
(delay (disjoin (restdisjuncts disjuncts) framestream)))))
(put 'or 'qeval disjoin)
e predicates and selectors for the syntax of conjuncts and disjuncts
are given in Section 4.4.4.7.
Filters
not is handled by the method outlined in Section 4.4.2. We aempt to ex
tend each frame in the input stream to satisfy the query being negated,
and we include a given frame in the output stream only if it cannot be
extended.
(define (negate operands framestream)
(streamflatmap
(lambda (frame)
(if (streamnull?
(qeval (negatedquery operands)
(singletonstream frame)))
(singletonstream frame)
640
theemptystream))
framestream))
(put 'not 'qeval negate)
lispvalue is a ﬁlter similar to not. Each frame in the stream is used
to instantiate the variables in the paern, the indicated predicate is ap
plied, and the frames for which the predicate returns false are ﬁltered
out of the input stream. An error results if there are unbound paern
variables.
(define (lispvalue call framestream)
(streamflatmap
(lambda (frame)
(if (execute
(instantiate
call
frame
(lambda (v f)
(error "Unknown pat var: LISPVALUE" v))))
(singletonstream frame)
theemptystream))
framestream))
(put 'lispvalue 'qeval lispvalue)
execute, which applies the predicate to the arguments, must eval the
predicate expression to get the procedure to apply. However, it must not
evaluate the arguments, since they are already the actual arguments,
not expressions whose evaluation (in Lisp) will produce the arguments.
Note that execute is implemented using eval and apply from the un
derlying Lisp system.
(define (execute exp)
(apply (eval (predicate exp) userinitialenvironment)
(args exp)))
641
e alwaystrue special form provides for a query that is always satis
ﬁed. It ignores its contents (normally empty) and simply passes through
all the frames in the input stream. alwaystrue is used by the rule
body selector (Section 4.4.4.7) to provide bodies for rules that were de
ﬁned without bodies (that is, rules whose conclusions are always satis
ﬁed).
(define (alwaystrue ignore framestream) framestream)
(put 'alwaystrue 'qeval alwaystrue)
e selectors that deﬁne the syntax of not and lispvalue are given in
Section 4.4.4.7.
4.4.4.3 Finding Assertions
by Paern Matching
findassertions, called by simplequery (Section 4.4.4.2), takes as in
put a paern and a frame. It returns a stream of frames, each extending
the given one by a database match of the given paern. It uses fetch
assertions (Section 4.4.4.5) to get a stream of all the assertions in the
data base that should be checked for a match against the paern and the
frame. e reason for fetchassertions here is that we can oen ap
ply simple tests that will eliminate many of the entries in the data base
from the pool of candidates for a successful match. e system would
still work if we eliminated fetchassertions and simply checked a
stream of all assertions in the data base, but the computation would be
less eﬃcient because we would need to make many more calls to the
matcher.
(define (findassertions pattern frame)
(streamflatmap
(lambda (datum) (checkanassertion datum pattern frame))
(fetchassertions pattern frame)))
642
checkanassertion takes as arguments a paern, a data object (asser
tion), and a frame and returns either a oneelement stream containing
the extended frame or theemptystream if the match fails.
(define (checkanassertion assertion querypat queryframe)
(let ((matchresult
(patternmatch querypat assertion queryframe)))
(if (eq? matchresult 'failed)
theemptystream
(singletonstream matchresult))))
e basic paern matcher returns either the symbol failed or an ex
tension of the given frame. e basic idea of the matcher is to check the
paern against the data, element by element, accumulating bindings for
the paern variables. If the paern and the data object are the same, the
match succeeds and we return the frame of bindings accumulated so far.
Otherwise, if the paern is a variable we extend the current frame by
binding the variable to the data, so long as this is consistent with the
bindings already in the frame. If the paern and the data are both pairs,
we (recursively) match the car of the paern against the car of the data
to produce a frame; in this frame we then match the cdr of the paern
against the cdr of the data. If none of these cases are applicable, the
match fails and we return the symbol failed.
(define (patternmatch pat dat frame)
(cond ((eq? frame 'failed) 'failed)
((equal? pat dat) frame)
((var? pat) (extendifconsistent pat dat frame))
((and (pair? pat) (pair? dat))
(patternmatch
(cdr pat)
(cdr dat)
(patternmatch (car pat) (car dat) frame)))
643
(else 'failed)))
Here is the procedure that extends a frame by adding a new binding, if
this is consistent with the bindings already in the frame:
(define (extendifconsistent var dat frame)
(let ((binding (bindinginframe var frame)))
(if binding
(patternmatch (bindingvalue binding) dat frame)
(extend var dat frame))))
If there is no binding for the variable in the frame, we simply add the
binding of the variable to the data. Otherwise we match, in the frame,
the data against the value of the variable in the frame. If the stored
value contains only constants, as it must if it was stored during pat
tern matching by extendifconsistent, then the match simply tests
whether the stored and new values are the same. If so, it returns the un
modiﬁed frame; if not, it returns a failure indication. e stored value
may, however, contain paern variables if it was stored during uniﬁ
cation (see Section 4.4.4.4). e recursive match of the stored paern
against the new data will add or check bindings for the variables in this
paern. For example, suppose we have a frame in which ?x is bound
to (f ?y) and ?y is unbound, and we wish to augment this frame by
a binding of ?x to (f b). We look up ?x and ﬁnd that it is bound to
(f ?y). is leads us to match (f ?y) against the proposed new value
(f b) in the same frame. Eventually this match extends the frame by
adding a binding of ?y to b. ?X remains bound to (f ?y). We never
modify a stored binding and we never store more than one binding for
a given variable.
e procedures used by extendifconsistent to manipulate bind
ings are deﬁned in Section 4.4.4.8.
644
Paerns with doed tails
If a paern contains a dot followed by a paern variable, the paern
variable matches the rest of the data list (rather than the next element
of the data list), just as one would expect with the doedtail notation
described in Exercise 2.20. Although the paern matcher we have just
implemented doesn’t look for dots, it does behave as we want. is is
because the Lisp read primitive, which is used by querydriverloop
to read the query and represent it as a list structure, treats dots in a
special way.
When read sees a dot, instead of making the next item be the next
element of a list (the car of a cons whose cdr will be the rest of the list)
it makes the next item be the cdr of the list structure. For example, the
list structure produced by read for the paern (computer ?type) could
be constructed by evaluating the expression (cons 'computer (cons
'?type '())), and that for (computer . ?type) could be constructed
by evaluating the expression (cons 'computer '?type).
us, as patternmatch recursively compares cars and cdrs of a
data list and a paern that had a dot, it eventually matches the variable
aer the dot (which is a cdr of the paern) against a sublist of the data
list, binding the variable to that list. For example, matching the paern
(computer . ?type) against (computer programmer trainee) will
match ?type against the list (programmer trainee).
4.4.4.4 Rules and Unification
applyrules is the rule analog of findassertions (Section 4.4.4.3).
It takes as input a paern and a frame, and it forms a stream of exten
sion frames by applying rules from the data base. streamflatmap maps
applyarule down the stream of possibly applicable rules (selected
645
by fetchrules, Section 4.4.4.5) and combines the resulting streams of
frames.
(define (applyrules pattern frame)
(streamflatmap (lambda (rule)
(applyarule rule pattern frame))
(fetchrules pattern frame)))
applyarule applies rules using the method outlined in Section 4.4.2.
It ﬁrst augments its argument frame by unifying the rule conclusion
with the paern in the given frame. If this succeeds, it evaluates the
rule body in this new frame.
Before any of this happens, however, the program renames all the
variables in the rule with unique new names. e reason for this is to
prevent the variables for diﬀerent rule applications from becoming con
fused with each other. For instance, if two rules both use a variable
named ?x, then each one may add a binding for ?x to the frame when it
is applied. ese two ?x’s have nothing to do with each other, and we
should not be fooled into thinking that the two bindings must be con
sistent. Rather than rename variables, we could devise a more clever
environment structure; however, the renaming approach we have cho
sen here is the most straightforward, even if not the most eﬃcient. (See
Exercise 4.79.) Here is the applyarule procedure:
(define (applyarule rule querypattern queryframe)
(let ((cleanrule (renamevariablesin rule)))
(let ((unifyresult (unifymatch querypattern
(conclusion cleanrule)
queryframe)))
(if (eq? unifyresult 'failed)
theemptystream
(qeval (rulebody cleanrule)
(singletonstream unifyresult))))))
646
e selectors rulebody and conclusion that extract parts of a rule are
deﬁned in Section 4.4.4.7.
We generate unique variable names by associating a unique identi
ﬁer (such as a number) with each rule application and combining this
identiﬁer with the original variable names. For example, if the rule
application identiﬁer is 7, we might change each ?x in the rule to ?x7
and each ?y in the rule to ?y7. (makenewvariable and newrule
applicationid are included with the syntax procedures in Section
4.4.4.7.)
(define (renamevariablesin rule)
(let ((ruleapplicationid (newruleapplicationid)))
(define (treewalk exp)
(cond ((var? exp)
(makenewvariable exp ruleapplicationid))
((pair? exp)
(cons (treewalk (car exp))
(treewalk (cdr exp))))
(else exp)))
(treewalk rule)))
e uniﬁcation algorithm is implemented as a procedure that takes as
inputs two paerns and a frame and returns either the extended frame
or the symbol failed. e uniﬁer is like the paern matcher except
that it is symmetrical—variables are allowed on both sides of the match.
unifymatch is basically the same as patternmatch, except that there
is extra code (marked “***” below) to handle the case where the object
on the right side of the match is a variable.
(define (unifymatch p1 p2 frame)
(cond ((eq? frame 'failed) 'failed)
((equal? p1 p2) frame)
((var? p1) (extendifpossible p1 p2 frame))
647
; ***
((var? p2) (extendifpossible p2 p1 frame))
((and (pair? p1) (pair? p2))
(unifymatch (cdr p1)
(cdr p2)
(unifymatch (car p1)
(car p2)
frame)))
(else 'failed)))
In uniﬁcation, as in onesided paern matching, we want to accept a
proposed extension of the frame only if it is consistent with existing
bindings. e procedure extendifpossible used in uniﬁcation is the
same as the extendifconsistent used in paern matching except for
two special checks, marked “***” in the program below. In the ﬁrst case,
if the variable we are trying to match is not bound, but the value we are
trying to match it with is itself a (diﬀerent) variable, it is necessary to
check to see if the value is bound, and if so, to match its value. If both
parties to the match are unbound, we may bind either to the other.
e second check deals with aempts to bind a variable to a pat
tern that includes that variable. Such a situation can occur whenever a
variable is repeated in both paerns. Consider, for example, unifying
the two paerns (?x ?x) and (?y ⟨expression involving ?y⟩) in a
frame where both ?x and ?y are unbound. First ?x is matched against
?y, making a binding of ?x to ?y. Next, the same ?x is matched against
the given expression involving ?y. Since ?x is already bound to ?y, this
results in matching ?y against the expression. If we think of the uniﬁer
as ﬁnding a set of values for the paern variables that make the paerns
the same, then these paerns imply instructions to ﬁnd a ?y such that
?y is equal to the expression involving ?y. ere is no general method
for solving such equations, so we reject such bindings; these cases are
648
recognized by the predicate dependson?.80 On the other hand, we do
not want to reject aempts to bind a variable to itself. For example, con
sider unifying (?x ?x) and (?y ?y). e second aempt to bind ?x to
?y matches ?y (the stored value of ?x) against ?y (the new value of ?x).
is is taken care of by the equal? clause of unifymatch.
(define (extendifpossible var val frame)
(let ((binding (bindinginframe var frame)))
(cond (binding
80In general, unifying ?y with an expression involving ?y would require our being
able to ﬁnd a ﬁxed point of the equation ?y = ⟨expression involving ?y⟩. It is sometimes
possible to syntactically form an expression that appears to be the solution. For exam
ple, ?y = (f ?y) seems to have the ﬁxed point (f (f (f : : : ))), which we can produce
by beginning with the expression (f ?y) and repeatedly substituting (f ?y) for ?y.
Unfortunately, not every such equation has a meaningful ﬁxed point. e issues that
arise here are similar to the issues of manipulating inﬁnite series in mathematics. For
example, we know that 2 is the solution to the equation y = 1 + y=2. Beginning with
the expression 1 + y=2 and repeatedly substituting 1 + y=2 for y gives
(
)
1 +
y
2
= 1 +
1
2
+
y
4
= : : : ;
which leads to
2 = y = 1 +
y
2
= 1 +
2 = 1 +
1
2
1
2
+
1
4
+
1
8
+ : : : :
However, if we try the same manipulation beginning with the observation that 1 is the
solution to the equation y = 1 + 2y, we obtain
(cid:0)1 = y = 1 + 2y = 1 + 2(1 + 2y) = 1 + 2 + 4y = : : : ;
which leads to
(cid:0)1 = 1 + 2 + 4 + 8 + : : : :
Although the formal manipulations used in deriving these two equations are identical,
the ﬁrst result is a valid assertion about inﬁnite series but the second is not. Similarly, for
our uniﬁcation results, reasoning with an arbitrary syntactically constructed expression
may lead to errors.
649
(unifymatch (bindingvalue binding) val frame))
((var? val)
(let ((binding (bindinginframe val frame)))
; ***
(if binding
(unifymatch
var (bindingvalue binding) frame)
(extend var val frame))))
((dependson? val var frame)
'failed)
(else (extend var val frame)))))
; ***
dependson? is a predicate that tests whether an expression proposed
to be the value of a paern variable depends on the variable. is must
be done relative to the current frame because the expression may con
tain occurrences of a variable that already has a value that depends on
our test variable. e structure of dependson? is a simple recursive
tree walk in which we substitute for the values of variables whenever
necessary.
(define (dependson? exp var frame)
(define (treewalk e)
(cond ((var? e)
(if (equal? var e)
true
(let ((b (bindinginframe e frame)))
(if b
(treewalk (bindingvalue b))
false))))
((pair? e)
(or (treewalk (car e))
(treewalk (cdr e))))
(else false)))
(treewalk exp))
650
4.4.4.5 Maintaining the Data Base
One important problem in designing logic programming languages is
that of arranging things so that as few irrelevant database entries as
possible will be examined in checking a given paern. In our system, in
addition to storing all assertions in one big stream, we store all asser
tions whose cars are constant symbols in separate streams, in a table
indexed by the symbol. To fetch an assertion that may match a paern,
we ﬁrst check to see if the car of the paern is a constant symbol. If
so, we return (to be tested using the matcher) all the stored assertions
that have the same car. If the paern’s car is not a constant symbol,
we return all the stored assertions. Cleverer methods could also take
advantage of information in the frame, or try also to optimize the case
where the car of the paern is not a constant symbol. We avoid build
ing our criteria for indexing (using the car, handling only the case of
constant symbols) into the program; instead we call on predicates and
selectors that embody our criteria.
(define THEASSERTIONS theemptystream)
(define (fetchassertions pattern frame)
(if (useindex? pattern)
(getindexedassertions pattern)
(getallassertions)))
(define (getallassertions) THEASSERTIONS)
(define (getindexedassertions pattern)
(getstream (indexkeyof pattern) 'assertionstream))
getstream looks up a stream in the table and returns an empty stream
if nothing is stored there.
(define (getstream key1 key2)
(let ((s (get key1 key2)))
(if s s theemptystream)))
651
Rules are stored similarly, using the car of the rule conclusion. Rule
conclusions are arbitrary paerns, however, so they diﬀer from asser
tions in that they can contain variables. A paern whose car is a con
stant symbol can match rules whose conclusions start with a variable as
well as rules whose conclusions have the same car. us, when fetch
ing rules that might match a paern whose car is a constant symbol we
fetch all rules whose conclusions start with a variable as well as those
whose conclusions have the same car as the paern. For this purpose
we store all rules whose conclusions start with a variable in a separate
stream in our table, indexed by the symbol ?.
(define THERULES theemptystream)
(define (fetchrules pattern frame)
(if (useindex? pattern)
(getindexedrules pattern)
(getallrules)))
(define (getallrules) THERULES)
(define (getindexedrules pattern)
(streamappend
(getstream (indexkeyof pattern) 'rulestream)
(getstream '? 'rulestream)))
addruleorassertion! is used by querydriverloop to add asser
tions and rules to the data base. Each item is stored in the index, if ap
propriate, and in a stream of all assertions or rules in the data base.
(define (addruleorassertion! assertion)
(if (rule? assertion)
(addrule! assertion)
(addassertion! assertion)))
(define (addassertion! assertion)
(storeassertioninindex assertion)
(let ((oldassertions THEASSERTIONS))
652
(set! THEASSERTIONS
(consstream assertion oldassertions))
'ok))
(define (addrule! rule)
(storeruleinindex rule)
(let ((oldrules THERULES))
(set! THERULES (consstream rule oldrules))
'ok))
To actually store an assertion or a rule, we check to see if it can be
indexed. If so, we store it in the appropriate stream.
(define (storeassertioninindex assertion)
(if (indexable? assertion)
(let ((key (indexkeyof assertion)))
(let ((currentassertionstream
(getstream key 'assertionstream)))
(put key
'assertionstream
(consstream
assertion
currentassertionstream))))))
(define (storeruleinindex rule)
(let ((pattern (conclusion rule)))
(if (indexable? pattern)
(let ((key (indexkeyof pattern)))
(let ((currentrulestream
(getstream key 'rulestream)))
(put key
'rulestream
(consstream rule
currentrulestream)))))))
e following procedures deﬁne how the database index is used. A pat
tern (an assertion or a rule conclusion) will be stored in the table if it
653
starts with a variable or a constant symbol.
(define (indexable? pat)
(or (constantsymbol? (car pat))
(var? (car pat))))
e key under which a paern is stored in the table is either ? (if it starts
with a variable) or the constant symbol with which it starts.
(define (indexkeyof pat)
(let ((key (car pat)))
(if (var? key) '? key)))
e index will be used to retrieve items that might match a paern if
the paern starts with a constant symbol.
(define (useindex? pat) (constantsymbol? (car pat)))
Exercise 4.70: What is the purpose of the let bindings
in the procedures addassertion! and addrule! ? What
would be wrong with the following implementation of add
assertion! ? Hint: Recall the deﬁnition of the inﬁnite stream
of ones in Section 3.5.2: (define ones (consstream 1
ones)).
(define (addassertion! assertion)
(storeassertioninindex assertion)
(set! THEASSERTIONS
(consstream assertion THEASSERTIONS))
'ok)
4.4.4.6 Stream Operations
e query system uses a few stream operations that were not presented
in Chapter 3.
654
streamappenddelayed and interleavedelayed are just like stream
append and interleave (Section 3.5.3), except that they take a delayed
argument (like the integral procedure in Section 3.5.4). is postpones
looping in some cases (see Exercise 4.71).
(define (streamappenddelayed s1 delayeds2)
(if (streamnull? s1)
(force delayeds2)
(consstream
(streamcar s1)
(streamappenddelayed
(streamcdr s1)
delayeds2))))
(define (interleavedelayed s1 delayeds2)
(if (streamnull? s1)
(force delayeds2)
(consstream
(streamcar s1)
(interleavedelayed
(force delayeds2)
(delay (streamcdr s1))))))
streamflatmap, which is used throughout the query evaluator to map
a procedure over a stream of frames and combine the resulting streams
of frames, is the stream analog of the flatmap procedure introduced
for ordinary lists in Section 2.2.3. Unlike ordinary flatmap, however,
we accumulate the streams with an interleaving process, rather than
simply appending them (see Exercise 4.72 and Exercise 4.73).
(define (streamflatmap proc s)
(flattenstream (streammap proc s)))
(define (flattenstream stream)
(if (streamnull? stream)
655
theemptystream
(interleavedelayed
(streamcar stream)
(delay (flattenstream (streamcdr stream))))))
e evaluator also uses the following simple procedure to generate a
stream consisting of a single element:
(define (singletonstream x)
(consstream x theemptystream))
4.4.4.7 ery Syntax Procedures
type and contents, used by qeval (Section 4.4.4.2), specify that a special
form is identiﬁed by the symbol in its car. ey are the same as the
typetag and contents procedures in Section 2.4.2, except for the error
message.
(define (type exp)
(if (pair? exp)
(car exp)
(error "Unknown expression TYPE" exp)))
(define (contents exp)
(if (pair? exp)
(cdr exp)
(error "Unknown expression CONTENTS" exp)))
e following procedures, used by querydriverloop (in Section 4.4.4.1),
specify that rules and assertions are added to the data base by expres
sions of the form (assert! ⟨ruleorassertion⟩):
(define (assertiontobeadded? exp)
(eq? (type exp) 'assert!))
(define (addassertionbody exp) (car (contents exp)))
656
Here are the syntax deﬁnitions for the and, or, not, and lispvalue
special forms (Section 4.4.4.2):
(define (emptyconjunction? exps) (null? exps))
(define (firstconjunct exps) (car exps))
(define (restconjuncts exps) (cdr exps))
(define (emptydisjunction? exps) (null? exps))
(define (firstdisjunct exps) (car exps))
(define (restdisjuncts exps) (cdr exps))
(define (negatedquery exps) (car exps))
(define (predicate exps) (car exps))
(define (args exps) (cdr exps))
e following three procedures deﬁne the syntax of rules:
(define (rule? statement)
(taggedlist? statement 'rule))
(define (conclusion rule) (cadr rule))
(define (rulebody rule)
(if (null? (cddr rule)) '(alwaystrue) (caddr rule)))
querydriverloop (Section 4.4.4.1) calls querysyntaxprocess to trans
form paern variables in the expression, which have the form ?symbol,
into the internal format (? symbol). at is to say, a paern such as
(job ?x ?y) is actually represented internally by the system as (job
(? x) (? y)). is increases the eﬃciency of query processing, since
it means that the system can check to see if an expression is a paern
variable by checking whether the car of the expression is the symbol
?, rather than having to extract characters from the symbol. e syntax
transformation is accomplished by the following procedure:81
81Most Lisp systems give the user the ability to modify the ordinary read pro
cedure to perform such transformations by deﬁning reader macro characters. oted
expressions are already handled in this way: e reader automatically translates
657
(define (querysyntaxprocess exp)
(mapoversymbols expandquestionmark exp))
(define (mapoversymbols proc exp)
(cond ((pair? exp)
(cons (mapoversymbols proc (car exp))
(mapoversymbols proc (cdr exp))))
((symbol? exp) (proc exp))
(else exp)))
(define (expandquestionmark symbol)
(let ((chars (symbol>string symbol)))
(if (string=? (substring chars 0 1) "?")
(list '?
(string>symbol
(substring chars 1 (stringlength chars))))
symbol)))
Once the variables are transformed in this way, the variables in a paern
are lists starting with ?, and the constant symbols (which need to be
recognized for database indexing, Section 4.4.4.5) are just the symbols.
(define (var? exp) (taggedlist? exp '?))
(define (constantsymbol? exp) (symbol? exp))
Unique variables are constructed during rule application (in Section
4.4.4.4) by means of the following procedures. e unique identiﬁer for
a rule application is a number, which is incremented each time a rule is
applied.
(define rulecounter 0)
'expression into (quote expression) before the evaluator sees it. We could arrange
for ?expression to be transformed into (? expression) in the same way; however,
for the sake of clarity we have included the transformation procedure here explicitly.
expandquestionmark and contractquestionmark use several procedures with
string in their names. ese are Scheme primitives.
658
(define (newruleapplicationid)
(set! rulecounter (+ 1 rulecounter))
rulecounter)
(define (makenewvariable var ruleapplicationid)
(cons '? (cons ruleapplicationid (cdr var))))
When querydriverloop instantiates the query to print the answer,
it converts any unbound paern variables back to the right form for
printing, using
(define (contractquestionmark variable)
(string>symbol
(stringappend "?"
(if (number? (cadr variable))
(stringappend (symbol>string (caddr variable))
""
(number>string (cadr variable)))
(symbol>string (cadr variable))))))
4.4.4.8 Frames and Bindings
Frames are represented as lists of bindings, which are variablevalue
pairs:
(define (makebinding variable value)
(cons variable value))
(define (bindingvariable binding) (car binding))
(define (bindingvalue binding) (cdr binding))
(define (bindinginframe variable frame)
(assoc variable frame))
(define (extend variable value frame)
(cons (makebinding variable value) frame))
659
Exercise 4.71: Louis Reasoner wonders why the simple
query and disjoin procedures (Section 4.4.4.2) are imple
mented using explicit delay operations, rather than being
deﬁned as follows:
(define (simplequery querypattern framestream)
(streamflatmap
(lambda (frame)
(streamappend
(findassertions querypattern frame)
(applyrules querypattern frame)))
framestream))
(define (disjoin disjuncts framestream)
(if (emptydisjunction? disjuncts)
theemptystream
(interleave
(qeval (firstdisjunct disjuncts)
framestream)
(disjoin (restdisjuncts disjuncts)
framestream))))
Can you give examples of queries where these simpler def
initions would lead to undesirable behavior?
Exercise 4.72: Why do disjoin and streamflatmap in
terleave the streams rather than simply append them? Give
examples that illustrate why interleaving works beer. (Hint:
Why did we use interleave in Section 3.5.3?)
Exercise 4.73: Why does flattenstream use delay ex
plicitly? What would be wrong with deﬁning it as follows:
(define (flattenstream stream)
660
(if (streamnull? stream)
theemptystream
(interleave
(streamcar stream)
(flattenstream (streamcdr stream)))))
Exercise 4.74: Alyssa P. Hacker proposes to use a sim
pler version of streamflatmap in negate, lispvalue,
and findassertions. She observes that the procedure that
is mapped over the frame stream in these cases always pro
duces either the empty stream or a singleton stream, so no
interleaving is needed when combining these streams.
a. Fill in the missing expressions in Alyssa’s program.
(define (simplestreamflatmap proc s)
(simpleflatten (streammap proc s)))
(define (simpleflatten stream)
(streammap ⟨??⟩
(streamfilter ⟨??⟩ stream)))
b. Does the query system’s behavior change if we change
it in this way?
Exercise 4.75: Implement for the query language a new
special form called unique. unique should succeed if there
is precisely one item in the data base satisfying a speciﬁed
query. For example,
(unique (job ?x (computer wizard)))
should print the oneitem stream
(unique (job (Bitdiddle Ben) (computer wizard)))
661
since Ben is the only computer wizard, and
(unique (job ?x (computer programmer)))
should print the empty stream, since there is more than one
computer programmer. Moreover,
(and (job ?x ?j) (unique (job ?anyone ?j)))
should list all the jobs that are ﬁlled by only one person,
and the people who ﬁll them.
ere are two parts to implementing unique. e ﬁrst is to
write a procedure that handles this special form, and the
second is to make qeval dispatch to that procedure. e
second part is trivial, since qeval does its dispatching in
a datadirected way. If your procedure is called uniquely
asserted, all you need to do is
(put 'unique 'qeval uniquelyasserted)
and qeval will dispatch to this procedure for every query
whose type (car) is the symbol unique.
e real problem is to write the procedure uniquelyasserted.
is should take as input the contents (cdr) of the unique
query, together with a stream of frames. For each frame
in the stream, it should use qeval to ﬁnd the stream of all
extensions to the frame that satisfy the given query. Any
stream that does not have exactly one item in it should be
eliminated. e remaining streams should be passed back
to be accumulated into one big stream that is the result of
the unique query. is is similar to the implementation of
the not special form.
662
Test your implementation by forming a query that lists all
people who supervise precisely one person.
Exercise 4.76: Our implementation of and as a series com
bination of queries (Figure 4.5) is elegant, but it is ineﬃ
cient because in processing the second query of the and we
must scan the data base for each frame produced by the
ﬁrst query. If the data base has n elements, and a typical
query produces a number of output frames proportional to
n (say n=k), then scanning the data base for each frame pro
duced by the ﬁrst query will require n2=k calls to the paern
matcher. Another approach would be to process the two
clauses of the and separately, then look for all pairs of out
put frames that are compatible. If each query produces n=k
output frames, then this means that we must perform n2=k2
compatibility checks—a factor of k fewer than the number
of matches required in our current method.
Devise an implementation of and that uses this strategy.
You must implement a procedure that takes two frames as
inputs, checks whether the bindings in the frames are com
patible, and, if so, produces a frame that merges the two
sets of bindings. is operation is similar to uniﬁcation.
Exercise 4.77: In Section 4.4.3 we saw that not and lisp
value can cause the query language to give “wrong” an
swers if these ﬁltering operations are applied to frames in
which variables are unbound. Devise a way to ﬁx this short
coming. One idea is to perform the ﬁltering in a “delayed”
manner by appending to the frame a “promise” to ﬁlter that
is fulﬁlled only when enough variables have been bound
663
to make the operation possible. We could wait to perform
ﬁltering until all other operations have been performed.
However, for eﬃciency’s sake, we would like to perform
ﬁltering as soon as possible so as to cut down on the num
ber of intermediate frames generated.
Exercise 4.78: Redesign the query language as a nonde
terministic program to be implemented using the evalua
tor of Section 4.3, rather than as a stream process. In this
approach, each query will produce a single answer (rather
than the stream of all answers) and the user can type try
again to see more answers. You should ﬁnd that much of
the mechanism we built in this section is subsumed by non
deterministic search and backtracking. You will probably
also ﬁnd, however, that your new query language has sub
tle diﬀerences in behavior from the one implemented here.
Can you ﬁnd examples that illustrate this diﬀerence?
Exercise 4.79: When we implemented the Lisp evaluator in
Section 4.1, we saw how to use local environments to avoid
name conﬂicts between the parameters of procedures. For
example, in evaluating
(define (square x) (* x x))
(define (sumofsquares x y)
(+ (square x) (square y)))
(sumofsquares 3 4)
there is no confusion between the x in square and the x
in sumofsquares, because we evaluate the body of each
procedure in an environment that is specially constructed
664
to contain bindings for the local variables. In the query sys
tem, we used a diﬀerent strategy to avoid name conﬂicts in
applying rules. Each time we apply a rule we rename the
variables with new names that are guaranteed to be unique.
e analogous strategy for the Lisp evaluator would be to
do away with local environments and simply rename the
variables in the body of a procedure each time we apply
the procedure.
Implement for the query language a ruleapplication method
that uses environments rather than renaming. See if you
can build on your environment structure to create constructs
in the query language for dealing with large systems, such
as the rule analog of blockstructured procedures. Can you
relate any of this to the problem of making deductions in a
context (e.g., “If I supposed that P were true, then I would be
able to deduce A and B.”) as a method of problem solving?
(is problem is openended. A good answer is probably
worth a Ph.D.)
665
Computing with Register Machines
My aim is to show that the heavenly machine is not a kind
of divine, live being, but a kind of clockwork (and he who
believes that a clock has soul aributes the maker’s glory
to the work), insofar as nearly all the manifold motions are
caused by a most simple and material force, just as all mo
tions of the clock are caused by a single weight.
—Johannes Kepler (leer to Herwart von Hohenburg, 1605)
W by studying processes and by describing pro
cesses in terms of procedures wrien in Lisp. To explain the mean
ings of these procedures, we used a succession of models of evaluation:
the substitution model of Chapter 1, the environment model of Chap
ter 3, and the metacircular evaluator of Chapter 4. Our examination of
the metacircular evaluator, in particular, dispelled much of the mys
tery of how Lisplike languages are interpreted. But even the metacir
666
cular evaluator leaves important questions unanswered, because it fails
to elucidate the mechanisms of control in a Lisp system. For instance,
the evaluator does not explain how the evaluation of a subexpression
manages to return a value to the expression that uses this value, nor
does the evaluator explain how some recursive procedures generate it
erative processes (that is, are evaluated using constant space) whereas
other recursive procedures generate recursive processes. ese ques
tions remain unanswered because the metacircular evaluator is itself a
Lisp program and hence inherits the control structure of the underlying
Lisp system. In order to provide a more complete description of the con
trol structure of the Lisp evaluator, we must work at a more primitive
level than Lisp itself.
In this chapter we will describe processes in terms of the stepby
step operation of a traditional computer. Such a computer, or register
machine, sequentially executes instructions that manipulate the contents
of a ﬁxed set of storage elements called registers. A typical register
machine instruction applies a primitive operation to the contents of
some registers and assigns the result to another register. Our descrip
tions of processes executed by register machines will look very much
like “machinelanguage” programs for traditional computers. However,
instead of focusing on the machine language of any particular com
puter, we will examine several Lisp procedures and design a speciﬁc
register machine to execute each procedure. us, we will approach our
task from the perspective of a hardware architect rather than that of
a machinelanguage computer programmer. In designing register ma
chines, we will develop mechanisms for implementing important pro
gramming constructs such as recursion. We will also present a language
for describing designs for register machines. In Section 5.2 we will im
plement a Lisp program that uses these descriptions to simulate the ma
667
chines we design.
Most of the primitive operations of our register machines are very
simple. For example, an operation might add the numbers fetched from
two registers, producing a result to be stored into a third register. Such
an operation can be performed by easily described hardware. In order
to deal with list structure, however, we will also use the memory opera
tions car, cdr, and cons, which require an elaborate storageallocation
mechanism. In Section 5.3 we study their implementation in terms of
more elementary operations.
In Section 5.4, aer we have accumulated experience formulating
simple procedures as register machines, we will design a machine that
carries out the algorithm described by the metacircular evaluator of Sec
tion 4.1. is will ﬁll in the gap in our understanding of how Scheme ex
pressions are interpreted, by providing an explicit model for the mech
anisms of control in the evaluator. In Section 5.5 we will study a simple
compiler that translates Scheme programs into sequences of instruc
tions that can be executed directly with the registers and operations of
the evaluator register machine.
5.1 Designing Register Machines
To design a register machine, we must design its data paths (registers
and operations) and the controller that sequences these operations. To
illustrate the design of a simple register machine, let us examine Eu
clid’s Algorithm, which is used to compute the greatest common divi
sor () of two integers. As we saw in Section 1.2.5, Euclid’s Algorithm
can be carried out by an iterative process, as speciﬁed by the following
procedure:
668
(define (gcd a b)
(if (= b 0)
a
(gcd b (remainder a b))))
A machine to carry out this algorithm must keep track of two numbers,
a and b, so let us assume that these numbers are stored in two registers
with those names. e basic operations required are testing whether the
contents of register b is zero and computing the remainder of the con
tents of register a divided by the contents of register b. e remainder
operation is a complex process, but assume for the moment that we have
a primitive device that computes remainders. On each cycle of the
algorithm, the contents of register a must be replaced by the contents
of register b, and the contents of b must be replaced by the remainder
of the old contents of a divided by the old contents of b. It would be
convenient if these replacements could be done simultaneously, but in
our model of register machines we will assume that only one register
can be assigned a new value at each step. To accomplish the replace
ments, our machine will use a third “temporary” register, which we call
t. (First the remainder will be placed in t, then the contents of b will be
placed in a, and ﬁnally the remainder stored in t will be placed in b.)
We can illustrate the registers and operations required for this ma
chine by using the datapath diagram shown in Figure 5.1. In this di
agram, the registers (a, b, and t) are represented by rectangles. Each
way to assign a value to a register is indicated by an arrow with an X
behind the head, pointing from the source of data to the register. We
can think of the X as a buon that, when pushed, allows the value at
the source to “ﬂow” into the designated register. e label next to each
buon is the name we will use to refer to the buon. e names are
arbitrary, and can be chosen to have mnemonic value (for example, a←b
669
Figure 5.1: Data paths for a machine.
denotes pushing the buon that assigns the contents of register b to
register a). e source of data for a register can be another register (as
in the a←b assignment), an operation result (as in the t←r assignment),
or a constant (a builtin value that cannot be changed, represented in a
datapath diagram by a triangle containing the constant).
An operation that computes a value from constants and the con
tents of registers is represented in a datapath diagram by a trapezoid
containing a name for the operation. For example, the box marked rem
in Figure 5.1 represents an operation that computes the remainder of
the contents of the registers a and b to which it is aached. Arrows
(without buons) point from the input registers and constants to the
box, and arrows connect the operation’s output value to registers. A
test is represented by a circle containing a name for the test. For exam
ple, our machine has an operation that tests whether the contents
of register b is zero. A test also has arrows from its input registers and
constants, but it has no output arrows; its value is used by the controller
rather than by the data paths. Overall, the datapath diagram shows the
registers and operations that are required for the machine and how they
670
abtrema←bt←rb←t0=Figure 5.2: Controller for a machine.
must be connected. If we view the arrows as wires and the X buons as
switches, the datapath diagram is very like the wiring diagram for a
machine that could be constructed from electrical components.
In order for the data paths to actually compute s, the buons
must be pushed in the correct sequence. We will describe this sequence
in terms of a controller diagram, as illustrated in Figure 5.2. e ele
ments of the controller diagram indicate how the datapath components
should be operated. e rectangular boxes in the controller diagram
identify datapath buons to be pushed, and the arrows describe the
sequencing from one step to the next. e diamond in the diagram rep
resents a decision. One of the two sequencing arrows will be followed,
depending on the value of the datapath test identiﬁed in the diamond.
We can interpret the controller in terms of a physical analogy: ink
of the diagram as a maze in which a marble is rolling. When the mar
ble rolls into a box, it pushes the datapath buon that is named by the
box. When the marble rolls into a decision node (such as the test for
671
startnodoneyes=t←ra←bb←tb = 0), it leaves the node on the path determined by the result of the
indicated test. Taken together, the data paths and the controller com
pletely describe a machine for computing s. We start the controller
(the rolling marble) at the place marked start, aer placing numbers
in registers a and b. When the controller reaches done, we will ﬁnd the
value of the in register a.
Exercise 5.1: Design a register machine to compute facto
rials using the iterative algorithm speciﬁed by the following
procedure. Draw datapath and controller diagrams for this
machine.
(define (factorial n)
(define (iter product counter)
(if (> counter n)
product
(iter (* counter product)
(+ counter 1))))
(iter 1 1))
5.1.1 A Language for Describing Register Machines
Datapath and controller diagrams are adequate for representing simple
machines such as , but they are unwieldy for describing large ma
chines such as a Lisp interpreter. To make it possible to deal with com
plex machines, we will create a language that presents, in textual form,
all the information given by the datapath and controller diagrams. We
will start with a notation that directly mirrors the diagrams.
We deﬁne the data paths of a machine by describing the registers
and the operations. To describe a register, we give it a name and specify
the buons that control assignment to it. We give each of these buons
672
a name and specify the source of the data that enters the register under
the buon’s control. (e source is a register, a constant, or an opera
tion.) To describe an operation, we give it a name and specify its inputs
(registers or constants).
We deﬁne the controller of a machine as a sequence of instructions
together with labels that identify entry points in the sequence. An in
struction is one of the following:
• e name of a datapath buon to push to assign a value to a
register. (is corresponds to a box in the controller diagram.)
• A test instruction, that performs a speciﬁed test.
• A conditional branch (branch instruction) to a location indicated
by a controller label, based on the result of the previous test. (e
test and branch together correspond to a diamond in the con
troller diagram.) If the test is false, the controller should continue
with the next instruction in the sequence. Otherwise, the con
troller should continue with the instruction aer the label.
• An unconditional branch (goto instruction) naming a controller
label at which to continue execution.
e machine starts at the beginning of the controller instruction se
quence and stops when execution reaches the end of the sequence. Ex
cept when a branch changes the ﬂow of control, instructions are exe
cuted in the order in which they are listed.
Figure 5.3: # A speciﬁcation of the machine.
(datapaths
(registers
673
((name a)
(buttons ((name a<b) (source (register b)))))
((name b)
(buttons ((name b<t) (source (register t)))))
((name t)
(buttons ((name t<r) (source (operation rem))))))
(operations
((name rem) (inputs (register a) (register b)))
((name =) (inputs (register b) (constant 0)))))
(controller
testb
(test =)
(branch (label gcddone))
(t<r)
(a<b)
(b<t)
(goto (label testb))
gcddone)
; label
; test
; conditional branch
; buon push
; buon push
; buon push
; unconditional branch
; label
Figure 5.3 shows the machine described in this way. is example
only hints at the generality of these descriptions, since the machine
is a very simple case: Each register has only one buon, and each buon
and test is used only once in the controller.
Unfortunately, it is diﬃcult to read such a description. In order to
understand the controller instructions we must constantly refer back
to the deﬁnitions of the buon names and the operation names, and to
understand what the buons do we may have to refer to the deﬁnitions
of the operation names. We will thus transform our notation to combine
the information from the datapath and controller descriptions so that
we see it all together.
To obtain this form of description, we will replace the arbitrary but
ton and operation names by the deﬁnitions of their behavior. at is,
674
instead of saying (in the controller) “Push buon t←r” and separately
saying (in the data paths) “Buon t←r assigns the value of the rem op
eration to register t” and “e rem operation’s inputs are the contents
of registers a and b,” we will say (in the controller) “Push the buon
that assigns to register t the value of the rem operation on the con
tents of registers a and b.” Similarly, instead of saying (in the controller)
“Perform the = test” and separately saying (in the data paths) “e =
test operates on the contents of register b and the constant 0,” we will
say “Perform the = test on the contents of register b and the constant
0.” We will omit the datapath description, leaving only the controller
sequence. us, the machine is described as follows:
(controller
testb
(test (op =) (reg b) (const 0))
(branch (label gcddone))
(assign t (op rem) (reg a) (reg b))
(assign a (reg b))
(assign b (reg t))
(goto (label testb))
gcddone)
is form of description is easier to read than the kind illustrated in
Figure 5.3, but it also has disadvantages:
• It is more verbose for large machines, because complete descrip
tions of the datapath elements are repeated whenever the ele
ments are mentioned in the controller instruction sequence. (is
is not a problem in the example, because each operation and
buon is used only once.) Moreover, repeating the datapath de
scriptions obscures the actual datapath structure of the machine;
it is not obvious for a large machine how many registers, opera
675
tions, and buons there are and how they are interconnected.
• Because the controller instructions in a machine deﬁnition look
like Lisp expressions, it is easy to forget that they are not arbitrary
Lisp expressions. ey can notate only legal machine operations.
For example, operations can operate directly only on constants
and the contents of registers, not on the results of other opera
tions.
In spite of these disadvantages, we will use this registermachine lan
guage throughout this chapter, because we will be more concerned with
understanding controllers than with understanding the elements and
connections in data paths. We should keep in mind, however, that data
path design is crucial in designing real machines.
Exercise 5.2: Use the registermachine language to describe
the iterative factorial machine of Exercise 5.1.
Actions
Let us modify the machine so that we can type in the numbers
whose we want and get the answer printed at our terminal. We
will not discuss how to make a machine that can read and print, but
will assume (as we do when we use read and display in Scheme) that
they are available as primitive operations.1
read is like the operations we have been using in that it produces
a value that can be stored in a register. But read does not take inputs
from any registers; its value depends on something that happens outside
the parts of the machine we are designing. We will allow our machine’s
1is assumption glosses over a great deal of complexity. Usually a large portion of
the implementation of a Lisp system is dedicated to making reading and printing work.
676
Figure 5.4: A machine that reads inputs and prints results.
operations to have such behavior, and thus will draw and notate the use
of read just as we do any other operation that computes a value.
print, on the other hand, diﬀers from the operations we have been
using in a fundamental way: It does not produce an output value to be
stored in a register. ough it has an eﬀect, this eﬀect is not on a part of
the machine we are designing. We will refer to this kind of operation as
an action. We will represent an action in a datapath diagram just as we
represent an operation that computes a value—as a trapezoid that con
tains the name of the action. Arrows point to the action box from any
inputs (registers or constants). We also associate a buon with the ac
tion. Pushing the buon makes the action happen. To make a controller
677
(controller gcdloop (assign a (op read)) (assign b (op read)) testb (test (op =) (reg b) (const 0)) (branch (label gcddone)) (assign t (op rem) (reg a) (reg b)) (assign a (reg b)) (assign b (reg t)) (goto (label testb)) gcddone (perform (op print) (reg a)) (goto (label gcdloop)))readabtrema←bt←rb←t0=printa←rdb←rdPpush an action buon we use a new kind of instruction called perform.
us, the action of printing the contents of register a is represented in
a controller sequence by the instruction
(perform (op print) (reg a))
Figure 5.4 shows the data paths and controller for the new machine.
Instead of having the machine stop aer printing the answer, we have
made it start over, so that it repeatedly reads a pair of numbers, com
putes their , and prints the result. is structure is like the driver
loops we used in the interpreters of Chapter 4.
5.1.2 Abstraction in Machine Design
We will oen deﬁne a machine to include “primitive” operations that
are actually very complex. For example, in Section 5.4 and Section 5.5
we will treat Scheme’s environment manipulations as primitive. Such
abstraction is valuable because it allows us to ignore the details of parts
of a machine so that we can concentrate on other aspects of the design.
e fact that we have swept a lot of complexity under the rug, however,
does not mean that a machine design is unrealistic. We can always re
place the complex “primitives” by simpler primitive operations.
Consider the machine. e machine has an instruction that
computes the remainder of the contents of registers a and b and as
signs the result to register t. If we want to construct the machine
without using a primitive remainder operation, we must specify how
to compute remainders in terms of simpler operations, such as subtrac
tion. Indeed, we can write a Scheme procedure that ﬁnds remainders in
this way:
678
(define (remainder n d)
(if (< n d)
n
(remainder ( n d) d)))
We can thus replace the remainder operation in the machine’s
data paths with a subtraction operation and a comparison test. Figure
5.5 shows the data paths and controller for the elaborated machine. e
instruction
(assign t (op rem) (reg a) (reg b))
in the controller deﬁnition is replaced by a sequence of instructions
that contains a loop, as shown in Figure 5.6.
Figure 5.6: # Controller instruction sequence for the
machine in Figure 5.5.
(controller testb
(test (op =) (reg b) (const 0))
(branch (label gcddone))
(assign t (reg a))
remloop
(test (op <) (reg t) (reg b))
(branch (label remdone))
(assign t (op ) (reg t) (reg b))
(goto (label remloop))
remdone
(assign a (reg b))
(assign b (reg t))
(goto (label testb))
gcddone)
Exercise 5.3: Design a machine to compute square roots
using Newton’s method, as described in Section 1.1.7:
679
Figure 5.5: Data paths and controller for the elaborated
machine.
680
a←bt←ab←tt←dabt<0==startyesdoneno