The Art of Prolog

The Art of Prolog
MIT Press Series in Logic Programming

Ehud Shapiro, editor
Koichi Furukawa , Fernando Pereira , David HiD . Warren , associate
editors
The Art of Prolog : Advanced Programming Techniques , by Leon

Sterling and Ehud Shapiro , 1986
Logic Programming : Proceedings- of- the Fourth International Con -

ference , edited by Jean - Louis Lassez , 1987
The Art of Prolog
Advanced Programming Techniques
Leon Sterling
Case Western Reserve University
Ehud Shapiro
The Weizmann Institute of Science
with a foreword by David HiD . Warren

University of Manchester
The MIT Press

Cambridge , Massachusetts
London , England
PUBLISHERSNOTE
This format is intended to reduce the cost of publishing certron works in book
form and to shorten the gap between editorial preparation and final publication .
Detailed editing and composition have been avoided by photographing the text
of this book directly from the authors ' prepared copy.
Seventhprinting , 1991
@ 1986bytheMassachusetts
Instituteof Technology
All rights reserved . No part of this book may be reproduced in any form by any
electronic or mechanical means (including photocopying , recording , or information
storage and retrieval ) without permission in writing from the publisher .
This book was set in TEX by Sarah Fliegelm ann

at the Weizmann Institute of Science
and printed and bound by MIT Press
in the United States of America .
Prints taken from Leonardo Da Vinci by Ludwig GoldscheiderJPhaidonPress, 1959
Library of Congress Cataloging -in -Publication Data
Sterling, Leon.
The Art of Prolog.
(MIT Press series in logic programming )

Includesindex.
1. Prolog (Computer program language) I . Shapiro, Ehud Y . II . Title . III . Series.
QA76.73.P76S74 1986 005
.13'3 86-10529
ISBN 0-262-19250
-0
-~ -~
ililill
~
~-
To Ruth, Miriam, Michal, and Danya
Contents
Foreword Xl
Preface XIV
Introduction xviii
Part I . Logic Programs 1
Chapter 1 : Basic Constructs 2
1 . 1 Facts
2
1 . 2 Queries 3
1 . 3 The logical variable , substitutions and instances 4
1 . 4 Existential queries 5
1 . 5 Universal facts
6
1 . 6 Conjunctive queries and shared variables 7
1 . 7 Rules
8
1 . 8 A simple abstract interpreter 12
1 . 9 The meaning of a logic program 15
1 . 10 Summary 16
Chapter 2 : Database Programming 19

2 . 1 Simple databases 19
2 . 2 Structured data and data abstraction 25
2 . 3 Recursive rules
28
2 . 4 Logic programs and the relational database model 30
2 . 5 Background 32
Chapter 3: Recursive Programming 33

3.1 Arithmetic 33
3.2 Lists 43
Contents VII
cCX
3.3 Composing recursive programs
3.4 Binary trees
3.5 Manipulating symbolic expressions
3.6 Background
Chapter 4: The Computation Model of Logic Programs

4.1 Unification
4.2 An abstract interpreter of logic programs
4.3 Background
Chapter 5: Theory of Logic Programs

5.1 Semantics
5.2 Program correctness
5.3 Complexity
5.4 Search trees
5.5 Negation in logic programming
5.6 Background
Part II . The Prolog Language 93
Chapter 6: Pure Prolog

94
6.1 The execution model of Prolog 94
6.2 Comparison to conventional programming languages
99
6.3 Background
101
Chapter 7: Programming in Pure Prolog

103
7.1 Rule order 103
7.2 Termination 105
7.3 Goal order 107
7.4 Redundant solutions 110
7.5 Recursive programming in pure Prolog
112
7.6 Background
119
Chapter 8: Arithmetic
121
8.1 System predicates for arithmetic

121
8.2 Arithmetic logic programs revisited 123
8.3 Transforming recursion into iteration 125
8.4 Background
133
Chapter 9: Structure Inspection

134
VIII Contents
9.1 Type predicates 134

9.2 Accessing compound terms 137
9.3 Background 144
Chapter 10 : MetaLogical Predicates 146

10.1 Metalogical type predicates 146
10.2 Comparing nonground terms 151
10.3 Variables as objects 152
10.4 The metavariable facility 155
10.5 Background 156
Chapter 11: Cuts and Negation 157

11.1 Green cuts: expressingdeterminacy 157
11.2 Tail recursion optimization 163
11.3 Negation 165
11.4 Red cuts: omitting explicit conditions 168
11.5 Default rules 171
11.6 Background 173
Chapter 12: Extra -Logical Predicates 175

12.1 Input / Output 175
12.2 Program accessand manipulation 179
12.3 Memo-functions 181
12.4 Interactive programs 182
12.5 Failure-driven loops 188
12.6 Background 190
Chapter 13: Pragmatics 192

13.1 Efficiency of Prolog programs 192
13.2 Programming tricks 195
13.3 Programming style and layout 198
13.4 Program development 200
13.5 Background 203
Part III . Advanced Prolog Programming Techniques 205
Chapter 14: Nondeterministic Programming 206

14.1 Generate -and-test 206
14.2 Don't -care and don't-know nondeterminism 218
Contents ix
14 . 3 Simulating nondeterministic computation models

224
14 . 4 AI classics : ANALOGY , ELIZA , and McSAM
228
14 . 5 Background
236
Chapter 15 : Incomplete Data Structures

239
15 . 1 Difference - lists
239
15 . 2 Difference - structures
247
15 . 3 Dictionaries
249
15 .4 Queues
252
15 . 5 Background
254
Chapter 16 : Parsing with Definite Clause Grammars 256

16 . 1 Background
264
Chapter 17 : Second - Order Programming

266
17 . 1 Set expressions
266
17 . 2 Applications of set expressions
271
17.3 Other second order predicates 280
17.4 Background 282
284
Chapt ~r 18: Se~ ch ,Techniques
18.1 Searching state- space graphs 284
18.2 Searching game trees 295
18.3 Background 302
Chapter 19: MetaInterpreters 303

19.1 Simple metainterpreters 303
19.2 Enhanced metainterpreters for expert systems 311
19.3 Enhanced metainterpreters for debugging 320
19.4 Background 329
Part IV . Applications 333
Chapter20: Game-PlayingPrograms 334

20.1 Mastermind 334
20 .2 Nim 338
20 .3 Kalab 343
20.4 Background 350
x Contents
Chapter 21 : A Credit Evaluation Expert System 351

21 . 1 Background 360
Chapter 22 : An Equation Solver 361

22 . 1 An overview of equation solving 361
22 .2 Factorization 364
22 .3 Isolation 364
22 .4 Polynomial 374
22 .5 Homogenization 376
22 .6 Background 378
Chapter 23: A Compiler 380

23.1 Overview of the compiler 380
23.2 The parser 386
23.3 The code generator 391
23.4 The assembler 396
23.5 Background 398
Appendix 399
A . Working with Prolog 399
B . System Predicates 400
C . Predefined Operators 405
List of Programs 415
List of Figures 421
Index 425
Foreword
by David HiD . Warren
University of Manchester
Programming in Prolog opens the mind to a new way of looking at computing .
There is a change of perspective which every Prolog programmer experiences when
first getting to know the language .
I shall never forget my first Prolog program . The time was early 1974 . I
had learnt about the abstract idea of logic programming from Bob Kowalski at
Edinburgh , although the name " logic programming " had not yet been coined .
The main idea was that deduction could be viewed as a form of computation , and
that a declarative statement of the form :
P if Q and R and S .
could also be interpreted procedurally as :
To solve P , solve Q and R and S .
Now I had been invited to Marseille . Here , Alain Colmerauer and his colleagues
had devised the language Prolog based on the logic programming conceptSome -
how , this realization of the concept seemed to me , at first sight , too simple - minded .
However Gerard Battani and Henri Meloni had implemented a Prolog interpreter
in Fortran ( their first major exercise in programming , incidentally ) . Why not give
Prolog a try ?
I sat at a clattering teletype connected down an ordinary telephone line to an
IBM machine far away in Grenoble . I typed in some rules defining how plans could
be constructed as sequences of actions . There was one important rule , modell - ed
on the SRI planner Strips ~ which described how a plan could be elaborated by
adding an action at the end . Another rule , necessary for completeness , described
how to elaborate a plan by inserting an action in the middle of the plan . As an
example for the planner to work on , I typed in facts about some simple actions
XII Foreword
in a "blocks world " and an initial state of this world . I entered a description of a
goal state to be achieved . Prolog spat back at me:
?
meaning it couldn 't find a solution . Could it be that a solution was not deducible
from the axioms I had supplied ? Ah , yes, I had forgotten to enter some crucial
facts . I tried again . Prolog was quiet for a long time and then responded :
DEBORDEMENT DE PILE
Stack overflow ! I had run into a loop . Now a loop was conceivable since the space
of potential plans to be considered was infinite . However , I had taken advantage
of Prolog 's procedural semantics to organize the axioms so that shorter plans
ought to be generated first . Could something else be wrong ? After a lot of head
scratching , I finally realized that I had mistyped the names of some variables . I
corrected the mistakes , and tried again .
Lo and behold , Prolog responded almost instantly with a correct plan to
achieve the goal state . Magic ! Declaratively correct axioms had assured a correct
result . Deduction was being harnessed before my very eyes to produce effective
computation . Declarative programming was truly programming on a higher plane !
I had dimly seen the advantages in theory . Now Prolog had made them vividly
real in practice . Never had I experienced such ease in getting a complex program
coded and running .
Of course , I had taken care to formulate the axioms and organize them in
such a way that Prolog could use them effectively . I had a general idea of how
the axioms would be used. Nevertheless it was a surprise to see how the axioms
got used in practice on particular examples . It was a delightful experience over
the next few days to explore how Prolog actually created these plans , to correct
one or two more bugs in my facts and rules , and to further refine the program .
Since that time , Prolog systems have improved significantly in terms of de-
bugging environments , speed, and general robustness . The techniques of using
Prolog have been more fully explored and are now better understood . And logic
programming has blossomed , not least because of its adoption by the Japanese a...,
the central focus of the Fifth Generation project .
After more than a decade of growth of interest in Prolog , it is a great pleasure
to see the appearance of this book . Hitherto , knowledge of how to use Prolog
for serious programming has largely been communicated by word of mouth . This
textbook sets down and explains for the first time in an accessible form the deeper
principles and techniques of Prolog programming .
Foreword Xlll
The book is excellent for not only conveying what Prolog is , but also explaining
how it should be used. The key to understanding how to use Prolog is
to properly understand the relationship between Prolog and logic programming .
This book takes great care to elucidate the relationship .
Above all , the book conveys the excitement of using Prolog - the thrill
of declarative programming . As the authors put it "declarative programming
clears the mind " . Declarative programming enables one to concentrate on the
essentials of a problem , without getting bogged down in too much operational
detail . Programming should be an intellectually rewarding activity . Prolog helps
to make it so. Prolog is indeed , as the authors contend , a tool for thinking .
Preface
The origins of this book lie in graduate student courses aimed at teaching
advanced Prolog programming . There is a wealth of techniques that has emerged
in the fifteen years since the inception of Prolog as a programming language . Our
intention in this book has been to make accessible the programming techniques
that kindled our own excitement , imagination and involvement in this area.
The book fills a general need. Prolog , and more generally logic programming ,
have received wide publicity in recent years . Currently available books and accounts
, however , typically describe only the basics . All but the simplest examples
of the use of Prolog have remained essentially inaccessible to people outside the
Prolog community .
We emphasize throughout the book the distinction between logic programming
and Prolog programming . Logic programs can be understood and studied ,
using two abstract , machine independent concepts : truth and logical deduction ;
One can ask whether an axiom in a program is true , under some interpretation of
the program symbols ; or whether a logical statement is a consequence of the pro ~
gram . These questions can be answered independently of any concrete execution
mechanism .
On the contrary , Prolog is a programming language , borrowing its basic constructs

from logic . Prolog programs have precise operational meaning : they are
instructions for execution on a computer - a Prolog machine . Prolog programs
in good style can almost always be read as logical statements , thus inheriting
some of the abstract properties of logic programs . Most important , the result of
a computation of such a Prolog program is a logical consequence of the axioms
in it . Effective Prolog programming requires an understanding of the theory of
logic programming .
The book consists of four parts : logic programming , the Prolog language ,
advanced techniques , and applications . The first part is a self-contained introduction
to logic programming . It consists of five chapters . The first chapter
aq uommoJ
Moq - ' - . ' ' - ma- ' re } ma- 9 pasoddo
l - Jo JO aq - ~ - . pmU . fRJuO' ptl
"
'
AX
xvi Preface
to write elegant short programs but have difficulty in building a major program .
The applications covered are game - playing programs , a prototype expert system
for evaluating requests for credit , a symbolic equation solver and a compiler .
During the development of the book , it has been necessary to reorganize the
foundations and basic examples existing in the folklore of the logic programming
community . Our structure constitutes a novel framework for the teaching of
Prolog .
Material from this book has been used success fully for several courses on
logic programming and Prolog : in Israel , the United States and Scotland . The
material more than suffices for a one semester course to first - year graduate students
or advanced undergraduates . There is considerable scope for instructors to
particularize a course to suit a special area of interest .
A recommended division of the book for a 13 - week course to senior undergraduates

or first - year graduates is as follows : 4 weeks on logic programming ,
encouraging students to develop a declarative style of writing programs , 4 weeks

on basic Prolog programming , 3 weeks on advanced techniques , and 2 weeks spent
on applications . The advanced techniques should include some discussion of nondeterminism
, incomplete data structures , basic second - order predicates , and basic
metainterpreters . Other sections can be covered instead of applications . Application
areas that can be stressed are search techniques in artificial intelligence ,
building expert systems , writing compilers and parsers , symbol manipulation , and
natural language processing .
There is considerable flexibility in the order of presentation . The material

from Part I should be covered first . The material in Part III and IV can be
interspersed with the material in Part II to show the student how larger Prolog
programs using more advanced techniques are composed in the same style as
smaller examples .
Our assessment of students has usually been 50 % by homework assignments

throughout the course , and 50 % by project . Our experience has been that students
are capable of a significant programming task for their project . Examples of
projects are prototype expert systems , assemblers , game - playing programs , partial
evaluators , and implementations of graph theory algorithms .
For the student who is studying the material on her own , we strongly advise
reading through the more abstract material in Part I . A good Prolog programming
style develops from thinking declaratively about the logic of a situation . The
theory in Chapter 5 , however , can be skipped until a later reading .
The exercises in the book range from very easy and well - defined to difficult
and open - ended . Most of them are suitable for homework exercises . Some of the
Preface XVII
more open - ended exercises were submitted as course projects .
The " code in this book is essentially in Edinburgh Prolog . The course has
been given where students used several different variants of Edinburgh Prolog ,
and no problems were encountered . All the examples run on Wisdom Prolog ,
which is discussed in the appendix es .
We acknowledge and thank the people who contributed directly to the book .
We also thank , collectively and anonymously , all those who indirectly contributed
by influencing our programming styles in Prolog . Improvements were suggested
by Lawrence Byrd , Oded Maler , Jack Minker , Richard O ' Keefe , Fernando Pereira ,
and several anonymous referees .
We appreciate the contribution of the students who sat through courses as
material from the book was being debugged . The first author acknowledges students
at the University of Edinburgh , the Weizmann Institute of Science , Tel Aviv
University , and Case Western Reserve University . The second author taught
courses at the Weizmann Institute , Hebrew University of Jerusalem and other
short courses to industry .
We are grateful to many people for assisting in the technical aspects of producing
a book . We especially thank Sarah Fliegelmann who produced the various
drafts and camera - ready copy , above and beyond the call of duty . This book may
not have appeared without her tremendous efforts . Arvind Bansal prepared the
index and helped with the references . Yehuda Barbut drew most of the figures .
Max Goldberg and Shmuel Sarra prepared the appendix . The publishers , MIT
Press , were helpful and supportive .
Finally , we acknowledge the support of family and friends without which
nothing would get done .

Introduction
The inception of logic is tied with that of scientific thinking . Logic provides a
precise language for the explicit expression of one's goals, knowledge , and assumptions
. Logic provides the foundation for deducing consequences from premises ;
for studying the truth or falsity of statements given the truth or falsity of other
statements ; for establishing the consistency of one's claims ; and for verifying the
validity of one's arguments .
Computers are relatively new in our intellectual history . Similar to logic ,
they are both the object of scientific study , and a powerful tool for the advancement
of scientific endeavor in general . Like logic , computers require a precise
and explicit statement of one's goals and assumptions . Unlike logic , which has
developed with the power of the human thinking as the only external consideration
, the development of computers has been governed from the start by severe
technological and engineering constraints . Although computers were intended for
use by humans , the difficulties in constructing them were so dominant , that the
language for expressing problems to the computer and instructing it how to solve
them was designed from the perspective of the engineering of the computer alone .
Almost all modern computers are based on the early concepts of yon Neu-
mann and his colleagues , which emerged during the 1940's. The yon Neumann
machine is characterized by a large uniform store of memory cells, and aprocessing
unit with some local cells, called registers . The processing unit can load data
from memory to registers , perform arithmetic or logical operations on registers ,
and store values of registers back into memory . A program for a yon Neumann
machine consists of a sequence of instructions to perform such operations , and an
additional set of control instructions , which can affect the next instruction to be
executed , possibly depending on the content of some register .
As the problems of building computers were gradually understood and solved ,
the problems of using them mounted . The bottleneck ceased to be the inability
of the computer to perform the human 's instructions , but rather the inability of
the human to instruct , or program , the computer . A search for programming
Introduction xix
languages convenient for humans to program in has begun . Starting from the
language understood directly by the computer , the machine language , better notations
and formalisms were developed . The main outcome of these efforts was
languages that were easier for humans to express themselves in , but still mapped
rather directly to the underlying machine language . Although increasingly abstract
, the languages in the mainstream of development , starting from assembly
language , through Fortran , Algol , Pascal , and Ada , all carried the mark of the
underlying machine - the von Neumann architecture .
To the uninitiated intelligent person , who is not familiar with the engineering
constraints that lead to its design , the von Neumann machine seems an arbitrary ,
even bizzare , device . Thinking in terms of its constrained set of operations is a
non -trivial problem , which sometimes stretch es the adaptiveness of the human
mind to its limits .
These characteristic aspects of programming von Neumann computers have

lead to a separation of work : there were those who thought how to solve the
problem , and designed the methods for its solution , and there were the coders ,
who performed the mundane and tedious task of translating the instructions of
the designers to instructions a compute :..' can digest ,
Both logic and programming require the explicit expression of one's knowledge
and methods in an acceptable formalism . The task of making one's knowledge
explicit is tedious . However , formalizing one's knowledge in logic is often
an intellectually rewarding activity , and usually reflects back on or adds insight
to the problem under consideration . In contrast , formalizing one's problem and
method of solution using the von Neumann instruction set rarely has these beneficial
effects .
We believe that programming can be , and should be, an intellectually rewarding

activity ; that a good programming language is a powerful conceptual
tool - a tool for organizing , expressing , experimenting with , and even communicating
one's thoughts ; that treating programming as "coding ," the last , mundane ,
intellectually trivial , but time -consuming and tedious phase of solving a problem
using a computer system , is perhaps at the very roots of what has been known as
the "software crisis ."
Rather , we think that programming can be , and should be , part of the problem
solving process itself ; that thoughts should be organized as programs , so that
consequences of a complex set of assumptions can be investigated by "running "
the assumptions ; that a conceptual solution to a problem should be developed
hand -in -hand with a working program that demonstrates it and exposes its different
aspects . Suggestions in this direction have been made under the title "rapid
prototyping ."
xx Introduction
To achieve this goal in its fullest - to become true mates of the human
thinking process - computers have still a long way to go. However , we find it both
appropriate and gratifying from a historical perspective that logic , a companion
to the human thinking process since the early days of human intellectual history ,
has been discovered as a suitable stepping -stone in this long journey .
Although logic has been used as a tool for designing computers , and for
reasoning about computers and computer programs since almost their beginning ,
the use of logic directly as a programming language ) termed logic programming ,
is quite recent .
Logic programming , as well as its sister approach , functional programming ,
departs radically from the mainstream of computer languages . Rather then being
derived , by a series of abstractions and reorganizations , from the von Neumann
machine model and instruction set , it is derived from an abstract model , which
has no direct relationship or dependency to one machine model or another . It is
based on the belief that instead of the human learning to think in terms of the
operations of a computer , which some scientists and engineers at some point in
history happened to find easy and cost-effective to build , the computer should
perform instructions that are easy for humans to provide . In its ultimate and
purest form , logic programming suggests that even explicit instructions for operation
not be given but , rather , the knowledge about the problem and assumptions
that are sufficient to solve it be stated explicitly , as logical axioms . Such a set
of axioms constitutes an alternative to the conventional program . The program
can be executed by providing it with a problem , formalized as a logical statement
to be proved , called a goal statement . The execution is an attempt to solve the
problem , that is , to prove the goal statement , given the assumptions in the logic
program .
A distinguishing aspect of the logic used in logic programming is that a
goal statement typically is existentially quantified : it states that there exist some
individuals with some property . An example of a goal statement is that there
exists a list X such that sorting . the list [9,1,2] gives X . The mechanism used to
prove the goal statement is constructive : if successful, it provides the identity
of the unknown individuals mentioned in the goal statement , which constitutes
the output of the computation . In the example above, assuming that the logic
program contains appropriate axioms defining the sort relation , the output of the
computation would be X = [1,2,9].
Introduction xxi
These ideas can be summarized in the following two metaphorical equations :
program = set of axioms

computation = constructive proof of a goal statement from the program
The ideas behind these equations can be traced back as far as intuitionistic
mathematics and proof theory of the early century . They are related to Hilbert 's
program , to base the the entire body of mathematical knowledge on logical foundations
, to provide mechanical proofs for its theories , starting from the axioms of
logic and set theory alone . It is interesting to note that the fall of this program ,
which ensued the incompleteness and undecidability results of Godel and Turing ,
also marks the beginning of the modern age of computers .
The first use of this approach in practical computing is a sequel to Robinson 's
unification algorithm and resolution principle , published in 1965. Several hesitant
attempts were made to use this principle as a basis of a computational mechanism ,
but they did not gain any momentum . The beginning of logic programming can
be attributed to Kowalski and Colmerauer . Kowalski formulated the procedural
interpretation of Horn clause logic . He showed that an axiom
A if Bl and B2 and . . . and Bn
can be read , and executed , as a procedure of a recursive programming language ,

where A is the procedure head and the Bi 'S are its body . In addition to the
declarative reading of the clause, A is true if the Bi 'S are true , it can be read
as follows: to solve (execute) A , solve (execute) Bl and B2 and . . . and Bn. In
this reading , the proof procedure of Horn clause logic is the interpreter of the
language , and the unification algorithm , which is at the heart of the resolution
proof procedure , performs the basic data manipulation operations of variable
assignment , parameter passing , data selection , and data construction .
At the same time , early 1970's, Colmerauer and his group at the University of
Marseille -Aix developed a specialized theorem prover , written in Fortran , which
they used to implement natural language processing systems . The theorem prover ,
called Prolog (for Programmation en Logique ), embodied Kowalski 's procedural
interpretation . Later , van Emden and Kowalski developed a formal semantics for
the language of logic programs , showing that its operational , model -theoretic , and
ftxpoint semantics are the same.
In spite of all the theoretical work and the exciting ideas , the logic programming
approach seemed unrealistic . At the time of its inception , researchers in the
U .S. began to recognize the failure of the "next -generation AI languages ," such
as Micro -Planner and Conniver , which developed as a substitute for Lisp . The
main claim against these languages was that they were hopelessly inefficient , and
XXII Introduction
very difficult to control . Given their bitter experience with logic -based high -level
languages , it is no great surprise that U .S. AI scientists , when hearing about Prolog
, thought that the Europeans are over-excited over what we, Americans , have
already suggested , tried , and discovered not to work .
In that atmosphere the Prolog - 10 compiler was almost an imaginary being .

Developed in the mid to late 19.70's by David HiD . Warren and his colleagues , this
efficient implementation of Prolog dispelled all the myths about the impracticality
of logic programming . That compiler , which is still one of the finest implementations
of Prolog around , delivered on pure list -processing programs performance
comparable to the best Lisp systems available at the time . Furthermore , the compiler
itself was written almost entirely in Prolog , suggesting that fairly classical
programming tasks , not just sophisticated AI applications , can benefit from the
power of logic programming .
The impact of this implementation cannot be over-exaggerated . Without it ,

the accumulated experience that has lead to this book would not have existed .
In spite of the promise of the ideas , and the practicality of their implementation
, most of the Western computer science and AI research community was
ignorant , outwardly hostile , or , at best , indifferent to logic programming . By
1980, the number of researchers actively engaged in logic programming were only
a few dozens in the U .S . , and about one hundred around the world .
No doubt logic programming would have remained a fringe activity in computer

science for quite a little longer were it not for the announcement of the
Japanese Fifth Generation Project , which took place in October 1981. Although
the research program the Japanese have presented was rather baggy , faithful to
their tradition of achieving consensus at almost all cost , the important role of logic
programming in the next generation of computer systems was presented loud and
clear .
Since that time the Prolog language has undergone a rapid transit from
adolescence to maturity . There are numerous commercially available Prolog implementations
on most widespread computers . There is a large number of Prolog
programming books , directed to different audiences and emphasizing different aspects
of the language . And the language itself has more -or -less stabilized , having
a de facto standard , the Edinburgh Prolog family .
The maturity of the language means that it is no longer a concept for scientists
yet to shape and define , but rather a given object , with all its vices and
virtues . It is time to recognize that , on the one hand , Prolog is falling short of
the high goals of logic programming , but that , on the other hand , it is a powerful ,
productive , and practical programming formalism . Given the standard life cy-
Introduction xxiii
cle of computer programming languages , the next few coming years will witness
whether these properties will show their merit only in the classroom or will also
be proven useful in the field , where people pay money to solve problems they care
about .
So what are the current active subjects of research in logic programming and
Prolog ? The answer to this question can be found in the regular scientific journals
and conferences of the field . The Logic Programming Journal , the Journal of New
Generation Computing , the International Conference on Logic Programming , and
the IEEE Symposium on Logic Programming , as well as in the general computer
science journals and conferences .
Clearly , one of the dominant areas of interest is the relationship between
logic programming , Prolog , and parallelism . The promise of parallel computers ,
combined with the parallelism that seems to be available in the logic programming
model , have lead to numerous attempts , which are still ongoing , to execute Prolog
in parallel , and to devise novel concurrent programming languages based on the
logic programming computation model . This , however , is a subject for another
book .
Leonardo Da Vinci , Old Man thinking. Pen and ink (slightly enlarged
). About 1510. Windsor Castle, Royal Library
P art I
Logic PrograIns
A logic program is a set of axioms , or rules , defining relationships between

objects . A computation of a logic program is a deduction of consequences of the
program . A program defines a set of consequences, which is its meaning . The art
of logic programming is constructing concise and elegant programs that have the
desired meaning .
Chapter 1
Basic Constructs
The ba.sic constructs of logic programming , terms and statements , are inherited
from logic . There are three ba.sic statements : facts , rules and queries . There
is a single data structure : the logical term .
1.1 Facts
The simplestkind of statementis calleda fact. Factsare a meansof stating

that a relationshipholdsbetweenobjects. An exampleis
fathcr( abraham
,isaac).
This fact saysthat Abraham is the father of Isaac, or that the relation father
holds betweenthe individuals named abrahamand isaac. Another namefor a
relationshipis a predicate
. Namesof individuals are known as atoms. Similarly
plus(2,3,5) express
esthe relationshipthat 2 plus3 is 5. The familiar plusrelationship
can be realizedvia a set of facts that definesthe addition table. An initial
segmentof the table is
plus(O,O,O). plus(Oil,l ). plus(O,2,2). plus(O,3,3).
plus(l ,Oil). plus(1,1,2). plus(1,2,3). plus(1,3,4).
A sufficientlylarge segmentof this table, which happensto be alsoa legal logic

program, will be assumedas the definition of the plus relation throughout this
chapter.
The syntactic conventionsused throughout the book are introduced as
needed
. The first is the caseconvention
. It is significant that the namesof
1.2 Queries 3
-
father :terach ,abraham ) . male (terach ) .
father -
:terach ,nachor ) . male (abraham ) .
father :terach ,haran ) . male (nachor ) .
father :abraham ,isaac ) . male (haran ) .
father :haran ,lot ) . male (isaac) .
-
father :haran ,milcah ) . male (lot ) .

father :haran ,yiscah ) .
female (sarah ) .
mother (sarah,isaac). female (milcah ) .
female (yiscah ) .
Program 1. 1: A Biblical family database
both predicates and atoms in facts begin with a lowercase letter , as opposed to
an uppercase letter . These names are italicized when they appear inrunning text .
A finite set of facts constitutes a program. This is the simplest form of logic
program. A set of facts is also a description of a situation . This insight is the
basis of databaseprogramming, to be discussedin the next chapter. An example
database of family relationships from the Bible is given as Program 1.1. The
predicates father, mother, male, and female expressthe obvious relationships.
1.2 Queries
The second form of statement in a logic program is a query. Queries

are a means of retrieving information from a logic program . A query asks
whether a certain relation holds between objects . For example , the query father
( abraham , isaac) ? asks whether the father relation holds between abraham
and isaac. Given the facts of Program 1.1, the answer to this query is yes.
Syntactically , queries and facts look the same, but can be distinguished by
the context . When there is a possibility of confusion , a terminating period will
indicate a fact , while a terminating question mark will indicate a query . We call
the entity without the period or question mark a goal. A fact P . states that the
goal P is true . A query P ? asks whether the goal P is true . A simple query
consists of a single goal .
Answering a query with respect to a program is determining whether the
query is a logical consequence of the program . We define logical consequence
incrementally through this section . Logical consequences are obtained by applying
deduction rules . The simplest rule of deduction is identity : from P deduce P. A
4 Basic Constructs 1.2
query is a logical consequence of an identical fact .

Operationally , answering simple queries using a program containing facts like
Program 1.1 is straightforward . Search for a fact in the program which implies
the query . If a fact identical to the query is found , the answer is yes.
The answer no is given if a fact identical to the query is not found , because
the fact is not a logical consequence of the program . ,This answer does not reflect
on the truth of the query ; it merely says that we failed to prove the query from the
program . Both the queries female ( abraham) ? and plus (1,1,2) ? will be answered
no with respect to Program 1.1.
1 .3 The logical variable , substitutions and instances
A logical variable stands for an unspecified individual , and is used accordingly

. Consider its use in queries . Suppose we wanted to know of whom abraham
was the father . One way is to ask a series of queries , father ( abraham , lot ) ?,
father ( abraham ,milcah ) ?, . . ., father ( abraham ,isaac) ?, . . . until an answer yes
is given . A variable allows a better way of expressing the query as father
( abraham ,X) ?, to which the answer is X = isaac. Used in this way+ variables
are a means of summarizing many queries. A query containing a variable asks
whether there is a value for the variable that makes the query a logical consequence
of the program , as explained further below .
Variables in logic programs behave differently from variables in conventional

programming languages . They stand for an unspecified but single entity , rather
than for a store location in memory .
Having introduced variables , we can defIne terms , the single data structure
in logic programs . The defInition is inductive . Constants and variables are terms .
Also compound terms , or structures , are terms . A compound term comprises a
functor (called the principal functor of the term ) and a sequence of one or more
arguments , which are terms . A functor is characterized by its name , which is
an atom , and its arity , or number of arguments . Syntactically compound terI I!s
have the form f ( 4 ,~ ,. . .,tn) where the functor has name f and is of arity n, and
the ~ 's are the arguments . Examples of compound terms include 8( 0) , hot (milk ) ,
name (john ,doe) , li8t ( a,list ( b,ni ~ ) , foo (X) , and tree(tree( nil ,9,ni ~ ,5,R) .
Queries , goals, and more generally terms where variables do not occur are
called ground . Where variables do occur , they are called nonground . For example ,
foo ( a,b) is ground , whereas bar(X) is not .
1.4 Existential queries 5
Definition : A substitution is a finite set (possibly empty) of pairs of the

form Xi = ~, where Xi is a variable and ~ is a term , and Xi # Xj for every j , and
Xi does not occur in tj , for any i and j . .
An example of a substitution consisting of a single pair is { X = isaac} . Substitutions
can be applied to terms. The result of applying a substitution lJ to a
term A , denoted by AlJ, is the term obtained by replacing every occurrence of X
by t in A , for every pair X = t in lJ.
The result of applying { X = isaac} to the term father(abraham,X) is the term
father ( abraham, isaac).
Definition : A is an instance of B if there is a substitution () such that A =
B (} . .
The goal father ( abraham, isaac) is an instance of father( abraham,X) by this

definition . Similarly mother( sarah, isaac) is an instance of mother(X , Y) under the
substitution { X = sarah, Y= isaac} .
1 .4 Existential queries
Logically speaking , variables in queries are existentially quantified , which

means, intuitively , that the query father( abrahamJX) ? reads: "Does there exist
an X such that abraham is the father of X ?" More generally, a query
p( T1JT2J.. .JTn) ?, which contains the variables xi ,X2J. . 'JXk reads: "Are there
X1JX2,. . .JXk such that p( T1, T2,. . ., Tn) ?" For convenience, existential quantification
is usually omitted .
The next deduction rule we introduce is generalization : an existential query
P is a logical consequence of an instance of it , P(}, for any substitution (). The fact
father( abraham, isaac) implies that there exists an X such that father( abraham,X)
is true , namely X = isaac .
Operationally , to answer an existential , nonground , query using a program
of facts , find a fact that is an instance of the query . The answer , or solution , is
that instance . The answer is no if there is no suitable fact in the program .
Answering nonground queries is performing a computation whose output is

an instance of the query . We sometimes represent this instance by a substitution
that , if applied to the query , results in the solution instance .
In general , an existential query may have several solutions . Program 1.1
showsthat Haran is the father of three children. Thus the query father (haran,X) ?
has the solutions { X = lot} , { X = milcah} , { X = yiscah} . Another query with multi -
pIe solutions is plus (X , Y,4) 'I for finding numbers that add up to 4. Solutions are,
for example , { X = O, Y= 4} and { X = l , Y= 9} . Note that the different variables X
and Y correspond to (possibly ) different objects .
An interesting variant of the last query is plus (X ,X ,4) 'I which insists that
the two numbers that add up to 4 be the same. It has a unique answer { X = 2} .
1 .5 _Universal facts
Variables are also useful in facts . Suppose that all the Biblical characters like
pomegranates . Instead of including in the program an appropriate fact for every
individual :
likes ( abraham ,pomegranates ) .

likes ( sarah ,pomegranates ) .
a fact likes(X ,pomegranates

) can say it all. Used in this way, variables are a means
of summarizing many facts. The fact times( O,X ,O) summarizesall the facts stating
that o times some number is 0 .
Variables in facts are implicitly universally quantified , which means , in -

tuitively , that the fact likes(X ,pomegranates ) states that for all X , X likes
pomegranates. In general a fact p( Tl ,. . ., Tn) reads that for all Xl ,. . .,Xk , where
the Xi 'S are variables occuring in the fact, p( Tl ' . . ., Tn) is true . Logically, from a
universally quantified fact one can deduce any instance of it . For example , from
likes(X ,pomegranates
) deduce likes( abraham,pomegranates).
This is the third deduction rule , called instantiation : From a universally
quantified statement P deduce an instance of it PO, for any substitution O.
As for queries, two unspecified objects, denoted by vaxiables, can be constrained
to be the same by using the same variable name. The fact plus( O,X ,X)
express es that 0 is a left identity for addition . It reads that for all values of
X , 0 plus X is X . A similar use occurs when translating the English statement ,
"everybody likes himself ' to likes(X ,X) .
Answering a ground query with a universally quantified fact is straightforward
. Search for a fact for which the query is an instance . For example , the
answer to plus(O,2,2) ? is yes, based on the fact plus(O,X ,X) . Answering a nonground
query using a nonground fact involves a new definition : a common instance
of two terms .
1.6 Conjunctive queries and shared variables 7
Definition : C is a common instance of A and B if it is an instance of A and
an instance of B . In other words , if there are substitutions fJ1 and fJ2 such that
C = AfJ1 is syntactically identical to BfJ2 . .
For example , the goals plus ( 0 , 9 , Y) and plus ( 0,X ,X) have a common instance
plus ( 0 ,9,9) . Applying the substitution { Y = 9} to plus ( 0 , 9 , Y) and the substitution
{ X = 9} to plus ( O, X , X ) both yield plus ( 0, 9, 9) .
In general , to answer a query using a fact , search for a common instance of
the query and fact . The answer is the common instance , if one exists . Otherwise
the answer is no .
Answering an existential query with a universal fact using a common instance
involves two logical deductions . The instance is deduced from the fact by the
rule of instantiation , and the query is deduced from the instance by the rule of
generalization .
1 .6 Conjunctive queries and shared variables
An important extension to the queries discussed so far is conjunctive queries .
Conjunctive queries are a conjunction of goals posed as a query , for example ,
father ( terach , x ) , father ( X , 1' ) ? or in general , Q ! , . . . , Qn ? Simple queries are a
special case of conjunctive queries when there is a single goal . Logically it asks
whether a conjunction is deducible from the program . We use ' , ' throughout to
denote logical ' and .' Do not confuse the comma that separates the arguments in
a goal with commas used to separate goals , denoting conjunction .
In the simplest conjunctive queries all the goals are ground , for example ,
father ( abraham , isaac ) , male ( lot ) ? The answer to this query using Program 1 . 1 is
clearly yes as both goals in the query are facts in the program . In general , the
query Q ! , . . . , Qn ? where each Qi is a ground goal is answered yes with respect to
a program P if each Qi is implied by P . Hence ground conjunctive queries are not
very interesting .
Conjunctive queries are interesting when there are one or more shared variables
, variables that occur in two different goals of the query . An example is the
query father ( haran , X ) , male (X) ? The scope of a variable in a conjunctive query
is the whole conjunction . Thus the query p (X) ,q(X) ? reads : " Is there an X such
that both p (X) and q(X ) ? " Like in simple queries , variables in conjunctive queries
are implicitly existentially quantified . .
Shared variables are used as a means of constraining a simple query by restricting
the range of a variable . We have already seen an example with the query
plus (X ,X ,;,) 'i where the solution of numbers adding up to 4 was restricted to
the numbers being the same. Consider the query father ( haran ,X) , male (X) ? Here
solutions to the query father ( haran ,X) 'i are restricted to children that are male .
Program 1.1 shows there is only one solution , { X = lot } . Alternatively this query
can be viewed as restricting solutions to the query male (X) ? to individuals who
have Haran for a father .
A slightly different use of a shared variable can be seen in the query father
( terach ,X) ,father (X , Y) ? On the one hand it restricts the sons of terach to
those who are themselves fathers . On the other hand it considers individuals
Y, whose fathers are sons of terach . There are several solutions , for example ,
{ X = abrahamY = isaac} , and { X = haran , Y= lot } .
A conjunctive query is a logical consequence of a program P if all the goals in

the conjunction are consequences of P, where shared variables are instantiated to
the same values in different goals. A sufficient condition is that there is a ground
instance of the query that is a consequence of P . This instance then deduces the
conjuncts in the query via generalization .
The restriction to ground instances is unnecessary , and will be lifted in Chapter

4 when we discuss the computation model of logic programs . We employ this
restriction in the meantime to simplify the discussion in the coming sections .
Operationally , to solve the conjunctive query Al ,A2 ' . ' .,An ? using a program
P, find a substitution {} such that ai {} and . . . and An {} are ground instances of
facts in P. The same substitution applied to all the goals ensures that instances
of variables are common throughout the query . For example , consider the query
Lather (harani X) , male (. X) ? with respect to Program 1.1. Applying the substitution
{ X = lot } to the query gives the ground instance Lather (haran ,lot ) , male ( lot ) ?
which is a consequence of the prog Fam.
1.7 Rules
Interesting conjunctive queries are defining relationships in their own right .

The query father (haran JX) Jmale(X) '?is asking for a son of Haran . The query father
( terach JX) , /ather (X JY) '?is asking about grandchildren of Terach . This brings
us to the third and most important statement in logic programming , a rule , which
enables us to define new relationships in terms of existing relationships .
Rules are statements of the form :
A +- Bl ,B2,. . .,Bn .
1.7 Rules 9
where n 2:: O. A is the head of the rule , and the Bi ' S are its body . Both A and the
Bi ' S are goals . Rules , facts and queries are also called Horn clauses , or clauses
for short . Note that a fact is just a special case of a rule when n = O. Facts are
also called unit clauses . We also have a special name for clauses with one goal
in the body , namely when n= l . Such a clause is called an iterative clause . As
for facts , variables appearing in rules are universally quantified , and their scope
is the whole rule .
A rule expressing the son relationship is
son (X , Y ) +- fatherY ,X ) , male (X ) .
Similarly one can define a rule for the daughter relationship :
daughter (X , Y ) +- fatherY ,X ) , female (X ) .
A rule for the grandfather relationship is
grandfather (X ,Z ) +- father (X ,Y ) , fatherY ,Z ) .
Rules can be viewed in two ways . First , they are a means of expressing
new or complex queries in terms of simple queries . A query son ( X , haran ) ? to
the program that contains the above rule for son is translated to the query father
( haran , X) , male ( X) ? according to the rule , and solved as before . A new query
about the son relationship has been built from simple queries involving father and
male relationships . Interpreting rules in this way is their procedural reading . The
procedural reading for the grandfather rule is : " To arlswer a query is X the grandfather
of Y , answer the conjunctive query is X the father of Z and Z the father of
Y ."
The second view of rules comes from interpreting the rule as a logical axiom .
The backward arrow +- is used to denote logical implication . The son rule reads :
" X is a son of Y if Y is the father of X and X is male ." In this view rules are
a means of defining new or complex relations using other , simpler , relationships .
The predicate son has been defined in terms of the predicates father and male . The
associated reading of the rule is known as the declarative reading . The declarative
reading of the grandfather rule is : " For all X , Y , and Z , X is the grandfather of
Y if X is the father of Z and Z is the father of Y ."
Although formally all variables in a clause are universally quantified , we will

sometimes refer to variables that occur in the body of the clause , but not in its
head ) as if they are existentially quantified inside the body . For example ) the
grandfather rule can be read : " For all X and Y , X is the grandfather of Y if there
exists a Z such that X is the father of Z and Z is the father of Y ." The formal
justification of this verbal transformation will not be given , and we treat it just
as convenience . Whenever it is a source of confusion , the reader can resort back

to the formal reading of a clause , in which all variables are universally quantified
from the outside .
To incorporate rules into our framework of logical deduction , we need the law
of modus ponens . Modus ponens states that from Band A +- B we can deduce A .
Definition : The law of universal modus ponens says that from the rule
R = (A ~ B1,B2,. . .,Bn )
and the facts
B'1-
~
-
Un-
A I can be deduced , if
A ' +- B' 1 , B' 2 ' . . . , B' n
is an instance of R . .
Universal modus ponens includes identity and instantiation as special cases.
We are now in a position to give a complete definition of the concept of a
logic program and of its associated concept of logical consequence .
Definition : A logic program is a finite set of rules . .
Definition : An existentially quantified goal G is a logical consequence of
a program P if there is a clause in P with a ground instance A + - Bl , . ' . , Bn ,
n ~ 0 , such that Bl , . . . , Bn are logical consequences of P and A is an instance of
G . . .
Note that the goal G is a logical consequence of a program P if and only if G
can be deduced from P by a finite number of applications of the rule of universal
modus ponens .
Consider the query son ( S , haran ) ' ? with respect to Program 1 . 1 augmented
by the rule for son . The substitution { X = lot , Y = haran } applied to the rule gives
the instance son ( lot , haran ) + - father ( haran , lot ) , male ( lot ) . Both the goals in the
body of this rule are facts in Program 1.1. Thus universal modus ponens implies
the query with answerS = lot .

1.7 Rules 11
Operationally , answering queries reflects the definition of logical consequence.

Guess a ground instance of a goal , and a ground instance of a rule , and recursively
answer the conjunctive query corresponding to the body of that rule . To prove
a goal A , with program P , choose a rule Al +- B1,B2,. . .,Bn in P , and guess
substitution (} such that A = ai (}, and Bi (} is ground for 1 :::; i :::; n. Then recursively
prove each Bi (}. This procedure can involve arbitrarily long chains of reasoning .
It is difficult in general to guess the correct ground instance and choose the right
rule . We show in Chapter 4 how the guessing of an instance can be removed .
The rule given for son is correct , but is an incomplete specification of the
relationship . For example , we cannot conclude that Isaac is the son of Sarah .
What is missing is that a child can be the son of a mother as well as the son of a
father . A new rule expressing this relationship can be added , namely
son(X ,Y ) i - motherY ,X ), male(X ).
Similarly , to define the relation grandparent would take four rules to include
both cases of father and mother :
grandparent(X ,Z) +- father (X ,Y ) , fatherY ,Z).

grandparent(X ,Z) +- father (X ,Y ) , motherY ,Z).
grandparent(X ,Z) ~ mother(X ,Y ) , fatherY ,Z).
grandparent(X ,Z) +- mother(X ,Y ) , motherY ,Z).
There is abetter , more compact , way of expressing these rules . We need to define
the auxiliary relationship , parent , as being a father or a mother . Part of the art
of logic programming is deciding on what intermediate predicates to define to
achieve a complete , elegant axiomatization of a relationship . The rules defining
parent are straightforward , capturing the definition of a parent being a father
or a mother . Logic programs can incorporate alternative definitions , or more
technically disjunction , by having alternative rules , as for parent :
paI'ent(X ,Y ) +- father (X ,Y ) .
parent (X ,Y ) +- mother(X ,Y ).
Rules for son and grandparent are now , respectively :
son(X ,Y ) +- parentY ,X ), male(X ).

grandparent(X ,Y ) +- parent(X ,Z), parent(Z,Y ).
A collection of rules with the same predicate in the head , such as the pair of
parent rules , is called a procedure. We shall see later that under the operational
interpretation of these rules by Prolog , such a collection of rules is indeed the
analogue of procedures or subroutines in conventional programming languages .
Input : A ground query Q and a program P

Output : yes if a proof of Q from P was found ,
.no otherwise
Algorithm :
Initialize the resolvent to Q
while the resolventAl ,' . .,An is not empty
begin
choose a goal Ai , 1 SiS n, and
a ground instance of a clause
A +- B1 ,B2 , . . ., Bk , k ~ 0 in P , such that A = Ai
(if no such clause exists, exit the while loop);
determine the new resolvent
Al , ' . .,Ai _ l ,Bl " . .,Bk ,Ai + l " . .,An

end
H the resolvent is empty , output yes ; otherwise output no .
Figure 1.1: An abstract interpreter for logic programs
1 .8 A simple abstract interpreter
An operational procedure for answering queries has been informally described

and progressively developed in the previous sections . We flesh out the details here
to give an abstract interpreter for logic programs . In keeping with the restriction
of universal modus ponens to ground goals, the interpreter only answers ground
queries .
The abstract interpreter performs yes/ no computations. It takes a program

P and a ground query Q and gives as output yes if Q is deducible from P and no
otherwise . The interpreter may also fail to terminate if the goal is not deducible
from the program , and in such a case it produces no answer at all . The steps of
the interpreter are given in Figure 1.1.
The current goal at any stage of the computation is called the resolvent . A
trace of the interpreter is the sequenceof resolvents produced during the computation
, together with the choicesmade. Consider the query son( lotJharan) ? with
respect to Program 1.2, a subset of the facts of Program 1.1 together with rules
defining son and daughter . Figure 1.2 is a trace of answering the query .
The trace implicitly contains a proof of the ground query from the program .
A more convenient representation of the proof is with a proof tree . We define the
necessary concepts .
1.8 A simple abstract interpreter 13
father ( abraham , isaac ) . male ( isaac ) .
father ( haran , lot ) . male ( lot ) .
father ( haran , milcah ) . female ( milcah ) .
father ( haran , yiscah ) . female ( yiscah ) .
son ( X , Y ) i - fatherY , X ) , male ( X ) .
daughter ( X , Y ) i - fatherY , X ) , female ( X ) .
Program 1 . 2 : Biblical family relationships
Definition : A ground reduction of a goal G by a program P is the replacement

of G by the body of a ground instance of a rule in P , whose head is identical
to the chosen goal . .
Later the definition is relaxed to general (non ground ) reductions . Areduction

is the basic computational step in logic programming . It corresponds to an
application of universal modus ponens . It also corresponds to one iteration of the
while loop of the interpreter in Figure 1.1. The goal replaced in a reduction is
reduced, and the new goals are derived .
We relate these concepts to our example trace in Figure 1.2. There are three
reductions in the trace . The first reduces the goal son( lot ,haran ) and produces
two derived goals, father (haran ,lot ) and male (lot ) . The second reduction is of
father (haran ,lot ) producing no derived goals . The third reduction also produces
no derived goals in reducing male ( lot ) .
A proof tree consists of nodes and edges which represent the goals reduced
during the computation . The root of the proof tree for a simple query is the
query itself . The nodes of the tree are the goals which are reduced during the
computation . There is a directed edge from a node to each node corresponding to
a derived goal of the reduced goal . The proof tree for a conjunctive query is just
the collection of proof trees for the individual goals in the conjunction . Figure
1.3 gives a proof tree for the program trace in Figure 1.2.
There are two unspecified choices in the interpreter . The goal to reduce from
the resolvent must be chosen, as well as the clause (and an appropriate ground
instance ) to reduce it . The two choices have very different natures .
The selection of the goal to be reduced is arbitrary . In any given resolvent

all the goals must be reduced . It can be shown that the order of reductions is
immaterial for finding a proof . That is , if there is a proof for a goal , then there is
a proof no matter in which order the reductions are made . In terms of the proof
tree , this means that the order of branch es is irrelevant .
Input : son(lot ,haran )? and Program 1.2

Resolvent is not empty
Choose son (lot ,haran ) (the only choice)
Chooseson(lot ,haran) +- father (haran,lot ), male(lot ).
New resolvent is father (haran,lot ), male(lot )?
Choosefather (haran,lot )
Choosefather (haran,lot ).
New resolvent is male(lot )?
Choosemale(lot )
Choose male(lot ).
New resolvent is empty
Output : yes
Figure 1.2: Tracing the interpreter
son(lot ,haran)
/ \
father (haran,lot ) male(lot )
Figure 1.3 : A simple proof tree
In contrast , the choice of the clause and a suitable ground instance is critical
. In general , there are several choices of a clause, and infinitely many ground
instances . The choice is made non determinist ically . The concept of nondeterministic
choice is used in the definition of many computation models , e.g. finite
automata and Turing machines , and proves to be a powerful theoretical concept .
A nondeterministic choice is an unspecified choice from a number of alternatives ,
which is supposedto be made in a "clairvoyant" way: if only some of the alternatives
lead to a successfulcomputation (in our case, to finding a proof ), then
one of them is chosen. Formally , the concept is defined as follows : a computation
that contains nondeterministic choices is defined to succeed if there is a sequence
of nondeterministic choices that lead to success . Of course , no real machine can
implement directly this definition . However , it can be approximated in a useful
way, as done in Prolog , and explained in Chapter 6.
The interpreter given in Figure 1.1 can be extended to answer nonground
existential queries by an initial additional step : guess a ground instance of the
query . This is identical to the step in the interpreter of guessing ground instances
1.9 The meaning of a logic program 15
of the rules . It is difficult in general to guess the correct ground instance , since
that means knowing the result of the computation before performing it .
A new concept is needed to lift the restriction to ground instances and remove
the burden of guessing them . We show in Chapter 4 how the guess of ground instances
can be eliminated , and introduce the computation model of logic programs
more fully . Until then it is assumed that the correct choices can be made .
An important measure provided by proof trees is the number of nodes in the
tree . It indicates how many reduction steps are performed in a computation . We
use the measure as a basis of comparison between different programs in Chapter
3.
1.9 The meaning of a logic program
How can we know if a logic program says what we wanted it to say? If it

is correct , or incorrect ? In order to answer such questions , we have to define
what is the meaning of a logic program . Once defined , we can now examine if the
program means what we have intended it to mean .
Definition : The meaning of a logic program P, M (P) , is the set of ground
unit goals deducible from P . .
From this definition it follows that the meaning of a logic program composing
just of ground facts , such as Program 1.1, is the program itself . In other words , for
simple programs , the program "means just what it says." Consider Program 1.1
augmented with the two rules defining the parent relation . What is its meaning ?
It contains , in addition to the facts on fathers and mothers , mentioned explicitly
in the program , also all facts of the form parent (X , Y) , for every pair X and Y such
that father (X , Y) or mother (X , Y) is in the program . This example shows that the
meaning of a program contains explicitly whatever the program states implicitly .
Assuming that we define the intended meaning of a program also to be a
set of ground unit goals , we can ask what is the relationship between the actual
and the intended meanings of a program . We can check whether everything the
program says is correct , or whether the program says everything we wanted it to
say.
Informally , we say that a program is correct with respect to some intended
meaning Mifthe meaning of P , M (P) , is a subset of M . That is , a correct program
does not say things that were not intended . A program is complete with respect
to M if M is a subset of M ( P) . That is , a complete program says everything that
is intended . It follows that a program P is correct and complete with respect to
an intended meaning Mif M = M (P ) .
Throughout the book , when meaningful predicate and constant names are
used , the intended meaning of the program is assumed to be the one intuitively
implied by the choice of names .
For example , the program for the son relation containing only the first axiom
that uses father is incomplete with respect to the intuitively understood intended
meaning of son , since it cannot deduce son ( isaac , sarah ) . If we add to it the rule
son ( X ,Y ) +- motherY , X ) , male (Y ) .
it would make the program incorrect with respect to the intended meaning , since
it deduces son( sarah, isaac) .
The notions of correctness and completeness of a logic program are studied
further in Chapter 5.
Although the notion of truth is not defined fully here , we will say that a
ground goal is true with respect to an intended meaning if it is a member of it ,
and false otherwise . We will say it is simply true if it is a member of the intended
meaning implied the names of the predicate and constant symbols appearing in
the program .
1.10 Summary
We conclude this section with a summary of the constructs and concepts

introduced , ruling in the remaining necessary definitions .
The basic structure in logic programs is a term . A term is a constant , a

variable or a compound term . Constants denote particular individuals such as
integers and atoms , while variables denote a single but unspecified individual .
The symbol for an atom can be any sequence of characters , which is quoted if
there is possibility of confusion with other symbols (such as variables or integers ) .
Symbols for variables are distinguished by beginning with an uppercase letter .
A compound term comprises a functor (called the principal functor of the
term ) and a sequence of one or more terms called arguments . A functor is char-
acterized by its name, which is an atom , and its arity or number of arguments .
Constants are considered functors of arity O. Syntactically , compound terms have
the form f ( tl ,t2,. . .,tn ) where the functor has name f and is of arity n, and the
~ 's are the arguments . A functor f of arity n is denoted fin . Functors with the
same name but different arities are distinct . Terms are ground if they contain no
1.10 Summary 17
variables ; otherwise they are . nonground . Goals are atoms or compound terms ,
aJld are generally nonground .
A substitution is a finite set (possibly empty) of pairs of the form X = t, where

X is a variable and t is a term , with no two pairs having the same variable as
left -haJld side. For any substitution ()= { Xl = 4 ,X2= t2,. . .,Xn = tn} and term s, the
term s() denotes the result of simultaneously replacing in s each occurrence of the
variable Xi by ~ , 1 ~ i ~ n; the term sOis called aJl instance of s.
A logic program is a finite set of clauses. A clause or rule is a universally
quantified logical sentence of the form
A +- B1 , B2 , . . .,Bk . k ~ 0,
where A and the Bi ' S are goals . Such a sentence is read declaratively " A is implied
by the conjunction of the Bi ' s , " and is interpreted procedurally " to answer query
A , answer the conjunctive query Bl , B2 , . . . , Bk . " A is called the clause ' s head and
the B ' s the clause ' s body . If k = O , the clause is known as a fact or unit clause
and written - A . , meaning A is true under the declarative reading , and goal A is
satisfied under the procedural interpretation . If k = l , the clause is known as an
iterative clause .
A query is a conjunction of the form
AI , . . . , An ? n > 0 ,
where the Ai ' S are goals . Variables in a query are understood to be existentially
quantified .
A computation of a logic program P finds an instance of a given query logically
deducible from P . A goal G is deducible from a program P if there is an instance
A of G where Ai - B1 , . . . , Bn , n ~ 0 , is a ground instance of a clause in P , and the
Bi ' s are deducible from P . Deduction of a goal from an identical fact is a special
case .
The meaning of a program P is inductively defined using logical deduction .
The set of ground instances of facts in P are in the meaning . A ground goal G
is in the meaning if there is a ground instance G + - B1 , . . . , Bn of a rule in P such
that Bl , . . . , Bn are in the meaning . The meaning consists of the ground instances
that are deducible from the program .
An intended meaning M of a program is also a set of ground unit goals . A
program P is correct with respect to an intended meaning M if M ( P ) is a subset
of M . It is complete with respect to M if M is a subset of M ( P ) . Clearly , it is
correct and complete with respect to its intended meaning , which is the desired
situation , if M = M ( P ) .
A ground goal is true with respect to an intended meaning if it is a member

of it , and false otherwise .
Logical deduction is defined syntactically here , and hence also the meaning
of logic programs . In Chapter 5 alternative ways of describing the meaning of
logic programs are presented , and their equivalence with the current definition is
discussed.
Chapter 2
Database Programming
There are two basic styles of using logic programs : defining a logical database ,
and manipulating data structures . This chapter discuss es database programming .
A logic database is comprised of a set of facts and rules . We show how a set of
facts can define relations , as in relational databases . We show how rules can define
complex relational queries , as in relational algebra . Together , a logic program
composed of a set of facts and rules of a rather restricted format can express the
functionalities associated with relational databases .
2.1 Simple databases
We begin by revising Program 1.1, the biblical database , and its augmentation
with rules expressing family relationships . The database itself had four basic
predicates , father / 2, mother / 2, male/ l , and female / l . We adopt a convention
from database theory and give for each relation a relation scheme that specifies
the role that each position in the relation (or argument in the goal ) is intended
to represent . Relation schemes for the four predicates here are, respectively ,
father (Father , Child) , mother (Mother , Child) , male (Person ) , and female (Person ) .
The mnemonic names are intended to speak for themselves .
We adopt the typo graphic convention that relation schemes are given in italics
. Variables are given mnemonic names in rules , but usually X or Y when
discussing queries . Multiword names are handled differently for variables and
predicates . Each new word in a variable is started with a capital letter , for example
, Niece Or Nephew, while words are delimited by underscores for predicate and
function name , for example , schedule_conflict .
New relations are built from these basic relationships by defining suitable
rules . Appropriate relation schemes for the relations introduced in the previous
20 DatabageProgramming 2.1
abraham : fisaac . abraham # haran . abraham # lot .

abraham : fmilcah . abraham # yiscah . isaac# haran .
isaac # lot . isaac# milcah . isaac# yiscah .
haran # lot . haran # milcah . haran # yiscah .
lot # milcah . lot # yiscah . milcah # yiscah .
Figure 2 .1: Defining inequality
chapter are son ( Son , Parent ) , daughter ( Daughter , Parent ) , parent ( Parent , Child ) ,
and grandparent ( Grandparent , Grandchild ) . From the logical viewpoint , it is unimportant

which relationships are defined by facts and which by rules . For example ,
if the available database consisted of parent , male and female facts , the rules
defining son and grandparent are still correct . New rules must be written for the
relationships no longer defined by facts , namely father and mother . Suitable rules
are :
father ( Dad , Child ) +- parent ( Dad , Child ) , male ( Dad ) .
mother ( Mum , Child ) +- parent ( Mum , Child ) , female ( Mum ) .
Interesting rules can be obtained by making relationships explicit that are
present in the database only implicitly . For example , since we know the father
and mother of a child , we know which couples produced offspring , or to use a
Biblical term , procreated . This is not given explicitly in the database but a
simple rule can be written recovering the information . The relation scheme is
procreated ( Man , Woman ) .
procreated ( Man , Woman ) +- father ( Man , Child ) , mother ( Woman , Child ) .
This reads : " Man and Woman procreated if there is a Child such that Man is the
father of Child and Woman is the mother of Child ."
Another example of information that can be recovered from the simple information
present is sibling relationships - brothers and sisters . We give a rule for
brother ( Brother , Sibling ) .
brother ( Brother , Sib ) +-
parent ( Parent , Brother ) , parent ( Parent , Sib ) , male ( Brother ) .
This reads : " Brother is the brother of Sib if Parent is a parent of both Brother
and Sib , and Brother is male ."
There is a problem with the definition of brother given above . The query
brother ( X ,X ) ? is satisfied for any male child X , which is not our understanding of
the brother relationship .

2.1 Simple databages 21
uncle(Uncle,Person) +-
brother (Uncle,Parent), parent(Parent,Person).
sibling(Sibl ,Sib2) +-
parent(Parent,Sibl ), parent (Parent,Sib2), Sibl # Sib2.
cousin(Cousinl ,Cousin2) +-
parent (Parentl ,Cousinl ),
parent (Parent2,Cousin2) ,
sibling(Parentl ,Parent2).
Program 2. 1: Defining family relationships
In order to preclude such cases from the meaning of the program we introduce
a predicate # ( Terml , Term2 ) . It is convenient to write this predicate as an infix
operator . Thus Terml # Term2 is true if Terml and Term2 are different . For the
present it is restricted to constant terms . It can be defined , in principle , by a
table X # Y for every two different individuals X and Y in the domain of interest .
Figure 2.1 gives the appropriate table for Program 1.1.
The new brother rule is
brother (Brother ,Sib) +-

parent (Parent,Brother ),
parent (Parent,Sib),
male(Brother ),
Brother =1=Sib.
The more relationships that are present , the easier it is to define complicated
relationships . Program 2.1 defines the relations uncle ( Uncle,Niece Or Nephew) ,
sibling (Sib1,Sib2) , and cousin ( Cousin1 , Cousin2 ) . More examples are posed as
exercises at the end of the section .
Another relationship implicit in the family database is whether a woman is

a mother . This is determined by using the mother / 2 relationships . The new
relationship scheme is mother ( Woman ) , and is defined by the rule :
mother (Woman ) t - mother (Woman ,Child ) .
This reads : A Woman is a mother if she is the mother of some Child . Note that
we have used the same predicate name , mother , to describe two different mother
relationships . The mother predicate takes a different number of arguments , i .e.,
has a different arity , in the two cases. In general the same predicate name denotes
a different relationship when it has a different arity .
22 Database Programming 2.1
Power
n3
I 0
n5
, 0
Figure 2.2: A logical circuit
We change examples , lest the example of family relationships become incestuous

, and consider describing simple logical circuits . A circuit can be viewed
from two perspectives . The first is the topological layout of the physical components
usually described in the circuit diagram . The second is the interaction of
functional units . Both views are easily accommodated in a logic program . The
circuit diagram is represented by a collection of facts , while rules describe the
functional components .
Program 2.2 is a database giving a simplified view of the logical and-gate

drawn in Figure 2.2. The facts are the connections of the particular resistors
and transistors comprising the circuit . The relation schemefor resistors is resistor
(End1,End2) and for transistors transistor(Gate,Source,Drain) .
The program demonstrates the style of commenting of logic programs we will
follow throughout the book . Each interesting procedure is preceded by a relation
scheme for the procedure , and English text defining the relation . We recommend
2.1 Simple databases 23
resistor (power ,nl ) .

resist or (power ,n2 ) .
transistor (n2 ,ground ,nl ) .
transistor (n3 ,n4 ,n2) .
transistor (n5 ,ground ,n4) .
inverter ( Input , Output ) +-

Output is the inversion of Input .
inverter (Input ,Output ) +-

transistor (Input ,ground ,Output ) ,
resistor (power ,Output ) .
nand _gate( Inputl , Input2 , Output ) +-

Output is the logical nand of Inputl and Input2 .
nand _gate (Inputl ,Input2 ,Output ) +-

transistor (Inputl ,X ,Output ) ,
transistor (Input2 ,ground ,X ) ,
resistor (power ,Output ) .
and_gate(Inputl ,Input2 , Output ) +-

Output is the logical and of Inputl and Input2 .
and_gate(Inputl ,Input2 ,Output ) +-

nand_gate(Inputl ,Input2 ,X ) ,
inverter (X ,Output ).
Program 2.2: A circuit for a logical and_gate
this style of commenting , which emphasizes the declarative reading of programs ,

for Prolog programs as well .
Particular configurations of resistors and transistors fulfill roles captured via

rules defining the functional components of the circuit . The circuit describes an
and-gate , which takes two input signals and produces as output the logical and of
these signals . One way of building an and-gate , and how this circuit is composed ,
is to connect a nand -gate with an inverter . Relation schemes for these three com-
ponents are and_gate(Input1,Input2, Output), nand _gate( Inputl ,Input2 , Output ) ,
and inverter(Input , Output).
To appreciate Program 2.2, let us read the inverter rule . This states that an
inverter is built up from a transistor with the source connected to the ground , and
a resistor with one end connected to the power source . The gate of the transistor
- - - - o -~ 1 - - - - . 0-
Figure 2.3: An or-gate
is the input to the inverter , while the free end of the resistor must be connected
to the drain of the transistor , which forms the output of the inverter . Sharing of
variables is used to insist on the common connection.
Consider the query and_gate(Inl ,Inf ,Out) ? to Program 2.2. It has the solution
{ Inl = n9,Inf = nS,Out= nl } . This solution confirms that the circuit described
by the facts is an and-gate, and indicates the inputs and output .
Exercises for Section 2.1
(i ) Modify the rule for brother to give a rule for sister , the rule for uncle to give
a rule for niece, and the rule for sibling so that it only recognizes full siblings ,
i .e., those that have the same mother and father .
(ii ) Using a predicate married _couple( Wile ,Husband) , define the relationships :
mother _in _law, brother -in _law, and son_in _law.
(iii ) Describe the logical circuit for an or -gate depicted in Figure 2.3 using a
logic program like Program 2.2. Extend the program to a nor -gate using an
inverter .
2.2 Structured data and data abstraction 25
2 .2 Structured data and data abstraction
A limitation of Program 2.2 for describing the and- gate is the treatment of
the circuit as a black box . There is no indication of the structure of the circuit in
the answer to the and_gate query , even though the structure has been implicitly
used in finding the answer . The rules tell us that the circuit represents an and-
gate , but the structure of the and-gate is present only implicitly . We remedy this
by adding an extra argument to each of the goals in the database . For uniformity ,
the extra argument becomes the first argument . The base facts simply acquire
an identifier . Proceeding from left to right in the diagram of Figure 2.2, we label
the resistors rl and r2 , and the transistors tl , t2 and t3 .
Names of the functional components should reflect their structure . An inverter
is composed of a transistor and a resistor . To represent this , we need
structured data . The technique is to use a compound term , inv ( T,R) , where T
and R are the respective names of the inverter 's component transistor andresis -
tor . Analogously , the name of a nand - gate will be nand ( Tl , T2,R) , where Tl , T2
and R name the two transistors and resistor that comprise a nand -gate . Finally ,
an and -gate can be named in terms of an inverter and a nand -gate . The modified
code containing the names appears in Program 2.3.
The query and_yate( G,In1 ,Inf , Out ) ? has solution { G= and(nand (tf ,t9,rf ) ,
inv (t1,r1 ) ),In1 = n9,Inf = n5, Out = ni } . In1 , Inf , and Out have their previous values
. The complicated structure for G reflects accurately the functional composition
of the and-gate .
Structuring data is important in programming in general and in logic programming

in particular . It is used to organize data in a meaningful way . Rules
can be written more abstractly , ignoring irrelevant details . More modular programs
can be achieved this way, as a change of data representation need not mean
a change in all the program , as shown by the following example .
Consider the following two ways of representing a fact about a lecture course
on complexity given on Monday from 9 to 11 by David Harel in the Feinberg
building , room A :
course (complexity ,monday ,9,11,david ,harel ,feinberg ,a) .
and
course ( complexity ,time (monday ,9,11) ,lecturer (david ,harel ) ,

location (feinberg ,a)) .
The first fact represents course as a relationship between eight items - a course
name , a day, a starting hour , a finishing hour , a lecturer 's first name , a lecturer 's
resistor(R,N odel,Node!!) +-
R is a resistor between N odel and Node !! .
resistor(r 1,power,nl ).
resistor(r2,power,n2).
transistor( T, Gate,Source,Drain ) +-
T is a transistor whose gate is Gate ,
source is Source , and drain is Drain .
transistor (tl ,n2,ground,nl ) .

transistor (t2 ,n3,n4,n2).
transistor (t3 ,n5,ground,n4).
inverter (I ,Input , Output) +-
I is an inverter which inverts Input to Output .
inverter (inv (T ,R),Input ,Output ) +-

transistor (T ,Input ,ground,Output ),
resistor(R,power,Output ).
nand_gate(N and,Inputl ,Input !!, Output) +-
Nand is a gate forming the logical nand , Output ,
of Inputl and Input !!.
nand-gate(nand(Tl ,T2,R) ,Inputl ,Input2 ,Output ) +-

transistor (Tl ,Inputl ,X ,Output ) ,
transistor (T2,Input2 ,ground,X ),
resistor (R,power,Output ).
and-gate(And,Inputl ,Input2, Output) +-
And is a gate forming the logical and , Output ,
of Inputl and Input2 .
and_gate(and(N ,1) ,Inputl ,1nput2,Output ) +-

nand_gate(N ,Inputl ,Input2 ,X ),
inverter (1,X ,Output ).
Program 2 .3 : The circuit database with names
surname , a building , and a room . The second fact makes course a relationship
between four items - a name , a time , a lecturer , and a location with further
qualification . The time is composed of a day , a starting time and a finishing
time , lecturers have a first name and a surname , and locations are specified by
a building and a room . The second fact reflects more elegantly the relationships
2.2 Structured data and data abstraction 27
lecturer (Lecturer ,Course) +-

course(Course,Time,Lecturer ,Location) .
duration (Course,Length) +-
course(Course,time (Day,Start ,Finish) ,Lecturer ,Location ),
plus(Start ,Length,Finish).
teaches(Lecturer ,Day) +-
course(Course,time (Day,Start ,Finish ) ,Lecturer ,Locati,on) .
occupied(Room,Day,Time) +-
course(Course,time (Day,Start ,Finish ) ,Lecturer ,Room),
Start :::; Time , Time :::; Finish .
Program 2.4: Course rules
that hold .
The four argument version of course enables more concise rules to be written
by abstracting the details which are irreleva J}t to the query . Program 2.4 is
comprised of some examples . The occupied rule assumes a predicate less thaJ} or
equal , represented aB a binary infix operator ~ .
Rules not concerning with the particular values of a structured argument
need not "know " how the argument is structured . For example , the rules for
duration and teaches represent time explicitly as time (Day ,Start ,Finish ) because
the Day or Start or Finish times of the course are desired . In contrast , the rule
for lecturer does not . This leads to greater modularity , as the representation of
time can be changed without affecting the rules that do not inspect it .
We do not have definite rules to decide whether to use structured data or
not . Not using structured data allows a uniform representation where all the data
are simple . The advantages of structured data are compactness of representation
which more accurately reflects our perspective of a situation , and modularity . We
can relate the discussion to conventional programming languages . Facts are the
counterpart of tables , while structured data correspond to records with aggregate
fields .
We believe that the appearance of a program is important , particularly when

attempting difficult - problems . A good structuring of data can make a difference
when programming complex problems .
Some of the rules in Program 2.4 are recovering relationships between two
individuals , binary relationships , from the single , more complicated one. All the
course information could have been written in terms of binary relationships as
28 DatabaseProgramming 2.2
follows :
day (complexity ,monday ) .

start _time (complexity ,9) .
finish _time ( complexity ,11) .
lecturer ( complexity ,harel ) .
building (complexity ,feinberg ) .
room (complexity ,a) .
Rules would then be expressed differently , reverting to the previous style of making
implicit connections explicit . For example ,
teaches ( Lecturer , Day ) + -
lecturer ( Course , Lecturer ) , day ( Course , Day ) .
Add rules defininf ?; the relationships location ( Course , Building ) , busy ( Lecturer ,
Time ) and cannot _ meet ( Lecturerl , Lecturer2 ) . Assume course facts as above .
Possibly using relationships from Exercise ( i ) , define the relationship schedule
_ conflict ( Time , Place , Course1 , Course2 ) .
to the family relationship rules to represent the
relationship , e . g . , father ( X , Y , pa ( X , Y ) ) .
Follow the example of the circuit database . )
Design a small database for an application of your own choice . Use a single
predicate to express the information , and invent suitable rules .
2 .3 Recursive rules
The rules described so far define new relationships in terms of existing ones.
An interesting extension is recursive definitions of relationships which define relationships
in terms of themselves . One way of viewing recursive rules is as gen-
eralization of a set of nonrecursive rules .
Consider a series of rules defining ancestors - grandparents , greatgrandpar -

ents , etc :
grandparent (Ancestor ,Descendant ) ~

parent (Ancestor ,Person ) , parent (Person ,Descendant ) .
great grandparent (Ancestor ,Descendant ) ~
2.3 Recursive rules 29
parent ( Ancestor , Person ) , ' grandparent ( Person , Descendant ) .
gre at great grandparent ( Ancestor , Descendant ) ~
parent ( Ancestor , Person ) , great grandparent ( Person , Descendant ) .
A clear pattern can be seen , which can be expressed in a rule defining the relationship
of ancestor ( Ancestor , Descendant ) :
ancestor ( Ancestor , Descendant ) i - -
parent ( Ancestor , Person ) , ancestor ( Person , Descendant ) .
This rule is a generalization of the rules above .
A logic program for ancestor also requires a nonrecursive rule , the choice
of which affects the mea J1ing of the program . If the fact ancestor ( X , X ) is used ,
defining the ancestor relationship to be reflexive , people will be considered to be
their own a J1cestors . This is not the intuitive mea J1ing of a J1cestor . Program 2 . 5 is
a logic program defining the a J1cestor relationship , where parents are considered
a J1cestors .
The ancestor relationship is the transitive closure of the parent relationship .
In general finding the transitive closure of a relationship is easily captured in a
logic program , by using a recursive rule .
Consider the problem of testing connectivity in a directed graph . A directed
graph can be represented as a logic program by a collection of facts . A fact
edge ( Nodel , Node2 ) is present in the program if there is an edge from Nodel to
Node2 in the graph . Figure 2 . 4 gives a graph , while Program 2 . 6 is its description
as a logic program .
Two nodes are connected if there is a series of edges that can be traversed
to get from the first node to the second . That is , the relationship connected
( Nodel , Node2 ) , which is true if Nodel and Node2 are connected , is the
transitive closure of the edge relationship . For example , a and e are connected in
the graph in Figure 2 . 4 , but b and fare not . Program 2 . 7 defines the relationship .
The meaning of the program is the set of goals connected ( X , Y ) , where X and Y
are connected . Note that connected is a transitive reflexive relationship , due to
the choice of base fact .
Exercises for Section 2 .3
(i) A stack of blocks can be described by a collection of facts on(Blockl ,

Block2 ) , which is true if Blockl is on Block2 . Define a predicate
above(Blockl , Block2 ) that is true if Blockl is above Block2 in the stack .
(Hint : Above is the transitive closure of on.)
30 DatabaBeProgramming 2.4
ancestor ( Ancestor , Descendant ) +-

Ancestor is an ancestor of Descendant .
ancestor ( Ancestor ,Descendant ) +-

parent ( Ancestor , Descendant ) .
ancestor ( Ancestor ,Descendant ) +-

parent ( Ancestor , Person ) , ancestor ( Person ,Descendant ).
Program 2 .5 : The ancestor relationship
edge ( a ,b ) . edge ( a ,c ) . edge ( bid ).

edge ( c ,d ) . edge ( d ,e ) . edge ( fig ) .
Program 2 .6 : A directed graph
connected ( N odel , N ode2 ) T -

N ode1 is connected to N ode2 in the
graph defined by the edge / 2 relation .
connected ( N ode , N ode ) .
connected ( Nodel ,Node2 ) 1- edge ( Nodel , Link ) , connected ( Link ,Node2 ).
Program 2 .7 : The transitive closure of the edge relationship
a - + b f
~ ~ ~
c - + d - + e g
Figure 2 .4 : A simple graph
2 .4 Logic programs and the relational database model
Logic programs can be viewed as a powerful extension to the relational

database model , the extra power coming from the ability to specify rules . Many
of the concepts introduced have meaningful analogues in terms of databases . The
converse is also true . The basic operations of the relational algebra are easily
expressed within logic programming .
Procedures composed solely of facts correspond to relations , the arity of the

relation being the arity of the procedure . Five basic operations define the relational
algebra : union , set difference , Cartesian product , projection and selection .
We show how each is translated into a logic program .

2.4 Logic programs aJld the relational database model 31
The union operation creates a relation of arity n from two relations r and 8,
hoth of aritv n. The new relation . denoted here r _union _8. is the union of r and
v .
8. It is defined directly as a logic program by two rules :

r_uniOn_S(Xl ,' . .,Xn) +- r(Xl ,' . .,Xn ).
r _union_s(xi ,. . .,Xn) +- S(Xl ,. . .,Xn ).
Set difference involves negation . We assume a predicate not . Intuitively , a

goal not G is true with respect to a program P if G is not a logical consequence of
P. Negation in logic programs is discussed in Chapter 5, where limitations of the
intuitive definition are indicated . The definition is correct , however , if we only
deal with ground facts , as is the case with relational databases .
The definition of T_diff -s of arity n where Talld s are of arity n is
r_diff-s(Xl ," .,Xn ) +- r(Xl ,' . .,Xn), not S(Xl ,. . .,Xn).

r _diff-s(xi ,. . .,Xn ) +- s(xi ,. . .,Xn) , not r (Xl ,. . .,Xn).
Cartesian product can be defined in a single rule . If r is a relation of arity

m, and s is a relation of arity n, then r - x- s is a relation of arity m + n defined by
r _X_S(xi ,. . .,Xm,Xm+l ," .,Xm+n) +- r(xi ,. . .,Xm), S(Xm+ l ," " Xm+n) '
Projection involves forming a new relation comprising only some of the attributes
of an existing relation . This is straightforward for any particular case.
For example , the projection r19 selecting the first and third arguments of a relation
of arity 9 is
r19(Xl ,X3) +- r(Xl ,X2,X3).
Selection is similarly straightforward for any particular case. Consider a

relation consisting of tupies whose third components are greater than their second ,
and a relation where the first component is Smith or Jones . In both cases a relation
r of arity 3 is used to illustrate . The first example creates a relation rl :
rl (xi ,X2,X3) +- r(Xl ,X2,X3),X2 > X3.
The second example creates a relation r2 , which requires a disjunctive relationship ,

smith _or _lones :
r2(xi ,X2,X3) +- r(xi ,X2,X3), smith_or_lones(xi ).
smith-or_lones(smith).
smith_or_lones(lones).
Some of the derived operations of the relational algebra are more closely
related to the constructs of logic programming . We mention two , intersection
32 Database
Programming 2.4
and the natural join . If r and 8 are relations of arity n, the intersection , r _meet_8
is also of arity n and is defined in a single rule .
r - meet_s(X I Jo. oJXn) +- r (X I Jo. oJXn) , S(X I Jo. oJXn) o
A natural join is precisely a conjunctive query with shared variables .
2.5 Background
Readers interested in pursuing the connection between logic programming

and database theory are referred to the many papers that have been written on the
subject . A good starting place is the review paper by Gallaire et al . ( 1984) . There
are earlier papers on logic and databases in Gallaire and Minker ( 1978) . Another
interesting book is about the implementation of a database query language in
Prolog (Li , 1983) . Our discussion of relational databases follows Ullman (1982) .
Another good account of relational databases can be found in Maler (1983) .
In general , an nary relation can be replaced by n + 1 binary relations , as
shown by Kowalski (1979) . If one of the arguments forms a key for the relation ,
as does the course name in the above example in Section 2.2, n binary relations
suffice .
Chapter 3
Recursive Programming
The programs of the previous section essentially retrieve information from ,

and manipulate , finite data structures . In general mathematical power is gained
by considering infinite or potentially infinite structures . Finite instances then
follow as special cases. Logic programs harness this power by using recursive
data types .
Logical terms can be classified into types. A type is a (possibly infinite ) set
of terms. Sometypes are conveniently defined by unary relations. A relation p/ l
defines the type p to be the set of X' s such that p(X) .
For example, the malell and femalell predicates used previously define the
male and female types .
More complex types can be defined by recursive logic programs . Such types
are called recursive types. Types defined by unary recursive programs are called
simple recursive types. A program defining a type is called a type definition .
In this chapter we show logic programs defining relations over simple recursive
types , such as integers , lists and binary trees , and also programs over more
complex types , such as polynomials .
3 .1 Arithmetic
The simplest recursive data type , natural numbers , arises from the foundations
of mathematics . Arithmetic is based on the natural numbers . This section
gives logic programs for performing arithmetic .
In fact , Prolog programs for performing arithmetic differ consider ably from
their logical counterparts , as we will see in later chapters . However , it is useful to
34 Recursive Programming 3.1
natural _number (X) +-

X is a natural number .
natural -ilumber (O) .

natural -ilumber (s(X )) +- natural -ilumber (X ) .
Program 3 . 1: Defining the natural numbers
spend time discussing the logic programs . There are two main reasons . Firstly ,
the operations of arithmetic are usually thought of functionally rather than relationally
. Presenting examples for such a familiar area emphasizes the change in
thinking necessary for composing logic programs . Second, it is more natural to
discuss the underlying mathematical issues, such as correctness and completeness
of programs .
The natural numbers are built from two constructs , the constant symbol
0 and the successor function 8 of arity 1. All the natural numbers are then
recursively given as 0, 8( 0) , 8(8(0) ) , 8(8(8(0))) , . . .. We adopt the convention that
8n( 0) denotes the integer n, that is , n applications of the successor function to O.
As in the previous chapter , we give a relation scheme for each predicate ,
together with the intended meaning of the predicate . Recall that a program P is
correct with respect to an intended meaning M if the meaning of P is a subset of
M . It is complete if M is a subset of the meaning of P . It is correct and complete
if its meaning is identical to M . Proving correctness establish es that everything
deducible from the program is intended . Proving completeness establish es that
everything intended is deducible from the program . Two typical correctness and
completeness proofs are given in this section .
The simple type definition of natural numbers is neatly encapsulated in the
logic program , Program 3.1. The relation scheme used is natural _number (X) , with
intended meaning that X is a natural number . The program consists of one unit
clause and one iterative clause (a clause with a single goal in the body ) . Such a
program is called minimal recursive .
Proposition : Program 3.1 is correct and complete with respect to the set
of goals natural _number ( si (D) ) , for i :?: D.
-i ~:,:Proof : ( 1) Completeness . Let Nbe a natural number . We show that the goal
~atural _number ( N) is deducible from the program by giving an explicit proof tree .
Either N is 0 or of the form sN ( 0) . The proof tree for the goal natural _number ( 0)
is trivial . The " proof tree for the goal natural _numbers (. . .s( 0) . . .) ) contains N
r J J Uctions, using the rule in Program 3.1, to reach the fact natural _number ( O) , as
isrshown in the left half of Figure 3.1.
3.1 Arithmetic 35
natural ..number(sn(o) ) plus(sn(0),sm(0),sn+m(o))
. .
I I
IIlumber
natural ..number(sn- l (0)) pIUS
(sn- l (0),sm(o),Sn+m- l (0))
natural
-
i (
8(
0
)
I I
natural
-ilumber
(O
)
Figure 3 . 1: Proof trees establishing completeness of programs
(2) Correctness. Supposethat natural_number(X) is deducible from Program

3.1, in n deductions. We prove that natural-number(X) is in the intended meaning
of the program by induction on n. If n = O, then the goal must have been proved
using a unit clause, which implies that X = O. If n > 0, then the goal must be
of the form natural_numbers (Xl )) , since it is deducible from the program, and
further natural_number(Xl ) is deducible in n- l deductions. By the induction
hypothesis, Xl is in the intended meaning of the program, i .e. Xl = sk(0) for some
k ~ O. .
The natural numbers have a natural order . Program 3.2 is a logic program
defining the relationship less than or equal to according to the order . We denote
the relationship with a binary infix symbol, or operator, $ according to mathematical
usage. The expression0 $ X is nonethelessa term with functor $ / 2, and
arguments 0 and X , and is syntactically equivalent to '$ '(O,X) .
The relation scheme is Nl ~ N2 . The intended meaning of Program 3.2 is
all ground facts X ~ Y where X and Yare natural numbers and X is less than or
equal to Y. Exercise (ii ) at the end of the section is to prove the correctnessand
completeness of Program 3.2.
The recursive definition of ~ is not "computationally efficient ." The proof
tree establishing that a particular Nis less than a particular Mhas M + f! nodes .
We usually think of testing whether one number is less than another as a unit
operation , independent of the size of the numbers . Indeed Prolog does not define
arithmetic according to the axioms presented in this section , but uses the
underlying arithmetic capabilities of the computer directly .
36 RecursiveProgramming 3.1
X : 5Y ~
X and Yare natural numbers ,
such that X is less than or equal to Y.
0 ~ X +- natural -ilumber (X ).
s(X ) ~ s(Y ) +- X ~ Y .
natural Jlumber (X ) +- SeeProgram 3.1
Program 3 .2 : The less than or equal relation
plus(X , Y,Z) f0-

X , Yand Z are natural numbers ,
such that Z is the sum of X and Y .
plus(O,X ,X ) -+- natural ..:number(X ) .

plus(s(X ),Yis (Z)) -+- plus(X ,Y ,Z).
naturaI J1umber(X ) +- SeeProgram 3.1
Program 3.3 : Addition
Addition is a basic operation defining a relationship between two natural

numbers and their sum . In Section 1.1 a table of the plus relationship was assumed
for all relevant natural numbers . A recursive program captures the relationship
elegantly and more compactly , and is given as Program 3.3. The intended meaning
of Program 3.3 is the set of facts plus (X , Y,Z) where X , Y and Z are natural
numbers and X + Y = Z.
Proposition : Programs 3.1 and 3.3 constitute a correct and complete ax-
iomatization of addition , with respect to the standard intended meaning of plus/ So
Proof : ( 1) Completeness . Let X , Y, and Z be natural numbers such that
X + Y= Z. We give a proof tree for the goal plus {X , Y,Z) . If X equals 0, then Y
equals Z. Since Program 3.1 is a complete axiomatization of the natural numbers ,
there is a proof tree for natural _numberY ) , which is easily extended to a proof
tree for plus ( 0, Y, Y) . Otherwise , X equals sn ( 0) for some n. If Y equals sm( 0) ,
then Z equals sn+m ( o) . The proof tree in the right half of Figure 3.1 establish es
completeness .
(2) Correctness . Let plus (X , Y,Z) be in the meaning . A simple inductive
argument on the size of X , similar to the one used in the previous proposition ,
establish es that X + Y = z . .
Addition is usually considered to be a function of two arguments rather than
a three place relation . Generally logic programs corresponding to functions of
3.1 Arithmetic 37
n arguments define n + 1 place .relations . Computing the value of a function is

achieved by posing a query with n arguments instantiated and the argument
place corresponding to the value of the function uninstantiated . The solution to
the query is the value of the function with the given arguments . To make the
analogy clearer , we give a functional definition of addition corresponding to the
logic program .
0+ X = x .
s(X ) + Y = s(X + Y ) .
One advantage that relational programs have over functional programs is

the multiple uses that can be made of the program . For example , the query
plus (s(O) ,s( O) ,s(s(O) )) ? means checking whether 1+ 1= 2. (We feel free to use
the more readable decimal notation when mentioning numbers .) As for :::;, the
prog Tam for plus is not efficient . The proof tree confirming that the sum of Nand
Mis N + Mhas N + M + 2nodes .
Posing the query plus (s( O) ,s( O) ,X) ?, an example of the standard use, calculates
the sum of 1 and 1. However , the program can just ~ e~ ily be used
for subtraction by posing a query such ~ plus (s( O) ,X ,s(s(s( O) )) ) ? The computed
value of X is the difference between 3 and 1, namely 2. Similarly asking a query
with the first argument uninstantiated , and the second and third instantiated ,
also performs subtraction .
A more novel use exploits the possibility of a query having multiple solutions .
Consider the query plus (X , Yis (s(s( O)) ) ) ? It reads : "Do there exist numbers X
and Y that add up to 3." In other words , find a partition of the number 3 into
the sum of two numbers , X and Y. There are several solutions .
A query with multiple solutions becomes more interesting when the properties
of the variables in the query are restricted . There are two forms of restriction :
using extra conjuncts in the query , and instantiating variables in the query . We
saw examples of this when querying a database . Exercise (ii ) at the end of this
section requires to define a predicate even(X) , which is true if X is an even number
. Assuming such a predicate , the query plus (X , YiN) , even(X) ,even( Y) ? gives a
partition of N into two even numbers . The second type of restriction is exempli -
fied by the query plus ( s( s(X) ) ,s( s( Y) ) ,N) ? which insists that each of the numbers
adding up to N is strictly greater than one.
Almost all logic programs have multiple uses. Consider Program 3.2 for ~ ,
for example . The query s( 0) ~ s( s( O) ) ? checks whether 1 is less than or equal to
2. The query X ~ s( s( O)) ? finds numbers X less than or equal to 2. It even
computes pairs of numbers less than or equal to each other with the query X ~
Y?
Program 3 .3 defining addition is not unique . For example , the logic program
plus (X ,O,X ) +- natural - number (X ) .

plus (X ,s(Y ) ,s(Z ) ) +- plus (X ,Y ,Z ) .
has precisely the same meaning as Program 3 .3 for plus . Two programs are to
be expected due to the symmetry between the first two arguments . A proof of
correctness and completeness given for Program 3 .3 applies to this program by
reversing the roles of the symmetric arguments .
The meaning of the program for plus would not change even if it consisted
of the two programs combined . This composite program is undesirable , however .
There are several different proof trees for the same goal . It is important both
for runtime efficiency and for textual conciseness that axiomatizations of logic
programs be minimal .
We define a type condition to be a call to the predicate defining the type . For
natural numbers , a type condition is any goal of the form natural _number (X) .
In practice , both Programs 3 .2 and 3 .3 are simplified by omitting the body

of the base rule , natural _number (X) . Without this test , facts such as 0 ::; a and
plus ( O, a, a) , where a is an arbitrary constant , will be in the programs ' meanings .
Type conditions are necessary for correct programs . However , type conditions
distract from the simplicity of the programs and affect the size of the proof trees .
Hence in the following we might omit explicit type conditions from the example
programs .
The basic programs shown are the building blocks for more complicated relationships
. A typical example is defining multiplication as repeated addition . Program
3 .4 reflects this relationship . The relation scheme is times (X , Y, Z) meaning
X times Y equals Z .
Exponentiation is defined as repeated multiplication . Program 3 .5 for

exp ( NiX , Y) express es the relationship that XN = y . It is analogous to Program
3 .4 for times (X , Y, Z) , with exp and times replacing times and plus , respectively .
The base cases for exponentiation are . xo = 1 for all positive values of X , and oN = 0
for positive values of N .
A definition of the factorial function uses the definition of multiplication .

Recall that N ! = N .( N - 1) . . . . .2 .1 . The predicate factorial ( N ,F) relates a number
N to its factorial F . Program 3 .6 is its axiomatization .
Not all relationships concerning natural numbers are defined recursively . Relations
can also be defined in the style of programs in Chapter 2 . An example
is Program 3 .7 determining the minimum of two numbers via the relation minimum
( ni , N .2,Min ) .
3.1 Arithmetic 39
times(X , Y,Z) +-
X , Yand Z are natural numbers ,
such that Z is the product of X and Y.
times(O,X ,O).
times(s(X),Y ,Z) +- times(X ,Y ,W), plus(W,Y ,Z).
plus (X ,Y ,Z) +- SeeProgram 3.3
Program 3.4 : Multiplication as repeated addition
exp(NiX , Y) +-
N , X , and Yare natural numbers ,
such that Yequals X raised to the power N .
exp(s(X ),O,O).
exp(O,s(X ),s(O) ).
exp(s(N),X ,Y ) ~ exp(N ,X ,Z), times(Z,X ,Y ).
times (X ,Y ,Z) +- SeeProgram 3.4
Program 3 .5: Exponentiation as repeated multiplication
factorial (N,F) +-
F equals N factorial .
factorial (O,s(O)).
factorials (N),F) -+- factorial (N ,Fl ), times(s(N),Fl ,F).
times (X ,Y ,Z) +- SeeProgram 3.4
Program 3 .6 : Computing factorials
minimum (ni ,N2,Min ) +-

The minimum of the natural numbers ni and N2 is Min .
minimum(Nl ,N2,Nl ) +- Nl ~ N2.

minimum(Nl ,N2,N2) +- N2 ~ Nl .
Nl ~ N2 +- SeeProgram3.2
Program 3.7: The minimum of two numbers
mod ( X , Y , Z) + -
Z is the remainder of the integer division of X by Y.
mod (X ,Y ,Z ) +- Z < Y , times ( Y ,Q , W ) , plus ( W ,Z ,X ) .
Program 3 . 8a : A non - recursive definition of modulus
mod ( X , Y , Z) +-
Z is the remronder of the integer division of X by Y.
mod (X ,Y ,X ) +- X < Y .
mod (X ,Y ,Z ) +- plus (Xl ,Y ,X ) , mod (Xl ,Y ,Z ) .
Program 3 . 8b : A recursive definition of modulus
Composing a program to determine the remainder after integer division reveals

an interesting phenomenon - different mathematical definitions of the same
concept are translated into different logic programs . Programs 3 .8a and 3 .8b give
two definitions of the relation mod ( X , Y , Z) , which is true if Z is the value of X
modulo Y , or in other words Z is the remainder of X divided by Y . The programs
assume a relation < as specified in exercise (i ) at the end of the section .
Program 3 .8a illustrates the direct translation of a mathematical definition ,

which is a logical statement , into a logic program . The program corresponds to
an existential definition of the integer remainder : " Z is the value of X modY if
Z is strictly less than Y , and there exists a number Q such that X = Q . Y + Z . In
general mathematical definitions are easily translated to logic programs .
We can relate Program 3 .8a to constructive mathematics . Although seem -

ingly an existential definition , it is also constructive , due to the constructive nature
of < , plus and times . The number Q , for example , proposed in the definition
will be explicitly computed by times in any use of mod .
In contrast to Program 3 .8a , Program 3 .8b is defined recursively . It constitutes

an algorithm for finding the integer remainder based on repeated subtraction
. The first rule says that X modY is X if X is strictly less than Y . The second
rule says that the value of X modY is the same as X - Y modY . The effect of any
computation to determine the modulus is to repeatedly subtractY from X until
it becomes less than Y and hence is the correct value .
The mathematical function X mod Yis not defined when Yis zero . Neither
Program 3 .8a nor Program 3 .8b have goals mod ( X , O, Z) in their meaning for any
values of X or Z . The test of " < " guarantees that .
The computational model gives a way of distinguishing between the two

3.1 Arithmetic 41
ackermann (X , Y,A ) +-
A is the value of Ackermann 's
function for the natural numbers X and Y.
ackermann (O,N ,s(N )) .

ackermann (s(M ) ,OVal ) ~ ackermann (Mis (O) ,Val ) .
ackermann (s(M ) ,s(N ) ,Val ) ~
ackermann (s(M ) ,N ,Vail ) , ackermann (M ,Vail ,Val ) .
Program 3.9 : Ackermann '8 function
programs for mod. Given a particular X , Yand Z satisfying mod, we can compare
the size of their proof trees . In general proof trees produced with Program 3.8b
will be smaller than those produced with Program 3.8a. In that sense Program
3.8b is more "efficient ." We defer more rigorous discussions of efficiency till the
discussions on lists , where the insights gained will carryover to Prolog programs .
Another example of translating a mathematical definition directly into a logic
program is writing a program that defines Ackermann 's function . Ackermann 's
function is the simplest example of a recursive function which is not primitive
recursive . It is a function of two arguments , defined by three cases:
ackermaJln (O,N ) = N + l .
ackermaJln (M ,O) = ackermann (M - l ,l ) .
ackermann (M ,N ) = ackermann (M - l ,ackermaJln (M ,N- l )) .
Program 3.9 is a translation of the functional definition into a logic program .

The predicate ackermann (M ,N ,A ) denotes that A = ackermann (M ,N) . The third
rule involves two calls to Ackermann 's function , one to compute the value of the
second argument .
This is more cleanly expressed in the functional definition . In general functional

notation is more readable for pure functional definitions such asAcker -
mann 's function . Another example is seen in Program 3.8a. Expressing that
X = Q. Y + Z, a statement about functions , is a little awkward with relational logic
programs .
The final example in this section is the Euclidean algorithm for finding the
greatest common divisor of two natural numbers , recast as a logic program . Like
Program 3.8b , it is a recursive program not based on the recursive structure of
numbers . The relation scheme is gcd(X , Y,Z) , with intended meaning that Zis the
greatest common divisor (or gcd) of two natural numbers X and Y. It uses either
of the two programs , 3.8a or 3.8b , for mod.
gcd(X , Y,Z) ~
Z is the greatest common divisor of
the natural numbers X and Y.
gcd(X ,Y ,Gcd) +- mod(X ,Y ,Z), gcd(Y ,Z,Gcd).

gcd(X ,O,X )+- X > o.
Program 3 .10 : The Euclidean algorithm
The first rule in Program 3.10 is the logical essence of the Euclidean algorithm
. The gcd of X and Y is the same as the gcd of Y and X modY . A proof
that Program 3.10 is correct depends on the correctness of the above mathematical
statement about greatest common divisors . The proof that the Euclidean
algorithm is correct similarly rests on this result .
The second fact in Program 3.10 is the base fact . It must be specified that
Xis greater than 0 to preclude gcd( O,O,O) from being in the meaning . The gcd of
0 and 0 is not well defined .
(i ) Modify Program 3.2 for ~ to axiomatize the relations < , > , and ~ . Discuss
multiple uses of these programs .
(ii ) Prove that Program. 3.2 is a correct and complete axiomatization of ~ .
(iii ) Prove that a proof tree for the query sn( o) ~ Sffl( O) using Program 3.2 has
M + 2nodes .
(iv ) Define predicates even(X) and odd(X) for determining if a natural number is
even or odd . .
(Hint : Modify Program 3.1 for natural - number .)
(v ) Write a logic program defining the relationship fib (N ,F} to determine the
Nth Fibonacci number F .
(vi ) The predicate times can be used for computing exact quotients with queries
such as times (s(s(O)) ,X ,s(s(s(s( O) )) ) ) ? to find the result of ;, divided by 2.
The query times (8(s(O) ) ,X ,s(s(s( O) )) ) ? to find 9/ 2 has no solution . Many
applications require the use of integer division that would calculate 9/ 2 to
be 1. Write a program to compute integer quotients .
(Hint : Use repeated subtraction .)
(vii ) Modify Program 3.10 for finding the gcd of two integers so that it performs
repeated subtraction directly , rather than use the mod function .
3.2 Lists 43
(Hint : The program repeatedly subtracts the smaller number from the larger
number until the two numbers are equal.)
3 .2 Lists
The basic structure for arithmetic is the unary successor functor . Although
complicated recursive functions such a.s Ackermann 's function can be defined , the
use of a unary recursive structure is limited . This section discuss es the binary
structure , the list .
The first argument of a list holds an element , and the . second argument is
recursively the rest of the list . Lists are sufficient for most computations -
attested to by the success of the programming language LISP , which has lists
as its basic compound data structure . Arbitrarily complex structures can be
represented with lists , though it is more convenient to use different structures
when appropriate .
For lists, as for numbers, a constant symbol is necessaryto terminate recursion

. This "empty list ," referred to as nil , will be denoted here by the symbol [ ].
We also need a functor of arity two . Historically the usual functor for lists is " ."
(pronounced dot), which overloads the use of the period . It is convenient to define
a separate, special syntax. . The term .(X , Y) is denoted [XI l1 . Its components
have special names : X is called the head and Y is called the tail .
The term [X] 11correspondsto a conspair in LISP. The correspondingjargon

for head and tail is respectively car and cdr.
Figure 3.2 illustrates the relationship between lists written with different
syntax . The first column writes lists with the dot functor , and is the way lists are
considered as terms in logic programs . The second column gives the square bracket
equivalent of the dot syntax . The third column is an improvement upon the syntax
of the second column , essentially hiding the recursive structure of lists . In this
syntax , lists are written as a sequence of elements enclosed in square brackets and
separated by commas . The empty list used to terminate the recursive structure is
suppressed . Note the use of "cons pair notation " within the third column , when
the list has a variable tail .
Terms built with the dot functor are more general than lists . Program 3.11
defines a list precisely . Declaratively it reads : "A list is either the empty list or a
cons pair whose tail is a list ." The program is analogous to Program 3.1 defining
natural numbers , and is the simple type definition of lists .
Figure 3.3 gives a proof tree for the goal list ([ a,b,c]). Implicit in the proof
~EEEEE
list(Xs) +-
Xs is a list.
list([ ]).
list([X I Xs]) +- list(Xs).
Program 3.11: Defininga list
~
Formal object Cons pair syntax Element syntax
0- .
[a]
'
[ ]]] [a,b]
"
[c I[ ]]]]
'
[a,b,c]
""~.
[aI X]
X]] [a,bIX]
Figure 3 .2: Equivalent forms of lists
list([a,b,c])
I
list([b,c])
I
list([c])
I
list([ ])
Figure 3.3: Proof tree verifying a list
tree are ground instances of rules in Program 3.11, for example , list ( [a,b, c]) +-
list ([b,c]) . We specify the particular instance here explicitly , as instances of lists
in cons pair notation can be confusing . [a, b, c] is an instance of [XlXs ] under the
substitution { X = a,Xs = [b,c]} .
Because lists are richer data structures than numbers there is a great variety
of interesting relationships that can be specified with them . Perhaps the most
basic operation with lists is determining whether a particular element is in a list .
The predicate expressing this relationship is member (Element ,List ) . Program 3.12
is a recursive definition of member/ 2.
Declaratively , the reading of Program 3.12 is straightforward . Xis an element
of a list if it is the head of the list by the first clause , or if it is a member of the
tail of the list by the second clause. The meaning of the program is the set of all
3.2 Lists 45
member ( Element , List ) ~
Element is an element of the list List .
member ( X , [X I Xs ] ) .
member ( X , [ YIYs ] ) ~ member ( X , Ys ) .
Program 3 . 12 : Membership of a list
prefix ( Prefix , List ) ~
.Prefix is a prefix of List .
prefix ( [ ] , Ys ) .
prefix ( [X I Xs ] , [ XIY s ] ) ~ prefix (Xs,Ys).

suffix ( Suffix , List ) ~
Suffix is a suffix of List .
suffix ( Xs , Xs ) . .
suffix ( Xs , [ YIYs ] ) ~ suffix ( Xs , Ys ) .
Program 3 . 13 : Prefix es and suffixes of a list
ground instances member(X ,Xs) where X is an element of Xs. We omit the type
condition in the first clause. Alternatively it would be written
member(X,[XjXs ]) +- list(Xs).
This program has many interesting applications to be revealed throughout

the book. Its basic uses are checking whether an element is in a list with a
query such as member( b,[a,b,c)) ?, finding an element of a list with a query such
as member(X ,[a,b,c)) ?, and finding a list containing an element with a query such
as member( b,X) ? This last query may seemstrange, but there are programs that
are based on this use of member.
We use the following conventions wherever possible when naming variables
in programs involving lists. If X is used to denote the head of a list , then Xs will
denote its tail . More generally, plural variable nameswill denote lists of elements
while singular names will denote individual elements. Numerical suffixes will
denote variants of lists. Relation schemeswill still contain mnemonic names.
Our next example is a predicate sublist(Sub,List) for determining whether
Sub is a sublist of List . A sublist needsthe elements to be consecutive: [b,c] is a
sublist of [a,b,c,dJ, whereas [a,c] is not .
It is convenient to define two special casesof sublists to make the definition of
sublist easier. It is good style when composinglogic programs to define meaningful
sublist ( Sub, List ) +-

Sub is a sublist of List.
a: Suffix of a prefix
sublist(Xs,Ys) +- prefix(Ps,Ys), suffix(Xs,Ps)
b : Prefix of a suffix
sublist (Xs,Ys) +- prefix (Xs,Ss), su:ffix(Ss,Ys).

c: Recursive definition of sublist
sublist(Xs,Ys) ~ prefix (Xs,Ys).
sublist(Xs,[YIYs]) ~ sublist(Xs,Ys).
d: Suffix of a prefix , using append

sublist(Xs,AsXsBs) +-
append
(As,XsBs
,AsXsBs), append
(Xs,Bs,XsBs
).
e: Prefix of a suffix , using append
sublist (Xs ,As Xs Bs) +-

append (As Xs ,Bs ,As Xs Bs ) , append (AsiXs ,As Xs ) .
Program 3 . 14 : Determining sublists of lists
relationships- as auxiliary - -predicates . The two cases considered are initial sublists ,
or prefix es, of a list , and terminal sublists, or suffixes, of a list . The programs are
interesting in their own right .
The predicate prefix(Prefix,List ) is true if Prefix is an initial sublist of List ,
for example , prefix ( (a,b],(a, b, c]) is true . The companion predicate to prefix is
sulJix ( SulJix,List ) determining if Suffix is a terminal sublist of List . For example ,
sulJix ( (b, c],[ a,b,c]) is true . Both predicates are defined in Program 3.13. The type
condition list (Xs ) should be added to the base fact in each predica ~e to give the
correct meaning .
An arbitrary sublist can be specified in terms of prefix es and suffix es: namely
as a suffix of a prefix , or as a prefix of a suffix . Program 3.14a express es the logical
rule that Xs is a sublist of Ys if there exists Ps such that Ps is a prefix of Ys and
Xs is a suffix of Ps. Program 3.14b is the dual definition of a sublist as a prefix
of a suffix .
The predicate prefix can also be used as the basis of a recursive definition of
3.2 Lists 47
append(Xs, YsiXs Ys) +-

XsYs is the result of concatenating
the lists Xs and Ys .
append([ ],Ys,Ys).
append([X IXs],Ys,[X IZs]) +- append(Xs,Ys,Zs).
Program 3 . 15 : Appending two lists
append([a,b] ,[c,d] ,[a,b,c,d])

I
append([b],[c,d] ,[b,c,d])
I
append([ ],[c,d],[c,d])
Figure 3.4: A proof tree for appending two lists
sublist . This is given as Program 3.14c. The base rule reads that a prefix of a list
is a sublist of a list . The recursive rule reads that the sublist of a tail of a list is
a sublist of the list itself .
The predicate member can be viewed as a special case of sublist defined by

the rule
member (X ,Xs ) +- sub Iist ( [X ],Xs ) .
The basic operation with lists is concatenating two lists to give a third list .
This defines a relationship , append(Xs , Ys,Zs) , between two lists Xs , Ys and the
result Zs of joining them together . The code for append, Program 3.15, is identical
in structure to the basic program for combining two numbers together , Program
3.3 for plus .
Figure 3.4 gives a proof tree for the goal append([ a, b],[ c, dj,[a,b,c,d] ) . The tree
structure suggests that its size is linear in the size of the first list . In general , if
Xs is a list of n elements , the proof tree for append(Xs , Ys,Zs) has n + l nodes .
There are multiple uses for append similar to the multiple uses for plus .
The basic use is to concatenate two lists by posing a query such as append
( [a,b, c],[die],Xs ) ? with answer Xs = [a,b, c, die]. A query such as append
(Xs , [c,dj, [a,b,c,d] ) ? finds the difference Xs = [a, b] between the lists [c, dj and
[a,b, c, d] . Unlike plus , append is not symmetric in its first two arguments , and
thus there are two distinct versions of finding the difference between two lists .
The analogous process to partitioning a number is splitting a list . The query
reverse( List , Tsi ~ +-

Tsil is the result of reversing the list List .
a: Naive reverse
reverse ( [ ] , [ ] ) .
reverse ( [ X I Xs ] , Zs ) + - reverse ( Xs , Ys ) , append ( Ys , [ X ] , Zs ) .
b: Reverse - accumulate
reverse ( Xs , Y s ) + - reverse ( Xs , [ ] , Y s ) .
reverse ( [ X I Xs ] , Acc , Ys ) + - reverse ( Xs , [ X I Acc ] , Ys ) .
reverse ( [ ] , Ys , Ys ) .
Program 3 . 16 : Reversing a list
append(As ,Bs,[a, b,c, dJ) ?, for example , asks for lists As and Bs such that appending
Bs to As gives the list [a, b, c, dJ. Queries about splitting lists are made more
interesting by partially specifying the nature of the split lists . The predicates
member , sublist , prefix and suffix introduced previously can all be defined in terms
of append by viewing the process as splitting a list .
The most straightforward definitions are for prefix and suffix , which just
specify which of the two split pieces are of interest :
prefix (Xs ,Ys ) +- append (Xs ,As ,Ys ) .

suffix (Xs ,Ys ) +- append (As ,Xs ,Ys ) .
Sublist can be written using two append goals. There are two distinct vari -
ants , given as Programs 3.14d and 3.14e. These two programs are obtained from
Programs 3.14a and 3.14b, respectively , where prefix and suffix are replaced by
append goals.
Member can be defined using append, as follows :
member (X ,Y s) +- append (As , [X IXs ],Y s) .
This says that X is a member of Ys if Ys can be split into two lists where X
is the head of the second list .
A similar rule can be written to expressthe relation adjacent(X , Y,Zs) that

two elements X and Yare adjacent in a list Zs:
adjacent(X ,Y ,Zs) +- append(As,[X ,YIYs],Zs).
Another relationship easily expressed through append is determining the last

3.2 Lists 49
length(Xs,N) +-
The list Xs hag N elements .
length ([ 1,0).
length ([X IXs1,s(N)) +- length (Xs,N).
Program 3 . 17 : Determining the length of a list
Repeated applications of append can used to define a predicate reverse

( List , Tsil ) . The intended meaning of reverse is that Tsil is a list containing
the elements in the list List in reverse order to how they appear in List . An
example of a goal in the meaning of the program is reverse( [a, b, cJ,[c, b, aJ) . The
naive version , given as Program 3.16a, is the logical equivalent of the recursive
formulation in any language : recursively reverse the tail of the list , and then add
the first element at the back of the reversed tail .
There is an alternative way of defining reverse without calling append directly .

We define an auxiliary predicate reverse(Xs , Ys,Zs) which is true if Zs is the result
of appending Ys to the elements of Xs reversed . It is defined in Program 3.16b.
The predicate reverse/ 9 is related to reverse/ 2 by the first clause in Program
3.16b.
Program 3.16b is more efficient than Program 3.16a. Consider Figure 3.5
with proof trees for the goal reverse( [ a,b, c, d] ,[ d,c, b,a]) using both programs . In
general the size of the proof tree of Program 3.16a is quadratic in the number of
elements in the list to be reversed , while that of Program 3.16b is linear .
The insight in Program 3.16b is the use of a better data structure for representing
the sequence of elements , which we discuss in more detail in Chapters 7
and 15.
The final program in this section , Program 3.17, express es a relationship

between numbers and lists , using the recursive structure of each. The predicate
length (Xs ,N) is true if Xs is a list of length N , that is , contains N elements , where
Nis a natural number . For example , length ( [a,b],s(s(O) )) indicating [a,b] has two
elements is in the program 's meaning .
Let us consider the multiple uses of Program 3.17. The query

length ( [a, b],X) ? computes the length , 2, of a list [a, b]. In this way length is
regarded as a function of a list , with the functional definition
reverse ([a,b ,c,d] , [d ,c,b ,a])

/ ' " ' -
reverse ( rb,c,dl ,rd,c,bl ) appendd ,c,b] ,[a] ,[d,c,b ,a])
/ ' "' " """
reverse([c,d],[d,c]) appendd ,c],[b],[d,c,b]) append([c,b],[a] ,[c,b,a])
. / " " "
reversed] ,[d]) appendd] ,[c] ,[d,c]) append([c],[b],[c,b]) append([b] ,[a] ,[b,a])
. / ' " " " "
reverse([ ],[ ]) append([ ],[d],[d]) append([ ],[c],[c]) append([ ],[b],[b]) append([ ],[a],[a])
Figure 3 .5 : Proof trees for reversing a list
length(( ]) = 0
length((X IXs]) = s(length(Xs)).
The query length([a,b],s(s(O))) ? checks whether the list [a,b] has length 2.
The query length(Xs,s( s( O))) ? generatesa list of length 2 with variables for elements
.
3 .3 Composing recursive programs 51
(i ) A variant of Program 3 . 14 for sublist is defined by the following three rules .
subsequence ( (X IXs ] , (X IYs ] ) +- s~ bsequence (Xs , Ys ) .

subsequence ( Xs , (YIYs ] ) +- subsequence (Xs , Ys ) .
subsequence ( ( ] , Ys ) .
Explain why this program has a different meaning from Program 3 . 14 .
(ii ) Write recursive programs for adjacent and last which have the same meaning
as the predicates defined in the text in terms of append .
( iii ) Write a program for double ( List , List List ) where every element in List appears
twice in List List , e .g . double ( [1 , 2 , 9] , [1 , 1 , 2 , 2 , 9 , 9] ) is true .
(iv ) Compute the size of the proof tree as a function of the size of the input list ,
for Programs 3 . 16a and 3 . 16b defining reverse .
(v ) Define the relation sum ( List Of Integers , Sum ) , which holds if Sum is the sum
of the List Of Integers .
( a ) Using plus / So
( b ) Without using any auxiliary predicate .
( Hint : Three axioms are enough .)
3 .3 Composing recursive programs
No explanation has been given so far about how the example logic programs
have been composed . To some extent we claim that the composition of logic
programs is a skill learned by apprenticeship or osmosis , and most definitely by
practice . For simple relationships , the best axiomatizatio DS have an aesthetic
elegance which look obviously correct when written down . Through solving the
exercises , the reader may find , however , that there is a difference between recognizing
and constructing elegant logic programs .
This section gives more example programs involving lists . Their presentation ,
however , places more emphasis on how the programs might be composed . Two
principles are illustrated : how to blend procedural and declarative thinking , and
how to develop a program top - down .
We have shown the dual reading of clauses : declarative and procedural . How
do they interrelate when composing logic programs ? Pragmatically , one thinks
procedurally when programming . However , one thinks declaratively when considering
issues of truth and meaning . One way to blend them in logic programming is
to compose procedurally and then interpret the result as a declarative statement .

Construct a program with a given use in mind ; then consider if the alternative
uses make declarative sense . We apply this to a program for deleting elements
from a list .
The first , and most important , step is to specify the intended meaning of the
relationship . There are clearly three arguments involved when deleting elements
from a list : an element X to be deleted , a list L1 which might have occurrences
of X , and a list L2 with all occurrences of X deleted . An appropriate relation
scheme is delete (L1 ,X ,L2 ) . The natural meaning is all ground instances where L2
is the list L1 with all occurrences of X removed .
When composing the program , it is easiest to think of one specific use . Consider
the query delete ( [a, b, c, b] , b,X) ?, a typical example of finding the result of
deleting an element from a list . The answer here is X = [a, c] . The program will be
recursive on the first argument . Let 's don our procedural thinking caps .
We begin with the recursive part . The usual form of the recursive argument
for lists is [XlXs ] . There are two possibilities to consider , one where X is the
element to be deleted , and one where it is not . In the first case the result of
recursively deleting X from Xs is the desired answer to the query . The appropriate
rule is
delete ( [X IXs ] ,X ,Ys ) +- delete (Xs ,X ,Ys ) .
Switching hats , the declarative reading of this rule is : " The deletion of X
from [XlXs ] is Ys if the deletion of X from Xs is Ys." The condition that the head
of the list and the element to be deleted are the same is specified by the shared
variable in the head of the rule .
The second case where the element to be deleted is different from X , the head
of the list , is similar . The result required is a list whose head is X and whose tail
is the result of recursively deleting the element . The rule is
delete ( [X IXs ] ,Z , [X I Ys]) ~ X # Z , delete (Xs ,Z ,Ys ) .
The rule 's declarative reading is : " The deletion of Z from [XlXs ] is [XI Y s]
if Z is different from X and the deletion of Z from Xs is Y s." In contrast to the
previous rule , the condition that the head of the list and the element to be deleted
are different is made explicit in the body of the rule .
The base case is straightforward . No elements can be deleted from the

empty list , and the required result is also the empty list . This gives the fact
delete ( ( ] ,X , [ ] ) . The complete program is collected together as Program 3 .18 .
3.3 Composing recursive programs 53
delete(List,X ,HasNoXs) ~
The list Has No Xs is the result of removing all
occurrences of X from the list List .
delete([X IXs],X ,Ys) +- delete(Xs,X ,Ys).

delete([X IXs],Z,[X IYs]) +- X :f=Z, delete(Xs,Z,Ys).
delete([ ],X ,[ ]).
Program 3. 18 : Deleting all occurrences of an element from a list
select(X ,H asXs, OneLessXs) +-

The list OneLessXs is the result of removing
one occurrence of X from the list H as Xs .
select(X ,[X IXsJ,Xs) .

select(X ,[YIYs],[YIZs]) +- select(X ,Ys,Zs).
Program 3 . 19 : Selecting an element from a list
Let us review the program we have written , and consider alternative formulations
. Omitting the condition X # Zfrom the second rule in Program 3.18 gives a
variant of delete. This variant has a less natural meaning since any number of oc-
currences of an element may be deleted . For example , delete( [ a, b, c,b],b,[ a, c]) ,
delete([ a, b, c, b], b, [a,c, b]) , delete([ a, b, c, b], b,[ a, b, c]) and delete( [ a, b, c,b], b, [a, b, c, b])
are all in the meaning of the variant .
Both Program 3.18 and the variant above include in their meaning instances
where the element to be deleted does not appear in either list , for example ,
delete( [aJib, [aJ) is true . There are applications where this is not desired . Program
3.19 defines select(X ,L1 ,L2 ) , a relationship that has a different approach to
elements not appearing in the list . The meaning of select(X ,L1 ,L2 ) is all ground
instances where L2 is the list L1 where exactly one occurrence of X has been
removed .
The program is a hybrid of Program 3.12 for member and Program 3.18 for
delete. Its declarative reading is : "X is selected from [X] Xs ] to give Xs ; or X is
selected from [ 11Ys] to give [ 11Zs] if X is selected from Ys to give Zs." We use
select to aid the construction of a naive program for sorting lists , presented below .
A major thrust in programming has been the emphasis on a top -down design
methodology , together with stepwise refinement . Loosely , the methodology is to
state the general problem , break it down into subproblems , and then solve the
pieces. A top -down programming style is one natural way for composing logic
programs . Our description of programs throughout the book will be mostly top -
down . The rest of this section describes the composition of two programs for
sorting a list : permutation sort and quicksort . Their top - down development is
stressed .
A logical specification of sorting a list is finding an ordered permutation of a

list . This can be written down immediately as a logic program . The basic relation
schemeis sort(Xs, Ys), where Ys is a list containing the elements in Xs sorted in
ascending order :
sort (Xs,Ys) +- permutation (Xs,Ys), ordered(Ys).
The top -level goal of sorting has been decomposed . We must now define permutation
and ordered.
Testing whether a list is ordered ascendingly can be expressed in the two

clauses given below . The fact says that a list with a single element is necessarily
ordered . The rule says that a list is ordered if the first element is less than or
equal to the second, and if the rest of the list , beginning from the second element ,
is ordered :
ordered([X ]).
ordered([X ,YIY s]) +- X ~ Y , ordered([YIY s]) .
A program for permutation is more delicate . One view of the process of

permuting a list is selecting an element nondeterministic ally to be the first element
of the permuted list , then recursively permuting the rest of the list . We translate
this view into a logic program for permutation , using Program 3.19 for select. The
base fact says that the empty list is its own unique permutation :
permutation (Xs,[ZIZs]) ~ select(Z,Xs,Ys) , permutation (Ys,Zs).

permutation ([ ],[ ]).
Another procedural view of generating permutations of lists is recursively permuting

the tail of the list and inserting the head in an arbitrary position . This
view also can be encoded immediately . The base part is identical to the previous
verSIon :
permutation ([X IXs] ,Zs) +- permutation (Xs,Y s) , insert (X ,Y siZs).

permutation ([ ],[ ])~
The predicate insert can be defined in terms of Program 3.19 for select.
insert (X ,Ys,Zs) +- select(X ,Zs,Ys) .
Both procedural versions of permutation have clear declarative readings .

.
3.3 Camposmg recurs Ive programs 55
sort ( Xs , Ys ) + -
The list Y s is an ordered permutation of the list Xs .
sort ( Xs ,Ys ) + - permutation ( Xs ,Ys ) , ordered ( Ys ) .
permutation ( Xs , [ ZIZs ] ) . . - select ( Z ,Xs ,Ys ) , permutation ( Ys , Zs ) .

permutation ( ( ] ,[ ] ) .
ordered ( [X ] ) .
ordered ( [X ,YIYs ]) +- X ~ Y , ordered ( [YIYs ]) .
Program 3 . 20 : Permutation sort
sort ( Xs , Ys ) + -
sort ( [X IXs ] , Y s ) ~ sort ( Xs , Zs ) , insert ( X , Zs , Y s ) .

sort ( [ ] ,[ ]) .
insert ( X , [ ] , [X ] ) .
insert ( X , [YIYs ] , [YIZs ]) +- X > Y , insert ( X , Ys , Zs ) .

insert ( X , [YIYs ] , [X ,YIYs ]) +- X ~ Y .
Program 3 . 21 : Insertion sort
The " naive " sorting program , which we call permutation sort , is collected
together as Program 3 . 20 . It is an example of the generate - and - test paradigm to

be discussed fully in Chapter 14 .
The problem of sorting lists is well studied . Permutation sort is not a good
method for sorting lists in practice . Much better algorithms come from applying
a " divide and conquer " strategy to the task of sorting . The insight is to sort a list
by dividing it into two pieces , recursively sorting the pieces , and then joining the
two pieces together to give the sorted list . The methods for dividing and joining
the lists must be specified . There are two extreme positions . The first is to make
the dividing hard , and the joining easy . This approach is taken by the quicksort
algorithm . We give a logic program for quicksort below . The second position is
making the joining hard , but the dividing easy . This is the approach of merge
sort , which is posed as exercise ( iv ) at the end of the section , and insertion sort ,
shown in Program 3 . 21 .
In insertion sort , one element ( typically the first ) is removed from the list .
The rest of the list is sorted recursively ; then the element is inserted , preserving
the orderedness of the list .
sort ( Xs , Ys ) +-
quicksort ( [X IXs ] ,Ys ) +-

partition (Xs ,X ,Littles ,Bigs ) ,
quicksort ( Littles ,Ls ) ,
quicksort ( Bigs ,Bs ) ,
append ( Ls , [X IBs ] ,Y s ) .
quicksort ( [ ] ,[ ]) .
partition
([XIXs],Y,[XILs],Bs) +- X SY , partition(Xs,Y ,Ls,Bs).
partition
([XIXs],Y,Ls,[XIBs]) +- X > Y, partition(Xs,Y ,Ls,Bs).
partition
([],Y,[],[]).
Program3.22:Quicksort
The insight in quicksort is to divide the list by choosing an arbitrary element
in it , and then to split the list into the elements smaller than the chosen element
and the elements larger than the chosen element . The sorted list is composed
of the smaller elements , followed by the chosen element , and then the larger
elements . The program we describe chooses the first element of the list as the
basis of partition .
Program 3.22 defines sort using the quicksort algorithm . The recursive rule
for sort reads : " Ys is a sorted version of [.X] Xs ] if Littles and Bigs are a result
of partitioning Xs according to X , Ls and Bs are the result of sorting Littles and
Bigs recursively , and Ys is the result of appending [.X] Bs] to Ls .
Partitioning a list is straightforward , and is similar to the program fordeleting
elements . There are two cases to consider : when the current head of the list
is smaller than the element being used for the partitioning , and when the head is
larger than the partitioning element . The declarative reading of the first partition
clause is : "Partitioning a list whose head is X and whose tail is Xs according to
an elementY gives the lists [Xl Littles ) and Bigs , if X is less than or equal to Y
and partitioning Xs according to Y gives the lists Littles and Bigs ." The second
clause for partition has a similar reading . The base case is that the empty list is
partitioned into two empty lists .
(i) Write a program for substitute (X , Y,L1 ,L2 ) where L2 is the result of substituting
Y for all occurrences of X in L1 , e.g. substitute ( a, x, [ a, b, a,c],[x,b,x,c])
3.4 Binary trees 57
is true , whereas substitute( a, x, (a,b,a,c),(a,b,x,c)) is false.

(ii ) What is the meaning of the variant of select
select(X ,[X IXs] ,Xs).
select(X ,[YIYs],[YIZs}) +- X # Y , select(X ,Ys,Zs).
(iii ) Write a program for no_doubles(L1,L2) where L2 is the result of removing all
duplicate elements from Ll , e.g. no_doubles
([a, b, c, b],[a, c, b]) is true.
(Hint : Use member.)
(iv ) Write programs for even_permutation (Xs , Ys) and odd_permutation (Xs , Ys)
which find Ys, the even and odd permutations respectively , of a list Xs .
For example , even-permutation ([l ,2,3],[2, 3,1]) and odd_permutation ([l ,2,3],
[2,1,3]) are true .
(v ) Write a program for merge sort .
3 .4 Binary trees
The next recursive data type we consider is binary trees . These structures
have an important place in many algorithms .
Binary trees are represented by the ternary functor tree(Element ,Left ,Right ) ,
where Element is the element at the node , and Left and Right are the left and
right subtrees respectively . The empty tree is represented by the atom void . For
example , the tree
a
/ \
b c
would be represented as
tree(a,tree( bivoid ,void) ,tree ( c,void ,void) ) .
Logic programs manipulating binary trees are similar to those manipulating

lists . As with natural numbers and lists , we start with the type definition of binary
trees . It is given as Program 3.23. Note that the program is doubly recursive ; that
is , there are two goals in the body of the recursive rule with the same predicate
as the head of the rule . This is due to the doubly recursive nature of binary trees ,
and will be seen also in the rest of the programs of this section .
Let us write some tree processing programs . Our first example tests whether
an element appears in a tree . The relation scheme is tree_member ( Element , Tree) .
binary _ tree ( Tree ) + -

Tree is a binary tree .
binary _tree ( void ) .

binary - tree ( tree ( Element , Left ,Right ) ) +-
binary _tree ( Left ) , binary _tree ( Right ).
Program 3 . 23 : Defining binary trees
tree _ member ( Element , Tree ) + -

Element is an element of the binary tree Tree.
tree - Inember ( X , tree ( X ,Left ,Right )).
tree .
- Inember (.Y ,Left ,Right
( X ,tree ) ) +- tree- member
(X ,Left ).
tree- member(X ,tree(Y ,Left ,Right )) +- tree- member(X ,Right ).
Program 3.24 : Testing tree membership
isotree( Tree1, Tree2) +-

Tree1 and Tree2 are isomorphic binary trees .
isotree(void,void).
isotree(tree (X ,Left 1,Right l ) ,tree(X ,Left2 ,Right2) +-
isotree(Leftl ,Left2) , isotree(Rightl ,Right2)).
isotree(tree(X ,Leftl ,Rightl ),tree(X ,Left2 ,Right2) +-
isotree(Leftl ~Right2), isotree(Rightl ,Left2)).
Program 3 .25 : Determining when trees are isomorphic
The relation is true if Element is one of the nodes in the tree . Program 3.24
contains the definition . The declarative reading of the program is "X is a member
of a tree if it is the element at the node (by the fact) or if it is a member of the
left or right subtree (by the two recursive rules) ."
The two branch es of a binary tree are distinguishable , but for many applications
the distinction is not relevant . Consequently a useful concept is isomor -
phism , which defines when unordered trees are essentially the same. Two binary
trees Tl and T2 are isomorphic if T2 can be obtained by reordering the branch es
of the subtrees of T1. Figure 3.6 shows three simple binary trees . The first two
are isomorphic ; the third is not ~
Isomorphism is an equivalence relation , with a simple recursive definition .

Two empty trees are isomorphic . Otherwise , two trees are isomorphic if they
have identical elements at the node , and , either both the left subtrees and the
3.4 Binary trees 59
Figure 3.6: Comparing trees for isomorphism
right subtrees are isomorphic , or the left subtree of one is isomorphic with the
right subtree of the other , and the two other subtrees are isomorphic .
Program 3.25 defines a predicate isotree ( Treel , Tree2) which is true if Treel
and Tree2 are isomorphic . The predicate is symmetric in its arguments .
Programs related to binary trees involve double recursion , one for each branch
of the tree . The double recursion can be manifest in two ways . Programs can
have two separate cases to consider , as in Program 3.24 for tree_member. In
contrast , Program 3.12 testing membership of a list has only one recursive case.
Alternatively the body of the recursive clause has two recursive calls , as in each
of the recursive rules for isotree in Program 3.25.
The task in Exercise 3.3(i ) is to write a program for substituting for elements
in lists . An analogous program can be written for substituting elements in binary
trees . The predicate substitute (X , Y, Old Tree,New Tree) is true if New Tree is the
result of replacing all occurrences of X by Y in Old Tree. An a:xiomatization of
substitute / 4' is given as Program 3.26.
Many applications involving trees require access to the elements appearing
as nodes . Central is the idea of a tree traversal which is a sequence of the nodes
of the tree in some predefined order . There are three possibilities for the linear
order of traversal : preorder , where the value of the node is first , then the nodes in
the left subtree , followed by the nodes in the right subtree , inorder , where the left
nodes come first followed by the node itself , and the right nodes , and postorder
where the node comes after the left and right subtrees .
A definition of each of the three travers als is given in Program 3.27. The
recursive structure is identical ; the only difference between the programs is the
order the elements are composed by the various append goals .
. 3.4
60 Recursive Pro gram mmg
substitute(X , Y, TreeX , TreeY) +-

The binary tree TreeY is the result of replacing all
occurrences of X in the binary tree TreeX by Y.
substitute (X ,Y ,void ,void).

substitute (X ,Y ,tree(X ,Left ,Right ) ,tree(Y ,Leftl ,Rightl )) +-
substitute (X ,Y ,Left ,Leftl ), substitute (X ,Y ,Right ,Rightl ).
substitute (X ,Y ,tree (Z,Left ,Right ) ,tree(Z,Leftl ,Rightl )) +-
X =I=Z, substitute (X ,Y ,Left ,Leftl ), substitute (X ,Y ,Right ,Rightl ).
Program 3 .26 : Substituting for a term in a tree
preorder ( Tree,Pre) +-
Pre is a preorder traversal of the binary tree Tree.
pre_order(tree(X ,L ,R) ,Xs) +-

pre_order(L ,Ls), pre_order(R,Rs), append( [X ILs] ,Rs,Xs).
pre_order(void,[ ]).
in_order( Tree,In ) +-
In is an in -order traversal of the binary tree Tree.
in _order (tree(X ,L ,R),Xs) +-

in _order(L ,Ls), in _order(R,Rs), append(Ls, [X IRs] ,Xs).
in _order(void,[ ]).
post_order( Tree,Post) +-
Post is a post -order traversal of the binary tree Tree.
post_order(tree(X ,L ,R) ,Xs) +-

post_order(L ,Ls) ,
post_order(R,Rs) ,
append(Rs,[X ] ,RsI ),
append(Ls,RsI ,Xs) .
post_order(void,[ ]).
Program 3 .27 : Travers als of a binary tree
(i) Define a program for subtree(ST ) where S is a subtree of T.

(ii ) Define the relation sum_tree( TreeOfIntegers,Sum), which holds if Sum is the
sum of the integer elements in TreeOflntegers
.
3.5 Manipulating symbolic expressions 61
(iii ) Define the relation ordered( TreeD/ Integers ) , which holds if Tree is an ordered
tree of integers , that is , for each node in the tree the elements in the left
subtree are smaller than the element in the node , and the elements in the
right subtree aloelarger than the element in the node ,
(Hint : Define two auxiliary relations , ordered_left (X , Tree) , and ordered
_right (X , Tree) , which hold if both X is smaller (larger ) than the root of
Tree, and Tree is ordered ,)
(iv ) Define the relation tree_insert (X , Tree, Treel ) , which holds if Treel is an ordered
tree resulting from inserting X into the ordered tree Tree. If X already
occurs in Tree, then Tree and Treel are identical .
(Hint : Four axioms suffice .)
3 .5 Manipulating symbolic expressions
The logic programs illustrated so far in this chapter have manipulated natural
numbers , lists , and binary trees . The programming style is applicable more generally
. This section gives four examples of recursive programming - a program
for defining polynomials , a program for symbolic differentiation , a program for
solving the Towers of Hanoi problem , and a program for testing the satisfiability
of Boolean formulae .
The first example is a program for recognizing polynomials in some term

X . Polynomials are defined inductively . X itself is a polynomial in X , as is any
constant . Sums , differences and products of polynomials in X are polynomials
in X . So too are polynomials raised to the power of a natural number , and the
quotient of a polynomial by a constant .
An example of a polynomial in the term x is x2 - 3x + .2. This follows from

it being the sum of the polynomials , x2 - 3x and .2, where x2 - 3x is recognized
recursively .
A logic program for recognizing polynomials is obtained by expressing the

rules given informally above in the correct form . Program 3 .28 defines the relation
polynomial ( Expression ,X) which is true if Expression is a polynomial in X . We give
a declarative reading of two rules from the program .
The fact polynomial (X ,X) says that a term X is a polynomial in itself . The
rule
polynomial(Terml+Term2,X) +-
polynomial(Terml,X), polynomial(Term2,X)
polynomial ( Expression , X ) + -
Expression is a polynomial in X .
polynomial ( X , X ) .
polynomial ( Term , X ) + -
constant ( Term ) .
polynomial ( Terml + Term2 , X ) + -
polynomial ( Terml , X ) , polynomial ( Term2 , X ) .
polynomial ( Terml - Term2 , X ) + -
polynomial ( Terml , X ) , polynomial ( Term2 , X ) .
polynomial ( Terml * Term2 , X ) + -
polynomial ( Term 1 , X ) , polynomial ( Term2 , X ) .
polynomial ( Termlj Term2 , X ) + -
polynomial ( Terml , X ) , constant ( Term2 ) .
polynomial ( Term iN , X ) + -
natural J1umber ( N ) , polynomial ( Term , X ) .
Program 3 . 28 : Recognizing polynomials
says that the sum Terml + Term2 is a polynomial in X if both Terml and Term2
are polynomials in X .
Other conventions used in Program 3 . 28 are the use of the unary predicate
constant for recognizing constants , and the binary functor i to denote exponentiation
. The term Xi Y denotes XY .
The next example is a program for taking derivatives . The relation scheme
is derivative ( Expression , X , Dijferentiated Expression ) . The intended meaning of
derivative is that Dijferentiated Expression is the derivative of Expression with
respect to X .
As for Program 3 . 28 for recognizing polynomials , a logic program fordiffer -
entiation i ~ just a collection of the relevant differentiation rules , written in the
correct syntax . For example , the fact
derivative ( X , X , s ( O ) ) .
express es that the derivative of X with respect to itself is 1 . The fact
derivative ( sin ( X ) , X , cos ( X ) ) .
reads : " The derivative of sin ( X ) with respect to X is cos ( X ) . " Natural mathematical
notation can be used . A representative sample of functions and their
derivatives is given in Program 3 . 29 .

derivative ( Expression , X , Differentiated Expression ) +-

Differentiated Expression is the derivative of
Expression with respect to X .
derivative (X ,X ,s ( 0 ) ) .
derivative (Xjs (N ) ,X ,s (N ) * XjN ).
derivative ( sin (X ) ,X ,cos (X ) ) .
derivative ( cos ( X ) ,X , - sin (X ) ) .
derivative ( ejX ,X ,ejX ).
derivative ( log (X ) ,x , 1 IX ) .
derivative ( F + G ,X ,DF + DG ) +-
derivative ( F ,X ,D F ) , derivative ( G ,X ,DG ) .
derivative ( F - G ,X ,DF - DG ) +-
derivative ( F ,X ,D F ) , derivative ( G ,X ,DG ) .
derivative ( F * G ,X ,F * DG + DF * G ) +-
derivative (F ,X ,DF ) , derivative ( G ,X ,DG ) .
derivative ( l / F ,X , - DF / (F * F ) ) +-
derivative ( F ,X ,DF ) .
derivative ( F / G ,X , ( G * DF - F * DG ) / ( G * G ) ) +-
derivative ( F ,X ,DF ) , derivative ( G ,X ,DG ) .
Program 3 . 29 : Derivative rules
Sums and products of terms are differentiated using the sum rule and product
rule , respectively . The sum rule states that the derivative of a sum is the sum of
derivatives . The appropriateclauseis:
derivative(F+ G,X,DF+ DG)

derivative(F ,X ,DF ), derivative(G,X ,DG).
The product rule is a little more complicated, but the logical clause is just the
mathematical definition :
derivative(F*G,X ,F *DG+ DF * G) +-
derivative(F ,X ,DF ), derivative(G,X ,DG).
Program 3.29 also contains the reciprocal and quotient rules .

The chain rule is a little more delicate . It states that the derivative of J( g( x) )
with respect to xis the derivative of J( g(x)) with respect to g(x) times the derivative
of g(x) with respect to x. As stated , it involves quantification over functions , and
is outside the scope of the logic programs we have presented .
hanoi(N,A ,BiG,Moves) +-
Moves is a sequence of moves for solving the towers of
Hanoi puzzle with N disks and three pegs, A , Band G.
hanoi(s(O),A ,B,C,[A to B]) .

hanoi(s(N) ,A ,B ,C,Moves)+-
hanoi(N ,A ,C,B,Msl ),
hanoi(N ,C,B ,A ,Ms2),
append(Msl ,[A to BIMs2],Moves) .
Program 3 .30 : Towers of Hanoi
Nonetheless , a version of the chain rule is possible for each particular function .
For example, we give the rule for differentiating XN and sin(X) :
derivative(Ujs (N) ,X ,s(N) * UrN *DU) ~ derivative(U ,X ,DU ).
derivative(sin(U),X ,cos(U)*DU ) ~ derivative(U ,X ,DU).
The difficulty of expressing the chain rule for differentiation arises from our
choice of representation of terms . Both Programs 3.28 and 3.29 use the "natural "
representation from mathematics where terms represent themselves . A term such
as sin (X ) is represented using a unary structure sin . If a different representation
were used, for example , unary _term ( sin ,X) where the name of the structure is
made accessible, then the problem with the chain rule disappears . The chain rule
can then be formulated as
derivative (unary _term (F ,U ) ,X ,DF * DU ) +-

derivative (unary _term (F ,U ) ,U ,DF ) , derivative (U ,X ,DU ) .
Note that all the rules in Program 3.29 would have to be reformulated in terms
of this new representation , and would appear less natural .
People take for granted the automatic simplification of expressions when differentiating
expressions . Simplification is missing from Program 3.29. The answer
to the query derivative (9* x + 2,x,D ) ? is D = ( 9* 1 + 0* x) + O. We would immediately
simplify D to 9, but it is not specified in the logic program .
The next example is a solution to the "Towers of Hanoi " problem , a standard
introductory example in the use of recursion . The problem is to move a tower of
n disks from one peg to another , with the help of an auxiliary peg . There are
two rules . Only one disk can be moved at a time , and a larger disk can never be
placed on top of a smaller disk .
There is a legend associated with the game. Somewhere hidden in the surroundings
of Hanoi , an obscure eastern village when the legend was first told ,
is a monastery . The monks there are performing a task assigned to them by

God when the world was created - solving the above mentioned problem with 3
golden pegs and 64 golden disks . At the moment they complete their task , the
world will collapse into dust . Since the optimal solution to the problem with n
disks takes 2n - 1 moves, we need not lose any sleep over this possibility . The
number 264 is comfortingly big .
The relation schemefor solving the problem is hanoi(N,A ,B,C,Moves). It is
true if Moves is the sequence of moves for moving a tower of N disks from peg A
to peg B using peg C as the auxiliary peg . This is an extension to usual solutions
which do not calculate the sequence of moves, but rather perform them . The
representation of the moves uses a binary functor to , written as an infix operator .
The term X to Y denotes that the top disk on peg X is moved to peg Y . The
program for solving the problem is given in Program 3.30.
The declarative reading of the heart of the solution , the recursive rule in
Program 3.30, is: "Moves is the sequenceof moves of s(N) disks from peg A to
peg B using peg C as an auxiliary , if Msl is the solution for moving N pegs from
A to C using B , Ms .2is the solution for moving N pegs from C to B using A , and
Moves is the result of appending [A to BIMs.2] to Msl .
The recursion terminates with moving one peg . A slightly neater , but less
intuitive , base for the recursion is moving no disks . The appropriate fact is
hanoi(O,A ,B ,C,[ ]).
The final example concerns Boolean formulae .

A Boolean formula is a term defined as follows : the constants true and false
are Boolean formulae ; if X and Y are Boolean formulae , so are Xv Y , X / \ Y , and
"" X , where V and /\ are binary infix operators for disjunction and conjunction ,
respectively , and "" is a unary prefix operator for negation .
A Boolean formula F is true if :
F = ' true '

F = X / \ Y , and both X and Y are true
F = XVY , and either X or Y (or both ) are true
F = "",X , and X is false.
A Boolean formula F is false if :

F= 'false'
F= XAY, and either X or Y (or both) arefalse
F= XVY, and both X and Y arefalse
F= "",X, and X is true.
satisfiable(Formula) i -
There is a true instance of the Boolean formula Formula .
satisfiable (true).
satisfiable (X /\ Y ) i - satisfiable(X ), satisfiable(Y ).
satisfiable (XVY ) i - satisfiable(X ).
satisfiable (XVY ) i - satisfiable(Y ).
satisfiable ("'-'X ) i - invalid (X ) .
invalid(Formula) +-
There is a false instance of the Boolean formula Formula .
invalid (false) .
invalid (XVY ) i - invalid (X ), invalidY ).
invalid (X /\ Y ) i - invalid (X ).
invalid (X /\ Y ) i - invalidY ).
invalid ("""Y ) i - satisfiable(Y ).
Program 3.31 : Satisfiability of Boolean formulae
Program 3.31 is a logic program for determining the truth or falsity of a

Boolean formula . Since it can be applied to Boolean formulae with variables , it
is actually more powerful than what seems on the surface . A Boolean formula
with variables is satisfiable if it has a true instance . It is invalid if it has a false
instance . These are the relations computed by the program .
(i ) Write a program to recognize if an arithmetic sum is normalized , that is , has

the form A + B where A is a constant and B is a normalized sum .
(ii ) Write a type definition for Boolean formulae .
(iii ) Write a program for recognizing whether a logical formula is in conjunctive

normal form , namely is a conjunction of disjunctions of literals , where a literal
is an atomic formula or its negation .
(iv ) Write a program for the relation negation - inwards (Fl ,F2) which is true if F2
is the logical formula resulting from moving all negation operators occurring
in the formula Fl inside conjunctions and disjunctions .
(v ) Write a program for converting a logical formula into conjunctive normal

form , that is , a conjunction of disjunctions .
3.6 Background 67
3 . 6 Background
Many of the programs in this chapter have been floating around the logic
programming community , and their origins have become obscure . For example ,
several appear in Clocksin and Mellish ( 1984 ) and the uneven collection of short
Prolog programs , " How to solve it in Prolog " by Coelho et al . ( 1980 ) .
The classic reference for binary trees is Knuth ( 1968 ) and for sorting Knuth
( 1975 ) .
Many of the basic programs for arithmetic and list processing have a simple
structure which allows many correctness theorems to be proved automatically ,
see , for example , Boyer and Moore ( 1979 ) and Sterling and Bundy ( 1982 ) .
Ackerman 's function is discussed by Peter ( 1967 ) .

Chapter4
The Computation
Model of Logic Programs
The computation model used in the first three chapters of the book has a
severe restriction . All goals appearing in the proof trees are ground . All rule
instances used to derive the goals in the proof trees are also ground . The abstract
interpreter described assumes that the substitutions giving the desired ground
instances can be guessed correctly . In fact the correct substitutions can be computed
rather than guessed.
This chapter presents the full computation model of logic programs . The
first section presents the unification algorithm which removes the guesswork in
determining instances of terms . The second section presents an appropriately
modified abstract interpreter , and gives example computations of logic programs .
4.1 Unification
The heart of the computation model of logic programs is the unification

algorithm . Unification is the basis of most work in automated deduction , and the
uses of logical inference in artificial intelligence .
Necessary terminology for describing the algorithm is repeated from Chapter
1, and new definitions are introduced as needed.
Recall that a term t is a common instance of two terms , 4 and t2, if there exist
substitutions (Jl and (J2 such that t equals 4 (Jl and t2(J2. A term s is more general
than a term t if t is an instance of s, but s is not an instance of t . A term s is an
alphabetic variant of a term t if both s is an instance of t, and t is an instance of s.
Alphabetic variants are related by the renaming of variables which occur in the
4.1 Unification 69
terms. For example, member(X ,tree(Left,X ,Right)) and memberY ,tree(Left, Y,Z) )
are alphabetic variants .
A unifier of two terms is a substitution making the terms identical . If two
terms have a unifier , we say they unify . There is a close relationship between
unifiers and common instances . Any unifier determines a common instance , and
conversely any common instance determines a unifier .
For example, append([1,2,3],[3,4],List ) and append([.X] Xs], Ys,[.X] Zs]) unify . A
unifying substitution is { X = l , Xs= [2,3], Ys= [3,4], List = [lIZs ]} . Their common
instance, determined by this unifying substitution , is append([1,2,3],[3,4],[lizs ]).
A most general unifier or mgu of two terms is a unifier such that the associated
common instance is most general . If two terms unify , then there is a unique most
general unifier . The uniqueness is up to renaming of variables . Equivalently , two
terms have a unique most general common instance , up to alphabetic variants .
A unification algorithm computes the most general unifier of two terms , if it
exists , and reports failure otherwise .
The algorithm for unification presented here is based on solving equations .
The input for the algorithm is two terms Tl and .T2. The output of the algorithm
is the mgu of the two terms if they unify , or failure if the terms do not unify . The
algorithm uses a pushdown stack for storing the equations that need to be solved ,
and a location , (), for collecting the substitution comprising the output .
The location e is initially empty , and the stack is initialized to contain the
equation Tl = T2. The algorithm consists of a loop of popping an equation from
the stack and processing it . The loop terminates if failure occurs in processing an
invalid equation , or when the stack becomes empty .
We consider the possible actions for dealing with the popped equationS = T.
The simplest case is if S and T are identical constants or variables . This equation
is correct , and nothing further needs to be done . The computation continues by
popping the next equation from the stack .
If S is a variable , and T is a term not containingS , the following happens .
The stack is searched for all occurrences of S, which are replaced by T. Similarly
all occurrences of S in (J are replaced by T. Then the substitutionS = T is added
to (J. It is significant that S does not occur in T. The test embodied by the phraBe
"not containing " is known aB the occurs check.
If T is a variable , and S is a term not containing T, i .eT satisfies the occurs
check with respect to S, the symmetric sequence of actions happens .
Equations are added to the stack if S and T are compound terms with the
sameprincipal functor and arity , J( 81,. . ., 8n) and J( T1,. . ., Tn) say. For the terms
70 The Computation Model of Logic Programs 4.1
to unify , each of the argument pairs must simultaneously unify . This is achieved
by pushing the n equations , Si = Ti , onto the stack .
In any other case, failure is reported , and the algorithm terminates . If the
stack is emptied , the terms unify , and the unifier can be found in (). The complete
algorithm is given as Figure 4.1. The occurs check is embodied in the phrase
"that does not occur in ."
We do not prove the correctness of this algorithm , nor analyze its complexity .
The interested reader is referred to the literature in the background section at
the end of the chapter .
Consider attempting to unify the terms append( [a,b], [c, dJ,Ls) and append(
[X] Xs ], Ys, [X] Zs]) . The stack is initialized to the equation
append( [ a,b],[ c,dJ,Ls) = append( [X] Xs ], Ys, [X] Zs]) .
These two terms have the same functor , append, and arity , 3, and so we add the
three equations relating the subterms of the two terms . These are [a, b] = [.)[jXs ],
[c,d] = Ys, and Ls = [X I Zs].
The next equation , [a, b] = [X IXs] , is popped from the stack . These two compound
terms have the same functor , " ." , and arity , 2, and so two equations , a= X
and [b] = Xs are added to the stack . Continuing , the equation a= X is popped .
This is covered by the second case in Figure 4.1. X is a variable not occurring in
the constant , a. All occurrences of X in the stack are replaced by a. One equation
is affected , namely Ls = [XlZs ], which becomes Ls = [aIZs] . The equation X = a is
added to the initially empty substitution , and the algorithm continues .
The next equation to be popped is [b] = Xs . Again this is covered by the

second case. Xs = [ b] is added to the set of substitutions , and the stack is checked
for occurrences of Xs . There are none , and the next equation is popped .
The second case also covers [c, dj = Ys. Another substitution , Ys= [c,dj, is
added to the collection , and the final equation , Ls = [ al Zs], is popped . This is
handled by the symmetric first case. Ls does not occur in [aIZs] , so the equation
is added as is to the unifier , and the algorithm terminates successfully . The unifier
is { X = a, Xs = [b], Ys= [c,dj, Ls = [aIZs]} . The common instance produced by the
unifier is append( [ a,b],[ c, dj, [ aIZs]) . Note that in this unification , the substitutions
were not updated .
The occurs check is necessary to prevent the unification of terms such as s( X)

and X . There is no finite common instance of these terms .
Most Prolog implementations omit the occurs check from the unification
algorithm , for pragmatic reasons . This issue is discussed further in Section 6.1.
4.1 Unification 71
Input : Two terms Tl and T2 to be unified

Output : 0, the mgu of Tl and T2, or failure
Algorithm :
Figure 4.1: A unification algorithm
When implementing the unification algorithm for a particular logic programming

language , the explicit substitution in both the equations on the stack and
the unifier is avoided . Instead , logical variables and other terms are represented
by memory cells with different values , and variable binding is implemented by
assigning the memory cell representing a logical variable a reference to the cell
containing the representation of the term the variable is bound to . Therefore
substituteY for X in stack and in (J
add X = Yto substitutions
is replaced by
make X a reference to Y.
(i ) What is the mgu of append([b],[c,dj,L) and append([.)(]Xs], Ys,[.)(]Zs]) ?

(ii ) What is the mgu of hanoi(s(N) ,A,B, C,Ms) and hanoi(s(s(O)),a,b,c,Xs) ?
4 .2 An abstract interpreter for logic programs
We revise the abstract interpreter of Section 1.8 in the light of the unification
algorithm . The result is the full computation model of logic programs . All the
concepts introduced previously , such as goal reductions and computation traces ,
have their analogue in the full model .
A computation of a logic program can be described informally as follows . It

starts from some initial (possibly conjunctive ) query G and , if it terminates , has
one of two results : success or failure . If a computation succeeds, the instance of G
proved is conceived of as the output of the computation . A given query can have
several successful computations , each resulting in a different output . In addition ,
it may have nonterminating computations , to which we associate no result .
The computation progress es via goal reduction . At each stage there is some
resolvent , a conjunction of goals to be proved . A goal in the resolvent and clause
in the logic program are chosen such that the clause's head unifies with the goal .
The computation proceeds with a new resolvent , obtained by replacing the chosen
goal by the body of the chosen clause in the resolvent , and then applying the most
general unifier of the head of the clause and the goal . The computation terminates
when the resolvent is empty . In this case, we say the goal is solved by the program .
To describe computations more formally we introduce some useful concepts .
A computation of a goal Q= Qo by a program Pis a (possibly infinite ) sequence of
triples ( Qi , Gi , Ci ) ' Qi is a (conjunctive ) goal , Gi is a goal occurring in Qi , and Ci
is a clause A +- B1,. . .,Bk in Prenamed so that it contains new variable symbols
not occurring in Qj , 0 $ j $ i . For all i > 0, Qi+ l is the result of replacing Gi by
the body of Ci in Qi , and applying the substitution Oi, the most general unifier
of Gi and Ai , the head of Ci ; or the constant true if Gi is the only goal in Qi
and the body of Ci is empty ; or the constant fail , if Gi and the head of Ci do not
unify .
4.2 An abstract interpreter for logic programs 73
Input : A logic program P

A goal G
Output : G(}, if this was the instance of G
decuded from P ,
or failure if failure has occured .
Algorithm :
Initialize the resolvent to be G , the input goal .
While the resolvent is not empty do
Choose a goal A from the resolvent
and a ( renamed ) clause A ' + - B1 , B2 , . . . , Bn , n ~ 0 , from P
such that A and A ' unify with mgu ( J
( exit if no such goal and clause exist ) .
Remove A from and add B1 , B2 " " , and Bn to the resolvent .
Apply ( J to the resolvent and to G .
If the resolvent is empty output G , else output failure .
Figure 4.2: An abstract interpreter for logic programs
The goals Bi ( Ji are said to be derived from Gj and Cj . A goal Gj = Bik ( J ,
where Bik occurs in the body of clause Ci , is said to be invoked by Gi and Ci .
Gi is the parent of any goal it invokes . Two goals with the same parent goal are
sibling goals .
A trace of a computation of a logic program ( QiJ GiJ Ci ) is the sequence of
pairs ( GiJ ( J ~ ) , where ( J ~ is the subset of the mgu ( Ji computed at the " th reduction ,
restricted to variables in Gi .
We present an abstract interpreter for logic programs . It is an adaptation
of the interpreter for ground goals ( Figure 1 . 1 ) . The restriction to using ground
instances of clauses to effect reductions is lifted . Instead , the unification algorithm
is applied to the chosen goal and head of the chosen clause to find the correct
substitution to apply to the new resolvent .
Care needs to be taken with the variables in rules to avoid name clashes .
Variables are local to a clause . Hence variables in different clauses that have
the same name are , in fact , different . This is ensured by renaming the variables
appearing in a clause each time the clause is chosen to effect a reduction . The
new names must not include any of the variable names used previously in the
computation .
The revised version of the interpreter is given as Figure 4 . 2 . It solves a query

74 4.2
The Computation Model of Logic Programs
G with respect to a program P . The output of the interpreter is an instance of G,

if a proof of such an instance if found , or failure , if a failure has occured during
the computation . Note that the interpreter may also fail to terminate .
An instance of a query for which a proof is found is called a solution to the
query .
The policy for adding and removing goals from the resolvent is called the
scheduling policy of the interpreter . The abstract interpreter leaves the scheduling
policy unspecified .
Consider solving the query append([a,b],[c,dJ,Ls) ? by Program 3.15 for append
using the abstract interpreter of Figure 4.2. The resolvent is initialized to
be append([a,b],[c,dJ,Ls) . It is chosen as the goal to reduce, being the only one.
The rule chosen from the program is
append([XlXs ], Ys,[XlZs]) +- append(Xs, Ys,Zs).
The unifier of the goal and the head of the rule is { X = a, Xs= [b], Ys= [c,dj,
Ls= [alZs]} . A detailed calculation of this unifier appearedin the previous section.
The new resolvent is the instance of append(Xs, Ys,Zs) under the unifier , namely
append([b],[c,dj,Zs). This goal is chosen in the next iteration of the loop. The
same clause for append is chosen, but variables must be renamed to avoid a clash
of variable names . The version chosen is
append([XlIXsl ], Ysl ,[XlIZs1 ]) -f- append(Xsl , Ysl ,Zsl ).
The unifier of the head and goal is { Xl = b, Xsl = [ ], Ysl = [c,dj, Zs= [bIZsl]} . The
new resolvent is append([ ],[c,dj,Zsl ). This time the fact, append([ ],Zs2,Zs2),
is chosen; we again rename variables as necessary. The unifier this time is
{ Zs2= [c,dj, Zsl = [c,dj} . The new resolvent is empty and the computation terminates
.
To compute the result of the computation , we apply the relevant part of the
mgu 's calculated during the computation . The first unification instantiated Ls to
[alZs]. Zs was instantiated to [blZsl ] in the second unification , and Zsl further
became [c,dj. Putting it together, Ls has the value [al[bl[c,dj]], or more simply,
[a, b, c, dj.
The computation can be represented by a trace . The trace of the append
computation described above is presented in Figure 4.3. To make the traces
clearer , goals are indented according to the indentation of their parent . A goal
has an indentation depth of d+ 1 if its parent has indentation depth d.
As another example, consider solving the query son(S,haran) by Program 1.2.
It is reduced using the clause son(X , Y) +- fatherY ,X) , male(X) . A most general
append([a,b],[c,d] ,Ls) Ls= [aIZs]

append([b] ,[c,d] ,Zs) Zs= [bIZsl]
append([ ],[c,d],Zsl ) Zsl= [c,d]
true
Output : Ls= [a,b,c,d]
Figure 4.3: Tracing the appending of two lists
son(S,haran) son(S,haran )
father (haran,S) S= lot male (S) S= lot
male(lot ) father (haran ,lot )
true true
Figure 4 .4 : Different traces of the same solution

~
0
~- ~
(
.
'~
~ g
~
oq j
- ~
rn .
~ rn ~
(
(
g i
0 ( tJ M ~ ;
CD1 CDM
~ e ' ~ " ~P
0 ~ (
= ~
CD tJ ~
oqo 1
~
, ~
The two traces in Figure 4. 4 illustrate two successful computations , where the
choice of goal to reduce at the second step of the computation differs .
The choice of the clause to effect the reduction is nondeterministic . Not every
choice will lead to a successful computation . For example , in both of the traces
in Figure 4.4, we could have gone wrong . If we had chosen to reduce the goal
father(haran,S) with the fact father(haran,yiscah), we would not have been able
to reduce the invoked goal male(yiscah) . For the second computation , had we
chosento reduce male(S) with male(isaac), the invoked goal father( haran, isaac)
could not have been reduced .
For some computations , for example , the computation illustrated in Figure

4.3, there is only one clause from the program which can reduce each goal . Such
a computation is called deterministic . Deterministic computations mean that we
do not have to exercise our nondeterministic imagination .
The alternative choices that can be made by the abstract interpreter , when
trying to prove a goal , implicitly define a search tree , as described more fully
in Section 5.4. The interpreter "guesses" a successful path in this search tree ,
corresponding to a proof of the goal , if one exists . However , dumber interpreters ,
without guessing abilities , can also be built , with the same power as our abstract
interpreter . One possibility is to search this tree breadth -first , that is , to explore
all possible choices in parallel . This will guarantee that if there is a finite proof
of the goal (i .e., a finite successfulpath in the search tree), it will be found.
Another possibility would be to explore the abstract search tree depth -first ~
In contrast to the breadth -first search strategy , the depth -first one does not guarantee
finding a proof even if one exists , since the search tree may have infinite
paths , corresponding to potentially infinite computations of the nondeterministic
interpreter . A depth -first search of the tree might get lost in an infinite path ,
never finding a finite successful path , even if one exists .
In technical terms , the breadth -first search strategy defines a complete proof
procedure for logic programs , whereas the depth -first one is incomplete . In spite
of its incompleteness , depth -first search is the one incorporated in Prolog , for
practical reasons, as explained in Chapter 6.
Let us give a trace of a longer computation , solving the Towers of Hanoi
problem with 3 disks , using Program 3.30. It is a deterministic computation , and
is given as Figure 4.5. The final append goal is given without unifications . It is
straightforward to fill them in .
Computations such as that in Figure 4.5 can be compared to computations
in more conventional languages . Unification can be seen to subsume many of
the mechanisms of conventional languages : record allocation , assignment of and
hanoi(s(s(s(O))),a,b,c,Ms)
hanoi(s(s(O)) ,a,c,b,Msl )
hanoi (s(0) ,a,b,c,Ms 11)
hanoi(O,a,c,b,Mslll ) Mslll = [ ]
hanoi(0,c,b,a,Ms I12) Ms112= [ ]
append([ ],[a to b],Msll ) Msll = [a to b]
hanoi(s(O) ,b,c,a,Ms12)
hanoi(0,b,a,c,Ms121) Ms121= [ ]
hanoi(0,a,c,b,Ms I22 ) Ms I22= [ ]
append([ ],[b to c],Ms12) Ms I2 = [b to c)
append([a to b],[a to c,b to c],Msl ) Msl = [a to blXs]
append([ ],[a to c,b to c],Xs) Xs= [a to c,b to c)
hanoi(s(s(O) ),c,b,a,Ms2)
hanoi(s(0),c,a,b,Ms21)
hanoi(0,c,b,a,Ms211) Ms211= [ ]
hanoi(0,b,a,c,Ms212) Ms212= [ ]
append([ ],[c to a],Ms21) Ms21= [c to a]
hanoi(s(O) ,a,b,c,Ms22)
hanoi(0,a,c,b,Ms221) Ms221= [ ]
hanoi(0,c,b,a,Ms222) Ms222= [ ]
append([ ],[a to b],Ms22) Ms22= [a to b)
append([c to a],[c to b,a to b],Ms2) Ms2= [c to alYs]
append([ ],[c to b,a to b],Ys) Ys= [c to b,a to b)
append([a to b,a to c,b to c],[a to b,c to a,c to b,a to b],Ms)
append([a to c,b to c],[a to b,c to a,c to b,a to b],Xs2)
append([b to c],[a to b,c to a,c to b,a to b],Xs3)
append([ ],[a to b,c to a,c to b,a to b],Xs4)
true
Output : Ms= [a to b,a to c,b to c,a to b,c to a,c to b,a to b)
Figure 4.5: Solving the Towers of Hanoi
access to fields in records , parameter passing , and more . We defer the subject till
the computation model for Prolog is introduced in Chapter 6.
A computation of G by P terminates if Gn = true or fail for some n ~ o. Such
a computation is finite and of length n. Successful computations correspond to
terminating computations which end in true . Failing computations end in fail .
All the traces given so far have been of successful computations .
Recursive programs admit the possibility of nonterminating computations .
The query append(Xs ,[c, dj, Ys) with respect to append can be reduced arbitrarily
append(Xs,[c,d},Ys) Xs= [X IXsl], Ys= [X I Ysl]

append(Xsl ,[c,d},Ysl ) Xsl= [XlIXs2], Ysl= [XlIYs2]
append(Xs2,[c,d],Ys2) Xs2= [X2IXs3 ], Ys2= [X2IYs3
]
append(Xs3,[c,d],Ys3) Xs3= [X3IXs4 ], Ys3= [X3IYs4
]
Figure 4 .6 : A nonterminating computation
many times using the rule for append . In the process Xs becomes a list of arbitrary
length . This corresponds to solutions of the query appending [ c , dJ to an arbitrarily
long list . It is illustrated in Figure 4 .6 .
All the traces presented so far have an important feature in common . If two
goals Gi and Gj are invoked from the same parent , and Gi appears before Gj in
the trace , then all goals invoked by Gi will appear before Gj in the trace . This
scheduling policy makes traces easier to follow , by solving queries depth first .
The scheduling policy has another important effect : instantiating variables
before their values are needed for other parts of the computation . A good ordering
can mean the difference between a computation being deterministic or not .
Consider the computation traced in Figure 4 .5 . The goal
hanoi ( s ( s ( s ( 0 ) ) ) , a , b , c , Ms )
is reduced to the following conjunction
hanoi ( s ( s ( 0 ) ) , a , b , c , Ms1 ) , hanoi ( s ( s ( 0 ) ) , c , b , a , Ms2 ) , app end ( Ms1 , Ms2 , Ms ) .
If the append goal is now chosen , the append fact could be used ( incorrectly ) to
reduce the goal . By reducing the two hanoi goals first , and all the goals they
invoke , the append goal has the correct values for Msl and Ms2 .
We conclude this section with an observation . Computations have been described
as a sequence of reductions . However , there is nothing inherently sequential
about most of the computation . Parallel languages , for example , Concurrent
Prolog , Parlog , and GHC , have been designed in order to exploit this potential
parallelism .
Exercises for Section 4 . 2
(i ) Trace the goal sort ( [ 9 , 1 , 2 ] , Xs ) ? using the permutation sort ( 3 . 20 ) , insertion
sort ( 3 . 21 ) , and quicksort ( 3 . 22 ) programs in turn .

4.3 Background 79
(ii ) Give a trace for the goal derivative ( 9* sin (x) - 4* cos(x) ,x,D) using Program
3.29 for derivative.
(iii) Practice tracing your favorite computations.
4 .3 Background
Unification plays a central role in automated deduction and the use of logical
inference in artificial intelligence . It was first described in the landmark paper
of Robinson ( 1965 ) . Algorithms for unification have been the subject of much
investigation : see , for example , Martelli and Montanari ( 1982 ) , Paterson and
Wegman ( 1978 ) and Dwork et al . ( 1984 ) . Typical textbook descriptions appear
in Bundy ( 1983 ) and Nilsson ( 1980 ) .
A proof that the choice of goal to reduce from the resolvent is arbitrary can
be found in Apt and van Emden (1982) or in the text of Lloyd (1984).
A method for replacing the runtime occurs checkwith compile-time analysis
wassuggested
by Plaisted(1984).
Attempts have been made to make unification without the occurs check more
than a necessary expedient for practical implementations of Prolog . In particular
, Colmerauer (19S2b) proposes a theoretical model for such unifications that
incorporates computing with infinite terms .
A novel use of unification without the occurs check appears in Eggert and
Chow (1983) where Escher -like drawings which gracefully tend to infinity are
constructed .
Chapter 5
Theory of Logic PrograIns
There is a growing body of theory on logic programming . In this chapter we
present results without proofs on five issues : semantics , correctness , complexity ,
search trees , and negation .
5 . 1 Semantics
Semantics assigns meanings to programs . Discussing semantics allows us
to describe more formally the relation a program computes . The first chapter
informally describes the meaning of a logic program P as the set of ground instance
~ that are deducible from P via a finite number of applications of the rule
of universal modus ponens . This section considers more formal approach es .
The operational semantics is a way of describing procedurally the meaning of a
program . The operational meaning of a logic program P is the set of ground goals
that are instances of queries that are solved by P using the abstract interpreter
given in Figure 4 .2 . This is an alternative formulation of the previous semantics ,
which defined meaning in terms of logical deduction .
The declarative semantics of logic programs is based on the standard model -
theoretic semantics of first - order logic . In order to define it , some new terminology
is needed .
Let P be a logic program . The Herbrand universe of P , denoted U (P ) , is
the set of all ground terms that can be formed from the constants and function
symbols appearing in P . For example , consider P to be Program 3 .1 defimng the
natural numbers , repeated below :
natural - rlumber (O) .
natural - rlumber (s (X ) ) +- natural - rlumber (X ) .

5.1 Semantics 81
There is one constant symbol , 0 , and one unary function symbol , 8. The Her -
brand universe of the program , U ( P ) , equals { 0 , 8( 0 ) , 8( 8( 0) ) , . . .} . In general the

Herbrand universe is infinite unless no function symbols appear in the program .
If no constant symbols appear either , one is arbitrarily chosen .
The H erbrand base , denoted B ( P ) , is the set of all ground goals that can
be formed from the predicates in P and the terms in the Herbrand universe .
The Herbrand .bMe is infinite if the Herbrand universe is . For our example program
there is one predicate natural _ number . The Herbrand base , B ( P ) , equals
{ natural _number ( 0 ) , natural _ numbers ( 0) ) , . . .} .
An interpretation for a logic program is a subset of the Herbrand base . An

interpretation assigns truth and falsity to the elements of the Herbrand base .
A goal in the Herbrand base is true with respect to an interpretation if it is a

member of it , false otherwise .
An interpretation I is a model for a logic program if for each ground instance
of a clause in the program A + - B1 , . . . , Bn , A is in Iif Bl ," . , Bn are in I . Intuitively

models are interpretations which respect the declarative reading of the clauses of
a program .
For our example , natural - number ( 0) must be in every model , and natural
_numbers ( . X) ) is in the model if natural _number ( . X) is . Any model of Program
3 . 1 thus includes the whole Herbrand base .
It is easy to see that the intersection of two models for a logic program P
is again a model . This property allows the definition of the intersection of all
models . The model obtained as the intersection of all models is known as the
minimal model and denoted M ( P ) . The minimal model is the declarative meaning
of a logic program .
The declarative meaning of the program for natural _ number , its minimal
model , is the complete Herbrand base { natural _ number ( 0 ) , natural _numbers ( 0) ) ,

natural _numberss ( 0 ) ) ) , . . .} .
Let us consider the declarative meaning of append , defined as Program 3 . 15

and repeated here :
append ( [X IXs ] ,Ys , [X I Zs ] ) + - append ( Xs ,Ys , Zs ) .

append ( [ ] ,Ys ,Ys ) .
The Herbrand universe is [ ],[[ ]],[[ ],[ ]],. . ., namely all lists that can be built using
the constant [ ]. The Herbrand base is all combinations of lists with the append
predicate. The declarative meaning is all ground instances of append([ ],Xs,Xs),
that is, append([ J,[ ]J[ ])Jappend([ ]J[[ ]],[[ ]]),. . ., together with goals such as append
([[ ]],[ ],[[ ]]) which are logically implied by applications ) of the rule. This is
82 Theory of Logic Programs 5.1
only a subset of the Herbrand base. For example , append([ ],[ ],[[ ]]) is not in the
meaning of append but is in the Herbrand base.
Denotational semantics assigns meanings to programs based on associating
with the program a function over the domain computed by the program . The
meaning of the program is defined as the least fixpoint of the function , if it exists .
The domain of computations of logic programs is interpretations .
Given a logic program P, there is a natural mapping Tp from interpretations
to interpretations , defined as follows :
Tp (J) = { A in B (P) :A +- Bl ,B2 ,. . .,Bn , n ~ 0, is a ground instance of

a clause in P, and Bl ,. . .,Bn are in J} .
The mapping is monotonic since whenever an interp retation I is contained in an

interpretation J , then Tp (J) is contained in Tp (J) .
This mapping gives an alternative way of characterizing models . An interpretation
lisa model if and only if Tp (1) is contained in I .
Besides being monotonic , the transformation is also continuous , a notion that

will not be defined here . These two properties ensure that for every logic program
P , the transformation Tp has a least fixpoint , which is the meaning assigned to
P by its denotational semantics .
Happily , all the different definitions of semantics are actually describing
the same object . The operational , denotational , and declarative semantics were
demonstrated to be equivalent . This allows us to define the meaning of a logic
program as its minimal model .
5 .2 Program correctness
Every logic program has a well -defined meaning as discussed in Section 5.1.
This meaning is neither correct nor incorrect .
The meaning of the program , however , mayor may not be what was intended
by the programmer . Discussions of correctness must therefore take into consideration
the intended meaning of the program . Our previous discussion of proving
correctness and completeness similarly was with respect to an intended meaning
of a program .
We recall the definitions from Chapter 1. An intended meaning of a program
P, is a set of ground goals. We use intended meanings to denote the set of goals
intended by the programmer for his program to compute . A program P is correct
5.2 Program correctness 83
natural J1umber (X ) X=s(Xl)

natural J1umber (Xl ) Xl =s(X2)
natural J1umber (X2 ) X2=s(X3)
Figure 5.1: A nonterminatingcomputation
with respect to an intended meaning M if M (P) is contained in M. A program

P is completewith respect to an intended meaning if Miscontained in M(P). A
program is thus correct and complete with respect to an intended meaning if the
two meanings coincide exactly .
Another important aspect of a logic program is whether it terminates . A
domain is a set of goals, not necessarily ground , closed under the instance relation .
That is , if A is in D and A ' is an instance of A , then A ' is in D as well .
A termination domain of a program P is adomainD such that every computation

of P on every goal in D terminates .
Usually , a useful program should have a termination domain that includes

its intended meaning . However , since the computation model of logic programs is
liberal in the order in which goals in the resolvent can be reduced , most interesting
logic programs will not have interesting termination domains . This situation will
improve when we switch to Prolog . The restrictive model of Prolog allows the
programmer to compose nontrivial programs that terminate over useful domains .
Consider Program 3.1 defining the natural numbers . This program is terminating
over its Herbrand base. However the program is nonterminating over the
domain { natural_number(X) } . This is causedby the possibility of the nonterminating
computation depicted in the trace in Figure 5.1.
For any logic program , it is useful to find domains over which they are terminating
. This is usually difficult for recursive logic programs . We need to describe
recursive data types in a way which allows us to discuss termination .
Recall that a type , introduced in Chapter 3, is a set of terms . A type is

complete if the set is closed under the instance relation . With every complete
type T we can associate an incomplete type IT , which is the set of terms which
have instances in T and instances not in T.
We illustrate the use of these definitions to find termination domains for the
recursive programs using recursive data types in Chapter 3. Specific instances of
the definitions of complete and incomplete types are given for natural numbers
and lists. A (complete) natural number is either the constant 0, or a term of the
form sn(o). An incomplete natural number is either a variable, X , or a term of
the form sn(X) where X is a variable . Program 3.2 for ::$: is terminating for the
domain consisting of goals where the first and / or second argument is a complete
natural number .
A list is complete if every instance satisfies Program 3.11. A list is incomplete

if there are instances which satisfy Program 3.11 and instances which do not . For
example , the list [a,b, c] is complete (proved in Figure 3.3) , while the variable Xis
incomplete . Two more interesting examples : [a,X , c] is a complete list , although
not ground , whereas [a,bIXs] is incomplete .
A termination domain for append is the set of goals where the first and / or
the third argument is a complete list . We discuss domains for other list processing
programs in Section 7.2 on termination of Prolog programs .
Givea domainoverwhichProgram3.3 for plusis terminating

.
Particularize
the definitionsof completeness
andincompleteness
for binary
5 .3 Complexity
We have analyzed informally the complexity of several logic programs , for

example , ~ and plus (Programs 3.1 and 3.2) in the section on arithmetic , and
append and the two versions of reverse in the section on lists (Programs 3.15,
3.16a, and 3.16b) . In this section we briefly describe more formal complexity
measures.
The multiple uses of logic programs slightly changes the nature of complexity
measures. Instead of looking at a particular use and specifying complexity in
terms of the sizes of the inputs , we look at goals in the meaning and see how
. they were derived . A natural measure of the complexity of a logic program is the
length of the proofs generated for goals in its meaning .
We begin discussion with a new definition , the size of a goal . The size of
a term is the number of symbols in its textual representation . Constants and
variables , consisting of a single symbol , have size one. The size of a compound
term is one more than the sum of the sizes of its arguments . For example , the
list [b] has size 3, [a,b] has size 5, and the goal append( [a,b],[c,dj,Xs ) has size 12.
In general , a list of n elements has size 2' n + l .
5.3 Complexity 85
A program P is of length complexity L ( n) if for any goal G in the meaning

of P of size n there is a proof of G with respect to P of length less than equal to
L (n) .
Length complexity is related to the usual complexity measures in computer

science . For sequential realizations of the computation model , it corresponds to
time complexity . Program 3 .15 for append has linear length complexity . This is
demonstrated in exercise (i ) at the end of the section .
The applicability of this measure to Prolog programs , as opposed to logic

programs , depends on using a unification algorithm without an occurs check .
Consider the runtime of the straightforward program for appending two lists .
Appending two lists , as shown in Figure 4 .3 , involves several unifications of append
goals with the head of the append rule append ( [XlXs ] , Ys, [XlZs ] ) . At least
three unifications , matching variables against (possibly incomplete ) lists , will be
necessary . H the occurs check must be performed for each , the argument lists
must be searched . This is directly _proportional to the size of the input goal .
However if the occurs check is omitted , the unification time will be bound ,ed by a
constant . The overall complexity of append becomes quadratic in the size ,of the
input lists with the occurs check , but only linear without it .
We introduce other useful measures related to proofs . Let R be a proof . We

define the depth of R to be the deepest invocation of a goal in the associated
reduction . The goal - size of R is the maximum size of any goal reduced .
A logic program P is of goal - size complexity G ( n ) if for any goal A in the

meaning of P of size n , there is a proof of A with respect to P of goal - size less
than or equal to G ( n) .
A logic program P is of depth - complexity D ( n ) if for any goal A in the meaning

of P of size n , there is a proof of G with respect to P of depth ~ D ( n) .
Goal - size complexity relates to space . Depth - complexity relates to space of

what needs to be remembered for sequential realizations , and to space and time
complexity for parallel realizations .
(i ) Show that the size of a goal in the meaning of append joining a list of length
n to one of length m to give a list of length n + m is 4 -n + 4 -m + 1- Show that
a proof tree has m + 2 nodes - Hence show that append has linear complexity -
Would the complexity be altered if the type condition were added ?
(ii ) Show that Program 3.3 for plus has linear complexity.
(iii ) Discuss the complexity of other logic programs.
5 .4 Search trees
Computations of logic programs given so far resolve the issue of nondeterminism

by always making the correct choice . For example , the complexity measures,
based on proof trees , assume th ~t the correct clause can be chosen from the
program to effect the reduction . Another way of computationally modeling nondeterminismis
by developing all possible reductions in parallel . In this section we
discuss search trees , a formalism for: considering all possible computation paths .
A search tree of a goal G with respect to a program P is defined as follows .
The root of the tree is G. Nodes of the tree are (possibly conjunctive) goals with
one goal selected . There is an edge leading from a node N for each clause in the
program whose head unifies with the selected goal . Each branch in the tree from
the root is a computation of G by P . Leaves of the tree are success nodes where
the empty goal has been reached or failure nodes where the selected goal at the
node cannot be further reduced . Success nodes correspond to solutions of the
root of the tree .
There are in general many search trees for a given goal with respect to a
program. Figure 5.2 shows two search trees for the query son(SJharan) ? with
respect to Program 1.2. The two possibilities correspond to the two choices of
goal to reduce from the resolvent father(haranJ S
) Jmale(S) . The trees are quite
distinct , but both have a single success branch corresponding to the solution of
the query S= lot . The respective success branch es are given as traces in Figure
4 .4 .
We adopt some conventions when drawing search trees . The leftmost goal
of a node is always the selected one. This implies that the goals in derived goals
may be permuted so that the new goal to be selected for reduction is the first
goal . The edges are labeled with substitutions that are applied to the variables
in the leftmost goal . These substitutions are computed as part of the unification
algorithm .
Search trees correspond closely to traces for deterministic computations . The

traces for the append query and hanoi query given , respectively , in Figures 4.3
and 4.5 can be easily made into searchtrees. This is exercise(i) at the end of the
section .
Search trees contain multiple success nodes if the query has multiple solu-
5.4 Search trees 87
son(S,haran) son(S,haran)
, +
ather (haran ,S) ,male (S) male(S),father (haran,S)
S= lot J S= yiscaht S= milcal1 \ S= isaacl S= lot \
male (lot ) male (yiscah ) male (milcal1 ) father (haran ,isaac) father (haran,lot )
t t
true true
Figure 5.2: Two searchtrees
append(As,Bs,[a,b,c])
+ As= [aIAsl ]I ""'~ As= [ ],Bs= [a,b,c]
append(Asl ,Bs,[b,c]) ~............... true
+AS1
=[bIAs2ff
append(As2,Bs,[c])
"""""""""""""""", Asl
true
=[ ],Bs=[b,c]
. AS2
=[cIAS
append(As3,Bs,[ ])
~I """""""""",~"""" As2
true
=[ ],Bs=[c]
~ As3= [ ],Bs= [ ]1
true
Figure 5.3: Search tree with multiple success nodes
tions . Figure 5.3 contains the search tree for the query append(As ,Bs,[a, b, c]) with
respect to Program 3.15 for append, asking to split the list [a,b,c] into two . The
solutions for As and Bs are found by collecting the labels of the edges in the
branch leading to the success node . For example , in the figure , following the
leftmost branch gives the solution { As = [a,b,c),Bs = [ )} .
The number of success nodes is the same for any search tree of a given goal
with respect to a program .
Search trees can have infinite branch es, which correspond to nonterminating
computations . Consider the goal append(Xs ,(c,d] , Ys) with respect to the standard
program for append. The search tree is given in Figure 5.4. The infinite branch
is the nonterminating computation given in Figure 4.6.
Complexity measures can also be defined in terms of search trees . Prolog

programs perform a depth -first traversal of the search tree . Therefore measures
based on the size of the search tree will be a more realistic measure of the complexity
of Prolog programs rather than those based on the complexity of the proof
tree . However , the complexity of the search tree is much harder to analyze .
append(Xs, [c,d],Y s)- -

JXs= [XIXs1],Ys=[XIYs1]1- - - - - Xs=[ ],Ys=[c,d]
append(Xs 1, [c,d],Y si ) - - - -----.... true
~Xs1= [X1IXs2
],Ys1= [X1IYs2
]1- ___~ Xs1= [ ],Ys= [c,d]
append(Xs2,[c,d],Ys2) - - - true
~Xs2= [X2IXs3
],Ys2=[X2IYs3
] I- -_~--... Xs2= [ ],Ys= [c,d]
append(Xs3),[c,d],Ys3) true
. .
. .
. .
Figure 5 .4 : Search tree with an infInite branch
There is a deeper point lurking . The relationship between search trees and
proof trees is the relationship between deterministic computations and nondeterministic
computations . Whether the complexity classes defined via proof trees
are equivalent to complexity classes defined via search trees is a reformulation of
the classic P = NP question in terms of logic programming .
(i) Transform the traces of Figure 4.3 and 4.5 into search trees.
(ii ) Draw a searchtree for the query sort([2,4,1,S,3],Xs) using permutation sort.
5 .5 Negation in logic programming
Logic programs are collections of rules and facts describing what is true .
Untrue facts are not expressed explicitly ; they are omitted . In this section we
describe an extension to the logic programming computation model that allows a
limited use of negative information in programs .
We define a relation not G, and describe its meaning . It is only a partial form
of negation from first -order logic . The relation not uses the negation as failure
rule . A goal not G will be assumed to be a consequence of a program P if G is
not a consequence of P .
We characterize negation by failure in terms of search trees . A search tree of

a goal G with respect to a program P is finitely failed if it has no success nodes
nor infinite branch es. The finite failure set of a logic program P is the set of goals
G such that G has a finitely failed search tree with respect to P .
A goal not G is implied by a program P by the negation as failure rule if G
5.6 Background 89
unmarried-Btudent(X ) +- not married (X ), student(X ).

student(bill ).
married (joe) .
Program 5. 1: A simple program using not
is in the finite failure set of P.
Let us see a simple example . Consider the program comprised of two facts :
likes ( abraham ,pomegranates ) .

likes (isaac ,pomegranates ) .
The goal not likes ( sarah , pomegranates ) follows from the program by negation as
failure . The search tree for the goallikes ( sarah , pomegranates ) has a single failure
node .
Using negation as failure allows easy definition of many relations . For example
, a declarative definition of the relation disjoint (Xs , Ys) that two lists , Xs and
Ys, have no elements in common is possible as follows .
disjoint (Xs ,Ys ) +- not (member (X ,Xs ) , member (X ,Ys )) .
This reads : Xs is disjoint from Ys if there is no element X which is a member of

both Xs and Ys.
Program 5.1 is another example of a program using negation . It defines a relation

unmarried _student (Per .~on) indicating that Person is an unmarried student .
The query unmarried _student (X) has the solution X = bill .
It is difficult to implement negation as failure both efficiently and correctly .
Most Prolog implementations use a version which is correct for simple cases, but
leads to logically incorrect conclusions in other circumstances . We will discuss
the problems with the Prolog version of Pro "gram 5.1 in Section 11.2.
5.6 Background
The classic paper on the semantics of logic programs is of van Emden and
Kowalski (1976) . Important extensions were given by Apt and van Emden (1982) .
In particular , they showed that the choice of goal to reduce from the resolvent
is arbitrary by showing that the number of success nodes is an invariant for the
search trees .
In Shapiro ( 1984) complexity measures for logic programs are compared with
the complexity of computations of alternating Turing machines . It is shown that
goal-size is linearly related to alternating space, the product of length and goal-size
is linearly related to alternating tree- size, and the product of depth and goal-size
is linearly related to alternating time .
The claBsic name for search trees in the literature is SLD trees . The name
SLD WaB coined by research in automatic theorem proving which preceded the
birth of logic programming . SLD resolution is a particular refinement of the resolution
principle introduced in Robinson (1965) . Computations of logic programs
can be interpreted as a series of resolution steps , and in fact SLD resolution steps,
and are still commonly described thus in the literature . The acronym SLD stands
for Selecting a literal , using a Linear strategy , restricted to Definite clauses.
The first proof of the correctness and completeness of SLD resolution , albeit
under the name LUSH -resolution , was given by Hill (1974) .
The subject of negation has received a large amount of attention and interest
since the inception of logic programming . The fundamental work on the semantics
of negation - as-failure is by Clark ( 1978) . Clark 's results were extended by Jaffar
et al . (1983) who proved the soundness and completeness of the rule .
The concept of negation as failure is a restricted version of the closed world
assumption as discussed in the database world . For more information see Reiter
(1978) . The exact relationship between different formulations of negation
is discussed in Lloyd (1984) , which also covers many of the issues raised in this
chapter .
Leonardo Da Vinci , Portrait of the Florentine poet Bernardo
Bellinzone , engaged at the Court of Ludovico Sforza. Woodcut ,
based on a drawing by Leonardo . From Bellinezone 's Rime . Milan
1493
P art II
The Prolog Language
In order to implement a practical programming language based on the com-

putational model of logic programming , three issues need attention . The first
concerns resolving the choices remaining in the abstract interpreter for logic programs
, defined in Chaper 4. The second concerns enhancing the expressiveness
of the pure computational model of logic programs by adding metalogical and
extra -logical facilities . Finally , access to some of the capabilities of the underlying
computer , such as fast arithmetic and input / output , must be provided . This part
discuss es how Prolog , the most developed language based on logic programming ,
handles each of these issues.
Chapter 6
Pure Prolog
A pure Prolog program is a logic program , in which an order is defined for

both clauses in the program and goals in the body of the clause . The abstract
interpreter for logic programs is specialized to take advantage of this ordering
information . This chapter discuss es the execution model of Prolog programs as
opposed to logic programs , and compares it to more conventional languages .
The relationship between logic programming and Prolog is reminiscent of the
relationship between the lambda -calculus and Lisp . Both are concrete realizations
of abstract computation models . Logic programs that execute with Prolog 's execution
mechanism are referred to as pure Prolog . Pure Prolog is an approximate
realization of the logic programming computation model on a sequential machine .
It is certainly not the only possible such realization . However , it is the one with
the best practical choices, which balance preserving the properties of the abstract
model with catering for efficient implementation .
6 .1 The execu ~ion model of Prolog
Two major decisions have to be taken to convert the abstract interpreter

for logic programs into a form suitable for a concrete programming language .
First , the arbitrary choice of which goal in the resolvent to reduce , namely , the
scheduling policy , must be specified . Second, the nondeterministic choice of the
clause from the program to effect the reduction must be implemented .
Several logic programming languages exist , reflecting different choices.
Loosely there are two categories . Prolog and its extensions (Prolog -II , IC -Prolog
and MU -Prolog , for example ) are based on sequential execution . Other languages ,
such as PARLOG , Concurrent Prolog and GHC , are based on parallel execution .
The treatment of nondeterminism distinguish es between sequential and parallel

languages . The distinction between Prolog and its extensions is in the choice of
goal to reduce .
Prolog 's execution mechanism is obtained from the abstract interpreter by
choosing the leftmost goal instead of an arbitrary one, and replacing the nondeterministic
choice of a clause by sequential search for a unifiable clause and
backtracking .
In other words , Prolog adopts a stack scheduling policy . It maintains the
resolvent as a stack : pops the top goal for reduction , and pushes the derived
goals on the resolvent stack .
In addition to the stack policy , Prolog simulates the nondeterministic choice
of reducing clause by sequential search and backtracking . When attempting to
reduce a goal , the first clause whose head unifies with the goal is chosen. H no
unifiable clause is found for the popped goal , the computation is unwound to the
last choice mode , and the next unifiable clause is chosen .
A computation of a goal G with respect to a Prolog program P is the generation

of all solutions of G with respect to P. In terms of logic programming
concepts , a Prolog computation on a goal G is a complete depth first traversal of
the particular search tree of G obtained by always choosing the leftmost goal .
Many different Prolog implementations exist . They differ in syntax , small
procedural matters , and the programming facilities . Here we largely follow the
conventions of Edinburgh Prolog . All our programs run in a particular implementation
, Wisdom Prolog . The syntax is what we have been using for logic programs
previously . Indeed many of the logic programs behave correctly as written .
A trace of a Prolog computation is an extension of the trace of a computation
of a logic program under the abstract interpreter as described in Section 4.2.
We revise the computations of Chapters 4 and 5 indicating the similarities and
differences. Consider the query son(X ,haran) '? with respect to Program 1.2, the
simplified Biblical database , repeated at the top of Figure 6.1. The computation
is given in the bulk of Figure 6.1. It corresponds to a depth -first traversal of the
first of the search trees in Figure 5.2. It is an extension of the first trace in Figure
4 .4 , since the whole search tree is searched .
The notation previously used for traces must be extended to handle failure
and backtracking . An f after a goal denotes that a goal failed , that is there
was no clause in the program whose head unified with the goal . The next goal
after a failed goal is where the computation proceeds on backtracking . It already
appears as a previous goal in the trace at the same depth of indentation , and can
be identified by the variable names . We adopt the Edinburgh Prolog convention
96 Pure Prolog 6.1
father ( abraham ,isaac) . male (isaac) .

father (haran ,lot ) . male (lot ) .
father (haran ,milcah ) . female (yiscah ) .
father (haran ,yiscah ) . female (milcah ) .
son(X ,Y ) +- fatherY ,X ), male(X ).

daughter(X ,Y ) +- fatherY ,X ), female(X ).
son(X ,haran)?
father (haran,X ) X = lot
male(lot )
true
Output : X = lot
,
father (haran,X ) X = milcah

male(milcah) f
father (haran,X ) X = yiscah
male(yiscah) f
No (more) choice points
Figure 6.1: Tracing a simple Prolog computation
that a 'j ' typed after a solution denotes a continuation of the computation to
search for more solutions . Unifications are j ' 1dicated as previously .
Trace facilities provided by particular Prolog implementations vary from our
description . For example , some Prolog implementations always give all solutions ,
while others wait for a user response after each solution .
The trace of append([a,b], [c, dj,Ls) ? giving the answer Ls = [a, b, c, dj is precisely
the trace given in Figure 4.3. Figure 4.5 giving the trace for solving the
Towers of Hanoi with 3 discs is also a trace of the hanoi program considered as
a Prolog program solving the query hanoi (s(s(s( O) ) ) a,b,c,Moves) ? The trace of
a deterministic computation is the same when considered as a logic program or a
Prolog program , provided the order of goals is preserved .
The next example is answering the query append(Xs , Ys,[a, b, c]) ? with respect
to Program 3.15 for append. There are several solutions of the query . The search
tree for this goal was given as Figure 5.3. Figure 6.2 gives the Prolog trace .
Tracing computations is a good way to gain understanding of the execution
model of Prolog . We give a slightly larger example , sorting a list with the quick -
append([X IXs],Ys,[X IZs]) f - append(Xs,Ys,Zs).

append([ ],Ys,Ys).
append(Xs,Ys,[a,b,c]) Xs= [aIXs1]
append(Xs1,Y s,[b,c]) Xs1= [bIXs2]
append(Xs2,Y s,[c]) Xs2= [cIXs3]
append(Xs3,Ys,[ ]) Xs3= [ ],Ys= [ ]
true
Output: (Xs= [a,b,c],Ys= [ ])

,
append(Xs2,Ys,[c]) Xs2= [ ],Ys= [c]

true
Output: (Xs= [a,b],Ys= [c] )

,
append(Xs1,Ys,[b,c]) Xs1= [ ],Ys= [b,c]

true
Output: (Xs= [a],Ys= [b,c])

.
append(Xs,Ys,[a,b,c]) Xs= [ ],Ys= [a,b,c]

true
Output: (Xs= [ ],Ys= [a,b,c])

.
no (more) solutions
Figure 6 .2: Multiple solutions for splitting a list
sort program (Program 3.22 reproduced here). Computations using quicksort are
essentially deterministic , and show algorithmic behavior of a Prolog program .
Figure 6.3 gives a trace of the query quicksort([2,1,9],Xs) ? Arithmetic comparisons
are assumedto be unit operations, and the standard program for appendis
used .
We introduce a distinction between shallow and deep backtracking . Shallow

backtracking occurs when the unification of a goal and a clause fails , and an
alternative clause is tried . Deep backtracking occurs when the unification of the
last clause of a procedure with a goal fails , and control returns to another goal in
the computation tree .
It is sometimes convenient to include , for the purpose of this definition , test
predicates that occur first in the body of the clause as part of unification , and
to classify the backtracking that occurs as a result of their failure as shallow .
98 Pure Prolog 6.1
quicksort([X IXs],Ys) +-
partition (Xs,X ,Littles ,Bigs) ,
quicksort(Littles ,Ls),
quicksort (Bigs,Bs) ,
append(Ls,[X IBs],Ys).
quicksort([ ],[ ]).
partition ([X IXs],Y ,[X ILs],Bs) +-
x ~ Y , partition (Xs,Y ,Ls,Bs).
partition ([X IXs],Y ,Ls,[X IBs]) +-
X > Y , partition (Xs,Y ,Ls,Bs).
partition ([ ],Y ,[ ],[ ]).
quicksort([2,1,3] ,Qs)
partition ([1,3],2,Ls,Bs)
152 Ls= [lILsl ]
partition ([3] ,2,Ls1,Bs)
352 f Lsl = [3ILs2]
partition ([3] ,2,Lsl ,Bs)
3 > 2 Bs= [3IBsl]
partition ([ ],2,Ls1,Bs1) Lsl = [ ]=Bsl
. quicksort([1],Qs1)
partition ([ ],1,Ls2,Bs2) Ls2 = [ ] = Bs2
quicksort([ ],Qs2) Qs2 = [ ]
append([ ],[1],Qs1) Qsl = [l ]
quicksort([3] ,Qs4)
partition ([ ],3,Ls3,Bs3) Ls3 = [ ] = Bs3
append([ ],[3],Qs4) Qs4 = [3 ]
append([1] ,[2,3],Qs) Qs = [ lIYs ]
append([ ],[2,3],Ys) Ys = [2 ,3 ]
true
Output : (Qs= [1,2,3])
Figure 6.3: Tracing a quicksort computation
An example is Figure 6.3 and the choice of a new clause for the goal partition
([9],2,Lsl ,Bs).
6.2 Comparison to conventional programming languages 99
(i ) Trace the execution of daughter(X ,haran) with respect to Program 1.2.

(ii ) Trace the execution of sort([3,1,2],Xs) ? with respect to Program 3.21.
(iii ) Trace the execution of sort([3,1,2],Xs) ? with respect to Program 3.20.
6.2 Comparison to conventional programming languages
A programming language is characterized by its control and data manipulation
mechanisms . Prolog , as a general purpose programming language , can
be discussed in these terms , as are conventional languages . In this section we
compare the control flow and data manipulation of Prolog to that of Algol - like
languages .
The control in Prolog programs is like in conventional procedural languages ,
as long as the computation progress es forward . Goal invocation corresponds to
procedure invocation , and the ordering of goals in the body of clauses corresponds
to sequencing of statements . Specifically , the clause A +- Bl ," . , Bn can be viewed
as a definition of a procedure A as follows :
procedure A
call Bl ,
call B2 ,
.
.
.
call Bn ,
end .
The recursive goal invocation in Prolog is similar in its behavior and its
implementation to that of conventional recursive languages . The differences show
when backtracking occurs . In a conventional language , if a computation cannot
proceed ( e . g . , all branch es of a case statement are false ) , a runtime error occurs . In
Prolog the computation is simply undone to the last choice made , and a different
computation path is attempted .
The data structures manipulated by logic programs , terms , correspond to
~
general record structures in conventional programming languages . The handling
of data structures is very flexible in Prolog . Like LISP , Prolog is a declaration
free , typeless language .

Other differencesin the use of data structures in Prolog arise from the nature
100 Pure Prolog 6.2
of logical variables . Logical variables refer to individuals rather than memory locations
. Consequently , having specified a particular individual , the variable cannot
be made to refer to another individual . In other words , logic programming does
not support destructive aBsignment where the contents of an initialized variable
can change.
Data m'anipulation in logic programs is achieved entirely via the unification

algorithm . Unification subsumes
. single assignment
. parameter passing
. record allocation
. read/ write -once field-accessin records

We discuss the trace of the quicksort program in Figure 6.3 pointing out the
various usesof unification . The unification of the initial goal quicksort( [2,1,3], Qs)
with the head of the procedure definition quicksort([XlXs ], Ys) illustrates several
features. The unification of [2,1,3] with the term [XlXs ] achievesrecord accessto
the list , and also selection of its two fields , the head and tail .
The unification of [1,9] with Xs achievesparameter passing to the partition

procedure , due to the sharing of the variables . This gives the first argument of
partition . Similarly , the unification of .2 with X passes the value of the second
parameter to partition .
Record creation can be seen with the unification of the goal partition
([1,9],.2,Ls,Bs) with the head of the partition procedure partition ([X] Ys],Z,
[X] Ls1],Bs1). As a result Ls is instantiated to [1ILs1]. Specifically, Ls is made
into a list and its head is assigned the value 1, namely record creation and field
assignment via unification .
These analogies may provide hints on how to implement Prolog efficiently

on a von Neumann machine . Indeed , the basic idea of compilation of Prolog
is to translate special cases of unification to conventional memory manipulation
operations , as specified above.
Conventional languages typically incorporate error -handling or exception -

handling mechanisms of various degrees of sophistication . Pure Prolog does not
have an error or exception mechanism built into its definition . The pure Prolog
counterparts of conventional programs which cause an error , e.g., a missing case
in a case statement , or dividing by zero , cause failure in pure Prolog .
Full Prolog , introduced in the following chapters , includes system predicates ,
such as arithmetic and I / O, which may causeerrors. Current Prolog implementations
do not have sophisticated error handling mechanisms. Typically , on an error
condition a system predicate prints an error message and either fails or aborts
6.3 Background 101
the computation .
This brief discussion of the different way of manipulating data does not help
with the more interesting question : How does programming in Prolog compare
with programming in conventional programming languages ? That is an implicit
topic in the rest of this book .
6 .3 Background
The origins of Prolog are shrouded in mystery . All that is known is that
the two founders Robert Kowalski , then at Edinburgh , and Alain Colmerauer at
Marseille worked on similar ideas during the early 70's, and even worked together
during one summer . The results were the formulation of the logic programming
philosophy and computation model by Robert Kowalski (1974), and the design
and implementation of the fIrst logic programming language , Prolog , by Alain
Colmerauer and his colleagues(1973).
A major force behind the realization that logic can be the basis of a practical
programming language has been the development of efficient implementation
techniques) as pioneered by Warren (1977). Warrens compiler identified special
cases of unification and translated them into efficient sequences of conventional
memory operations .
Variations of Prolog with extra control features, such as IC-Prolog (Clark
and McCabe, 1979), have been developed, but have proved too costly in run-
time overhead to be seriously considered as alternatives to Prolog . We will refer
to particular interesting variations that have been proposed in the appropriate
sections .
Another breed of logic programming languages , which indirectly emerged

from IC -Prolog , was concurrent logic languages . The first was the Relational
Language (Clark and Gregory, 1981), followed by Concurrent Prolog (Shapiro,
1983b) , Parlog (Clark and Gregory, 1984), GHC (Ueda, 1985), and a few other
proposals .
Referencesfor the variations mentioned in the text are: for Prolog-II (Van
Caneghem, 1982), IC-Prolog (Clark et al., 1982) and MU -Prolog (Naish, 1985a).
The syntax of Prolog stems from the clausal form of logic due to Kowalski
(1974). The original Marseille interpreter used the terminology of positive and
negative literals from resolution theory . The clause A +- Bl ," .,Bn was written
+ A - B1 . . .- Bn .
Warren et al . adapted Marseille Prolog for the DEC - 10, and their decisions
102 Pure Prolog 6.3
have been very influential . Many systems adopted most of the conventions of
Prolog - 10 (Warren et al ., 1979) , which has become known more generically as
Edinburgh Prolog . Its essential features are described in the widespread primer
on Prolog (Clocksin and Mellish , 1984) . This book draws mainly on Edinburgh
Prolog as described in its manual (Bowen et al ., 1981) .
A recent paper by Cohen ( 1985) delves further on the relation between Prolog
and conventional languages .
Chapter 7
PrograIn Ining
in Pure Prolog
A major aim of logic programming is to enable the programmer to program

at a higher level . Ideally one should write axioms that define the desired relationships
, maintaining ignorance of the way they are going to be used by the execution
mechanism . Current logic programming languages , Prolog in particular , are
still far away from allowing this ideal of declarative programming . The specific ,
well -defined choices of how their execution mechanisms approximate the abstract
interpreter cannot be ignored . Effective logic programming requires knowing and
utilizing these choices .
This chapter discusses the consequences of Prolog 's execution model for the
logic programmer . New aspects of the programming task are introduced . Not
only must the programmer come up with a correct and complete axiomatization
of a relationship , he must also consider its execution according to the model .
7 .1 Rule order
Two syntactic issues, irrelevant for logic programs , are important to consider
when composing Prolog programs . The rule order , or clause order , of clauses in
each Drocedure must be decided . Also the goal order of goals in the bodies of each
~
clause must be determined . The consequences of these decisions can be immense .

There can be orders of magnitude of difference in efficiency in the performance of
Prolog programs . In extreme , though quite common cases, correct logic programs
will fail to give solutions due to nontermination .
The rule order determines the order in which solutions are found .
104 Programmingin Pure Prolog 7.1
parent (terach,abraham). parent (abraham,isaac).

parent(isaacjacob). parent(jacob,benjamin).
ancestor(X ,Y ) -+- parent (X ,Y ).
ancestor(X ,Z) -+- parent (X ,Y ), ancestorY ,Z).
Program 7.1: Yet another family example
Changing the order of rules in a procedure permutes the branch es in any

search tree for a goal using that procedure . The search tree is traversed depth -
first . So permuting the branch es causes a different order of traversal of the search
tree , and a different order of finding solutions . The effect is clearly seen when
using facts to answer an existential query . With our Biblical database and a query
such asfather{X , Y) ? changing the order of facts will changethe order of solutions
found by Prolog . Deciding how to order facts is not very important .
The order of solutions of queries solved by recursive programs is also determined
by the clause order . Consider a simple Biblical database together with a
program for the relationship ancestor , given as Program 7.1.
For the query ancestor(terach,X) '?with respect to Program 7.1, the solutions
will be given in the order , X = abraham, X = isaac, X = jacob and X = benjamin . If
the order of the two rules defining ancestor is swapped , the solutions will appear
in a different order , namely X = benJ.amin , X = jacob , X = isaac and X = abraham.
The different order of ancestor clauses changes the order of searching the
implicit family tree . In one order , Prolog outputs solutions as it goes along . With
the order of the rules swapped , Prolog travels to the end of the family tree and
gives solutions on the way back . The desired order of solutions is determined by
the application , and the rule order of ancestor chosen accordingly .
Changing the order of clausesfor the memberpredicate (Program 3.12) also

changes the order of search. As written , the program search es the list until the
desired element is found . If the order of the clauses is reversed , the program
always searches to the end of the list . The order of solutions will also be affected ,
for example, responding to the query member(X,[1,2,S]) ? In the standard order,
the order of solutions is intuitive ; X = 1, X = 2, X = S. With the rules swapped , the
order is X = S, X = 2, X = 1. The order of Program 3.12 is more intuitive , and hence
preferable .
When the search tree for a given goal has an infinite branch , the order of
clausescan determine if any solutions are given at all. Consider the query append
(Xs,(c,dj, Ys) ? with respect to append. As can be seenfrom the search tree
in Figure 5. 4, no solutions would be given . If , however , the append fact appeared
7.2 Termination 105
before the append rule , an infinite number of pairs Xs , Ys satisfying the query
would be given .
There is no consensus as to how to order the clauses of a Prolog procedure .

Clearly , the standard dictated in more conventional languages , of testing for the
termination condition before proceeding with the iteration or recursion is not
mandatory in Prolog . This is demonstrated in Program 3.15 for append, as well as
in other programs in the book . The reason is that the recursive or iterative clause
tests its applicability by unification . This test is done explicitly and independently
of the other clauses in the procedure .
Clause order is more important for general Prolog programs than it is for
pure Prolog programs . Other control features , notably the cut to be discussed in
Chapter 11, depend si~ ficantly on the clause order . When such constructs are
used, clauses lose their independence and modularity , and clause order becomes
significant .
In the book we follow the convention that the recursive clauses precede the
base clauses.
Exercises for Section 7. 1
(i ) Verify the order of solutions for the query ancestor ( abraham ,X) with respect
to Program 7 .1, and its variant with different rule order for ancestor , claimed
in the text .
(ii ) What is the order of solutions for the query ancestor (X , benjamin ) with re -
spect to Program 7.1? What if the rule order for ancestor is swapped ?
7 . 2 Termination
Prolog 's depth -first traversal of search trees has a serious problem . If the
search tree of a goal with respect to a program contains an infinite branch , the
computation will not terminate . Prolog may fail to find a solution to a goal , even
though the goal has a finite computation .
Nontermination arises with recursive rules . Consider adding a relationship

married (Male ,Female) to our database of family relationships . A sample fact from
the Biblical situation is married ( abraham, sarah) . A user querying the married
relationship should not care whether males or females are first , as the relationship
is commutative . The "obvious " way of overcoming the commutativity is adding
a recursive rule married (X , Y) +- married ( Y,X) . If this is added to the program
106 Programmingin Pure Prolog 7.2
married ( X ,Y ) + - married ( Y , X ) .
married ( abraham , sarah ) .
married ( abraham , sarah )
married ( sarah , abraham )
married ( abraham , sarah )
married ( sarah , abraham )
Figure 7.1: A nonterminating computation
no computation involving married would ever terminate . For example , the trace
of the goal married ( abraham ,sarah) ? is given in Figure 7.1.
Recursive rules which have the recursive goal as the first goal in the body are
known as left recursive rules . The problematic married axiom is an example . Left
recursive rules are inherently troublesome in Prolog . They cause nonterminating
computations if called with inappropriate arguments .
The best solution to the problem of left recursion is avoidance . The married
relationsllip used a left recursive rule to express commutativity . Commutative
relationships are best handled differently , by defining a new predicate that has a
clause for each permutation of the arguments of the relationship . For the relationship
married , a new predicate , are_married (Personl ,Person2 ) say, would be
defined using two rules :
are-Inarried(X ,Y) +- married(X,Y).

are-Inarried(X,Y) +- married(Y,X).
Unfortunately , it is not generally possible to remove all occurrences of left recursion
. All the elegant minimal recursive logic programs shown in Chapter 3 are
left recursive , and can cause nontermination . However , the appropriate analysis ,
using the concepts of domains and complete structures introduced in Section 5.2,
can determine which queries will terminate with respect to recursive programs .
Let us consider an example , Program 3.15 for appending two lists . The
program for append is everywhere terminating for the set of goals whose first
and / or last argument is a complete list . Any append query whose first argument
is a complete list will terminate . Similarly all queries where the third argument is
a complete list will terminate . The program will also terminate if the first and / or
third argument is a ground term that is not a list . The behavior of append is best
summed up by considering the queries that do not terminate , namely when both
the first and third arguments are incomplete lists .
The condition for when a query to Program 3.12 for member terminates is
7.3 Goal order 107
also stated in terms of incomplete lists . A query does not terminate if the second
argument is an incomplete list . If the second argument of a query to member is a
complete list the query terminates .
Another guaranteed means of generating nonterminating computations , easy
to overlook , is circular definitions . Consider the pair of rules
parent ( X , Y ) + - child ( Y , X ) .
child ( X , Y ) + - parentY , X ) .
Any computation involving parent or child , for example , parent ( haran , lot ) ? , will
not terminate . The search tree necessarily contains an infinite branch , due to the
circular i ty .
( i ) Discuss the termination behavior of both programs in Program 3 . 13 determining
prefix es and suffix es of lists .
( ii ) Discuss the termination of Program 3 . 14c for sublist .
7 . 3 Goal order
Goal order is more significant than clause order . It is the principal means of
specifying sequential flow of control in Prolog programs . The programs for sorting
lists , e . g . , Program 3 . 22 for quicksort , exploit goal order to indicate the sequence
of steps in the sorting algorithms .
We first discuss goal order from the perspective of databa . se programming .
The order of goals can affect the order of solutions . Consider the query daughter
( X , haran ) ? with respect to a variant of Program 1 . 2 , where the order of the
facts female ( milcah ) and female ( yiscah ) is interchanged . The two solutions are
given in the order X = milcah , X = yiscah . H the goal order of the daughter rule
were changed to be daughter ( X , Y ) + - female ( X ) , fatherY , X ) the order of the
solutions to the query , given the same database , would be X = yiscah , X = milcah .
The reason that the order of goals in the body of a clause affects the order
of solutions to a query is different from the reason that the order of rules in a
procedure affects the solution order . Changing rule order does not change the
search tree that must be traversed for a given query . The tree is just traversed in
a different order . Changing goal order changes the search tree .
{ ioal order deter ~ ines the search tree .

108 Programming in Pure Prolog 7.3
Goal order affects the amount of searching the program does in solving a
query by determining which search tree is traversed . Consider the two search
trees for the query son ( X , haran ) ? given in Figure 5 .2 . They represent two different
ways of finding a solution . In the first case , solutions are found by searching
for children of haran and checking if they are male . The second case corresponds
to the rule for son being written with the order of the goals in its body swapped ,
namely as son ( X , Y) +- male ( X) , parentY , X) . Now the query is solved by searching
through all the males in the program and checking if they are children of
haran . If there were many male facts in the program , more search would be
involved . For other queries , for example , son ( sarah ,X) ? , the reverse order has
advantages . Since sarah is not male , the query would fail more quickly .
The optimal goal order of Prolog programs varies with different uses . Consider
the definition of grandparent . There are two possible rules .
grandparent (X ,Z ) +- - parent ( X ,Y ) , parentY ,Z ) .

grandparent (X ,Z ) +- - parentY ,Z ) , parent (X ,Y ) .
If you wish to find someone ' s grandson with the grandfather relationship with
a query such as grandparent ( abraham i X) ?, the first of the rules search es more
directly . If looking for someone ' s grandparent with a query such as grandparent
( X , isaac ) ?, the second rule finds the solution more directly . If efficiency is
important , then it is advisable to have two distinct relationships , grandparent
and grandchild , to be used appropriately at the user ' s discretion .
In contrast to rule order , goal order can determine whether computations

terminate . Consider the recursive rule for ancestor :
ancestor (X ,Y ) +- parent (X ,Z ) , ancestor ( Z ,Y ) .
If the goals in the body are swapped , the ancestor program becomes left recursive ,
and all Prolog computations with ancestor are nonterminating .
The goal order is also important in the recursive clause of the quicksort
algorithm in Program 3 .22 .
sort ( [X IXs ] ,Ys ) +-

partition (Xs ,X ,Ls ,Bs ) ,
sort ( Ls ,Lsl ) ,
sort ( Bs ,Bs 1 ) ,
append ( Lsl , [X IBsl ] ,Y s ) .
The list should be partitioned into its two smaller pieces before recursively sorting
the pieces . If , for example , the order of the partition goal and the recursive sorting
goal is swapped , no computations terminate .
7.3 Goal order 109
We next consider Program 3.16 for reversing a list :

reverse([X IXs],Zs) ~ reverse(Xs,Ys), append(Ys,[X ],Zs).
reverse([ ],[ ]).
The goal order is significant . As written , the program terminates with goals
where the first argument is a complete list . Goals where the first argument is an
incomplete list give nonterminating computations . If the order of the goals in the
recursive rule is swapped , the determining factor of the termination of goals is
the second argument . Calls to reverse with the second argument a complete list
terminate . They do not terminate if the second argument is an incomplete list .
A subtler example comes from the definition of the predicate sublist in terms
of two appendgoals, specifying the sublist as a suffix of a prefix , as given in Program
3.14e. Consider the query sublist([2,9],[1,2,9,4]) ? with respect to the program
. The query is reduced to append(A Xs,Bs,[1,2,9,4]),append(As,[2,9],A Xs) ?
This has a finite search tree , and the initial query succeeds. If Program
3.15e had its goals reversed, the initial query would be reduced to append
(As,[2,9],A Xs),append(A Xs,Bs,[1,2,9,4]) ? This leads to a nonterminating
computation due to the first goal , as illustrated in Figure 5.4.
A useful heuristic for goal order can be given for recursive programs with
tests such as arithmetic comparisons , or determining whether two constants are
different . The heuristic is to place the tests as early as possible . An example
comes in the program for partition , which is part of Program 3.22. The first
recursive rule is
partition ([X IXs],Y ,[X ILs],Bs) +- X ~ Y , partition (Xs,Y ,Ls,Bs).
The test X :::; Yshould go before the recursive call . This leads to a smaller search
tree .
In Prolog programming (in contrast, perhaps, to life in general) our goal is

to fail as quickly as possible . Failing early prunes the search tree , and brings us
to the right solution sooner .
(i ) Consider the goal order for Program 3.14d defining a sublist of a list as a
suffix of a prefix . Why is the order of the append goals in Program 3.14d
preferable ?
(Hint : Consider the query sublist(Xs,[a,b,c]) ?)
(ii ) Discuss the clause order, goal order and termination behavior for substitute,
posed as Exercise 3.3(i) .
7.4 Redundant solutions
An important issue when composing Prolog programs , irrelevant for logic
programs , is the irredundancy of solutions to queries . The meaning of a logic
program is the set of ground goals deducible from it . No distinction was made
between whether a goal in the meaning could be deduced uniquely from the program
, or whether it could be deduced in several distinct ways . The distinction
is important for Prolog when considering the efficiency of searching for solutions .
Each possible deduction means an extra branch in the search tree . The bigger
the search tree , the longer a computation will take . It is desirable in general to
keep the size of the search tree as small as possible .
Having a redundant program may cause , in an extreme case , exponential
increase in runtime , in the event of backtracking . If a conjunction of n goals
is solved , and each goal has one redundant solution , then in the event of backtracking
, the conjunction may generate 2n solutions , thus possibly changing a
polynomial - time program ( or even a linear one ) to be exponential .
One way for redundancy to occur in Prolog programs is by covering the same
case with several rules . Consider the following two clauses defining the relation
. .
m ~ n ~ mum .
minimum ( X , Y , X ) + - X ~ Y .
minimum ( X , Y , Y ) + - Y ~ X .
The query minimum ( 2 , 2 , M ) with respect to these two clauses has a unique solution
M = 2 which is given twice ; one is redundant .
Careful specification of the cases can avoid . the problem . The second clause
can be changed to
minimum ( X , Y , Y ) + - Y < X .
Now only the first rule covers the case when the two numbers have equal values .
Similar care is necessary with the definition of partition as part of Program
3 . 22 for quicksort . The programmer must ensure that only one of the recursive
clauses for partition covers the case when the number being compared is the same
as the number being used to split the list .
Another way redundancy appears in programs is by having too many special
cases . Some of these can be motivated by efficiency . An extra fact can be added
to Program 3 . 15 for append , namely append ( Xs , ( ] , Xs ) , to save recursive computations
when the second argument is an empty list . In order to remove redundancy ,

7.4 Redundant solutions 111
merge ( Xs , Ys , Zs ) +-
Zs is an ordered list of integers obtained from
merging the ordered lists of integers Xs and Y s.
merge ( [X I Xs ] , [ YIYs ] , [X I Zs ] ) +-
X < Y , merge ( Xs , [YIYs ] , Zs ) .
merge ( [X I Xs ] , [ YIYs ] , [X , X I Zs ] ) +-
X = Y , merge ( Xs , Y siZs ) .
merge ( [X I Xs ] , [ YIYs ] , [X I Zs ] ) +-
x > Y , merge ( [X I Xs ] , Ys , Zs ) .
merge ( [ ] , [X I Xs ] , [X I Xs ]) .
merge ( Xs , [ ] , Xs ) .
Program 7 .2 : Merging ordered lists
member - check ( X , Xs ) +-
X is a member of the list Xs .
member _ check ( X , [X I Xs ] ) .
member _ check ( X , [ YIYs ]) +- X =1= Y , member _ check ( X , Ys ) .
Program 7 .3 : Checking , for list membership
each of the other clauses for append would have to only cover lists with at lea Bt
one element aB their second argument .
We illustrate these points when composing Program 7 .2 for the relation
merge ( Xs , Ys , Zs ) , which is true if Xs and Ys are lists of integers sorted in ascending
order , and Zs is the ordered list resulting from merging them .
There are three separate recursive clauses . They cover the three possible
cases ; when the head of the first list is less than , equal to or greater than the head
of the second list . We discuss the predicates < , = , and > in Chapter 8 . Two
cases are needed when the elements in either list have been exhausted . Note that
we have been careful that the goal merge ( [ ] , [ ] , [ ] ) is only covered by one fact , the
bottom one .
Redundant computations occur when using member to find whether a particular

element occurs in a particular list , and there are multiple occurrences of
the particular element being checked for in the list . For example , the search tree
for the query member( a,[a, b, a, c]) would have two success nodes .
The redundancy of previous programs was removed by a careful consideration
of the logic . In this case the member program is correct . If we want a different
member ( a, [a,b ,a,c)) member _check ( a, (a,b ,a,c])

; / \ , / ~
true member ( a,[b ,a,c)) true a a, member _check (a,(b ,a,c])
/
member (a,[a,c])
/ \
true member (a, [c))
/
member (a,[ ))
Figure 7.2: Variant searchtrees
behavior , the solution is indeed to compose a modified version of member.

Program 7.3 defines the relationship member _check( X ,Xs ) which checks
whether an element X is a member of a list Xs . The program is a variant of
Program 3.12 for member which adds a test to the recursive clause . It has the
same meaning but behaves differently as a Prolog program . Figure 7.2 contains
search trees for the identical query to the two programs that show the difference
between them . The left tree is for the goal member ( a,[ a,b,a,c]) with respect to
Program 3.12. Note there are two success nodes . The right tree is for the goal
member _check( a, [a, b, a, c]) with respect to Program 7.3. It has only one success
node .
We restrict use of Program 7.3 to queries where both arguments are ground .
This is due to the way =;f is implemented in Prolog , to be discussed in Section
11.3.
7 .5 Recursive programming in pure Prolog
Lists are a very useful data structure for many applications written in Prolog .
In this section we revise several logic programs of Sections 3.2 and 3.3 concerned
with list processing . The chosen clause and goal orders are explained , and their
termination behavior presented . The section also discuss es some new examples .
Their properties are analyzed , and a reconstruction offered of how they are composed
.
Programs 3.12 and 3.15, for member and append respectively , are correct
Prolog programs as written . They are both minimal recursive programs , so there
is no issue of goal order . They are in their preferred clause order , the reasons for
which have been discussed earlier in the chapter . The termination of the programs
7.5 Recursive programming in pure Prolog 113
select - first ( X , Xs , Ys ) ~
Ys is the list obtained by removing the
first occurrence of X from the list Xs .
select Jirst ( X , [ X I Xs ] , Xs ) .
select Jirst ( X , [ YIYs ] , [ YIZs ] ) ~
X = 1 = Y , select - first ( X , Y siZs ) .
Program 7 . 4 : Selecting the first occurrence of an element from a list
was discussed in Section 7 . 2 .
Program 3 . 19 for select is analogous to the program for member .
select ( X , [ X I Xs } , Xs ) .
select ( X , [ YIXs } , [ YIYs ] ) ~ select ( X , Xs , Ys ) .
The analysis of select is similar to the analysis of member . There is no issue
of goal order as the program is minimal recursive . The clause order is chosen
to reflect the intuitive order of solutions to queries such as select ( X , [ a , b , c ] , Xs ) ,
namely { X = a , Xs = [ b , c ] } , { X = b , Xs = [ a , c ] } , { X = c , Xs = [ a , b ] } . The first solution is
the result of choosing the first element , and so forth . The program terminates
unless both the second and third arguments are incomplete lists .
A variant of select is obtained by adding the test X = fY in the recursive
clause . As before , we assume that = f is only defined for ground arguments
. The variant is given as Program 7 . 4 defining the relationship select
- first ( X , Xs , Ys ) . Program 3 . 12 and 7 . 2 defining member and member _ check
have the same meaning . Program 7 . 4 , in contrast , has a different meaning from
Program 3 . 19 . The goal select ( a , [ a , b , a , c ] , [ a , b , c ] ) is in the meaning of select ,
whereas select _ first ( a , [ a , b , a , c ] , [ a , b , c ] ) is not in the meaning of select - first .
The next program considered is Program 3 . 20 for permutation . The order of
clauses , analogously to the clause order for append , reflects the more likely mode
of use :
permutation ( Xs , ( XIY a ] ) + - select ( X , Xs , Zs ) , permutation ( Zs , Y s ) .
permutation ( ( ] , ( ] ) .
The goal order and the termination behavior of permutation are closely related .
Computations of permutation goals where the first argument is a complete list
will terminate . The query calls select with its second argument a complete list ,
which terminates generating a complete list as its third argument . Thus there
is a complete list for the recursive permutation goal . If the first argument is an
nonmember ( X , Xs ) + -
X is not a memberof the list Xs.

nonmember ( X , [ YIYs ] ) ~ x # Y , nonmember(X ,Ys).
nonmember ( X , [ ] ) .
Program 7 . 5 : Non -membership of a list
members(Xs , Ys) +-
Each element of the list Xs is a member of the list Ys.
members ( [X IXs ],Ys ) +- member (X ,Ys ) , members (Xs ,Ys ) .
members ( [ ],Ys ) .
Program 7.6 : Testing for a subset
incomplete list , the permutation query will not terminate , because it calls a select
goal that will not terminate . If the order of the goals in the recursive rule for
permutation is swapped , the second argument of a permutation query becomes
the significant one for determining termination . If it is an incomplete list , the
computation will not terminate ; otherwise it will .
A useful predicate using # is non _member (X , Ys) which is true if X is not a

member of a list Ys. Declaratively the definition is straightforward : an element
is a nonmember of a list if it is not the head and is a nonmember of the tail . The
base case is that any element is a nonmember of the empty list . This program is
given as Program 7.5.
Because of the use of :tf, nonmember is restricted to ground instances . This is
sensible intuitively . There are arbitrarily many elements which are not elements of
a given list , and also arbitrarily many lists not containing a given element . Thus
the behavior of Program 7.5 with respect to these queries is largely irrelevant .
The clause order of nonmember follows the convention of the recursive clause
preceding the fact . The goal order uses the heuristic of putting the test before
the recursive goal .
We reconstruct the composition of two programs concerned with the "subset "
relationship . Program 7.6 defines a relationship based on Program 3.12 for member
, while Program 7.7 defines a relationship based on Program 3.19 for select.
Both consider the occurrences of the elements of one list in a second list .
Program 7.6 defining members(Xs , Ys) ignores the multiplicity of elements in

the lists . For example , members( [b, b],[a,b,c]) is in the meaning of the program .
There are two occurrences of b in the first list , but only one in the second.
selects(Xs,
- Ys)- +-
The list Xs is a subset of the list Ys.
selects((X IXs],Ys) i - select(X ,Ys,Ysl ), selects(Xs,Ysl ).

selects(( ],Ys).
select(X ,Ys,Zs) ~ SeeProgram 3.19.
Program 7.7: Testing for a subset
Program 7.6 is also restrictive with respect to termination . If either the first
or the second argument of a members query is an incomplete list the program will
not terminate . The second argument must be a complete list due to the call to
member, while the first argument must also be complete , since that is providing
the recursive control . The query members(Xs ,[1,2,9]) ? asking for subsets of a
given set does not terminate . Since multiple copies of elements are allowed in
Xs , there are an infinite number of solutions , and hence the query should not
terminate .
Both these limitations are avoided by Program 7.7. The revised relation is
selects( X sY s) . Goals in the meaning of Program 7.7 have at most as many copies
of an element in the first list as appear in the second. Related to this property ,
Program 7.7 terminates whenever the second argument is a complete list . A query
such as selects(Xs ,[ a,b, c]) has as solution all the subsets of a given set.
We now consider a different example : translating a list of English words , word
for word , into a list of French words . The relationship is translate ( Words,Mots )
where Words is a list of English words , and Mots the corresponding list of
French words . Program 7. performs the translation . It assumes a dictionary
of pairs of corresponding English and French words , the relation scheme being
dict ( Word,Mot ) . The translation is very naive , ignoring issues of number , gender ,
subject -verb agreement , and so on . Its range is solving a query such as translate
( [the,dog,chases,the,cat]) ,X) ? with solution X = [le,chien ,chasse,le, chat]. This
program can be used in multiple ways . English sentences can be translated to
French , French ones to English , or two sentences can be checked if they are correct
mutual translations .
Program 7.8 is a typical program performing mapping , that is , converting

one list to another by: applying some function to each element of the list . The
clause order has the recursive rule (s) first , and the goal order calls dict first , so
as not to be left recursive .
We conclude the section with a discussion of the use of data structures in Prolog
programs . Data structures are handled somewhat differently in Prolog than
translate( Words,Mots) i --
Mots is a list of French words which is the
translation of the list of English words Words.
translate ([Word IWords],[Mot IMots]) -f-.

dict (Word,Mot ), translate (Words,Mots).
translate ([ ],[ ]).
dict (the,le). dict (dog,chien).
dict (chases,chasse). dict (cat,chat).
Program 7 .8 : Translating word for word
in conventional programming languages . Rather than having a global structure ,

all parts of which are accessible, the programmer specifies logical relationships
between various substructures of the data .
Taking a more procedural view , in order to build and modify structures ,

the Prolog programmer must pass the necessary fields of the structure to subprocedures
. These fields are used and / or acquire values during the computation .
Assignment of values to the structures happens via unification .
Let us look more closely at a generic example - producing a single output
from some given input . Examples are the standard use of append, joining two lists
together to get a third , and using Program 7.8 to translate a list of English words
into French . The computation proceeds recursively . The initial call instantiates
the output to be an incomplete list [.X1Xs]. The head Xis instantiated by the call
to the procedure , often in unification with the head of the clause. The tail Xs is
progressively instantiated while solving the recursive call . The structure becomes
fully instantiated with the solution of the base case and the termination of the
computation .
Consider appending the list [c, dj to the list [a, b] as illustrated in Figure
4.3. The output Ls = [a, b, c,dj is constructed in stages, as Ls = [aIZs], Zs= [bIZsl ],
and finally Zsl = [c, dj, when the base fact of append is used. Each recursive call
partially instantiates the originally incomplete list . Note that the recursive calls
to append do not have access to the list being computed . This is a top -down
construction of recursive structures , and is typical of programming in Prolog .
The top -down construction of recursive data structures has one limitation .
Pieces of the global data structure cannot be referred to deeper in the computation
. This is illustrated in a program for the relation no_doubles(XXs ,Xs ) which is
true if Xs is a list of all the elements appearing in the list XXs with all duplicates
removed .
no_doubles(Xs, Ys) +-
Ys is the list obtained by removing
duplicate elements from the list Xs .
no_doubles([X IXsJ,Ys) +-
member(X ,Xs), no_doubles(Xs,Ys).
no_doubles([X IXs],[X IYs]) +-
nonmember(X ,Xs), no_doubles(Xs,Y s).
no_doubles([ J,[ ]).
nonmember(X ,Xs) +- SeeProgram 7.5.
Program 7.9 : Removing duplicates from a list
Consider trying to compose no_doubles top -down . The head of the recursive
clause
will be
no_doubles([X IXs],' . .) +-
where we need to fill in the blank . The blank is filled by calling no_doubles
recursively on Xs with outputY s and integrating Ys with X . If X has not appeared
in the output so far , then it should be added, and the blank will be [XI VB]. If X
has appeared , then it should not be added and the blank is Ys. This cannot be
easily said . There is no way of knowing what the output is so far .
The program for no_doubles is composed by thinking differently about the
problem . Instead of determining whether an element has already appeared in the
output , we can determine whether it will appear . Each element X is checked to
see if it appears again in the tail of the list Xs . If X appears , then the result is
Y s, the output of the recursive call to no _doubles . If X does not appear , then it
is added to the recursive result . This version of no_doubles is given as Program
7.9. It uses Program 7.5 for nonmember .
A problem with Program 7.9 is that the list without duplicates may not have
the elementsin the desired order. For example, no_doubles([a,b,c,b],Xs) ? has the
solution Xs= [a,c,b], where the solution Xs= [a,b,c] may be preferred. This latter
result is possible if the program is rewritten . Each element is deleted from the
remainder of the list as it is found . In terms of Program 7.9 this is done by
replacing the two recursive calls by a rule
no_doubles([X IXs],[X IYs]) +- delete(X ,Xs,Xsl ), no_doubles(Xsl ,Ys).
The new program builds the output top -down . However it is inefficient for large
lists , as will be discussed in Chapter 13. Briefly each call to delete rebuilds the
whole structure of the list .
nd _ reverse ( Xs , Ys ) + -
Ys is the reversal of the list obtained by
removing duplicate elements from the list Xs .
nd . : reverse ( Xs ,Ys ) f - nd . : reverse ( Xs , [ ] ,Ys ) .
nd - I everse ( [X IXs ] ,Revs ,Ys ) ~

member ( X ,Revs ) , nd - I everse ( Xs , Revs ,Y s ) .
nd - I everse ( [X IXs ] ,Revs ,Ys ) ~
noll - Inember ( X ,Revs ) , nd - I everse ( Xs , [X I Revs ] , Ys ) .
nd - I everse ( [ ] , Y sY s) .
nonmember ( X ,Xs ) + - See Program 7 .5 .
Program 7 . 10 : Reversing with no duplicates
reverse ( [ a ,b ,c ] ,Xs )
reverse ( [ a ,b ,c ] , [ ] ,Xs )
reverse ( [b ,c ] , [a ] ,Xs )
reverse ( [c ] , [b , a ] ,Xs )
reverse ( [ ] , [c ,b , a ] ,Xs ) Xs = [c ,b , a ]
true
Figure 7 .3 : Tracing a reverse computation
The alternative to building structures top - down is building them bottom - up .

A simple example of bottom - up construction of data structures is Program 3 . 16b
for reversing a list :.
reverse ( Xs , Y s ) + - reverse ( Xs , [ ] , Y s ) .
reverse ( [X IXs ] ,Revs ,Ys ) + - reverse ( Xs , [X I Revs ] ,Ys ) .
reverse ( [ ] ,Ys ,Ys ) .
An extra argument is added to reverse / 2 and used to accumulate the values of the
reversed list as the computation proceeds . This procedure for reverse builds the
output list bottom - up rather than top - down . In the trace in Figure 7 .3 solving
the goal reverse ( [ a , b , c ] , Xs ) , the successive values of the middle argument of the
calls to reverse / 3 [ ] , [ a ] , [ b , a ] , and [ c , b , a ] represent the structure being built .
A bottom - up construction of structures allows access to the partial results
of the structure during the computation . Consider a relation nd _reverse ( Xs , Ys )

combining the effects of no _ doubles and reverse . The meaning of nd _reverse is
that Y s is a list of elements in Xs in reverse order and with duplicates removed .
7.6 Background 119
Analogously to reverse , nd _ reverse calls nd _ reverse / 9 with an extra argument that
builds the result bottom up . This argument is checked to see whether a particular
element appears , rather than checking the tail of the list as in Program 7 .6 for
no _ doubles . The program is given as Program 7 . 10 .
We emphasize the characteristics of bottom - up construction illustrated here .
One argument behaves as an accumulator of the final data structure . It is augmented
in the recursive call , so that the more complex version is in the body of
the clause rather than in its head . This contrasts with top - down construction ,
where the more complex version of the data structure being built is in the head
of the clause . Another argument is used solely for returning the output , namely
the final value of the accumulator . It is instantiated with the satisfaction of the
base fact . The argument is explicitly carried unchanged in the recursive call .
The technique of adding an " accumulator " to a program can be generalized .
It is used in the next chapter discussing Prolog programs for arithmetic . Accu -
mulators can also be viewed as a special case of incomplete data structures , as
will be discussed in Chapter 15 .
Exercise for Section 7 . 5
( i ) Write Program 7 .9 for no _ doubles building the structure bottom - up .
7 . 6 Background
Prolog was envisaged as a first approximation to logic programming , which
would be superseded by further research . Its control has always been acknowledged
as limited and naive . An oft - cited slogan credited to Kowalski ( 1979b ) is
" Algorithm = Logic + Control ." The particular control provided in pure Prolog
was intended as just one solution on the path to declarative programming and
intelligent control . Time has shown otherwise . The control of Prolog has proven
adequate for a large range of applications , and the language has not only endured ,
but has blossomed .
Nonetheless , logic programming researchers have investigated other forms
of control . For example , LOGLISP ( Robinson and Sibert , 1982 ) has breadth -
first traversal of the search tree , and IC - Prolog ( Clark and McCabe , 1978 ) has
co - routining . MU - Prolog ( Naish , 1985a ) allows suspension to provide a correct
implementation of negation , and to prevent the computation from searching infinite
branch es in certain cases . Wait declarations are generated ( Naish , 1985a )

which are related to the conditions on termination of Prolog programs given in

Section 7.2.
Other researchon analyzing the properties of Prolog programs is reported in
Mellish (1985).
Chapter 8
Ari th I Detic
The logic programs for performing arithmetic presented in Section 3.1 are
very elegant , but they are not practical . Any reasonable computer provides very
efficient arithmetic operations directly in hardware , and practical logic programming
languages cannot afford to ignore this feature . Computations such as addition
take unit time on most computers independent of the size of the addends (as
long as they are smaller than some large constant ) . The recursive logic program
for plus (Program 3.3) takes time proportional to the first of the numbers being
added . This could be improved by switching to binary or decimal notation , but
still won 't compete with direct execution by dedicated hardware .
8 .1 System predicates for arithmetic
The role of the arithmetic predicates introduced in Prolog is to provide an

interface to the underlying arithmetic capablities of the computer in a straightforward
way . The price paid for this efficiency is that some of the machine oriented
arithmetic operations are not as general as their logical counterparts . The interface
provided is an arithmetic evaluator , which uses the arithmetic facilities of the
underlying computer . Edinburgh Prolog has a binary operator is for arithmetic
evaluation . We prefer the more conventional binary operator ' := ' for the identical
predicate .
Operators are used in order to make programs more readable . People are
very flexible and learn to adjust to strange surroundings - they can become accustomed
to read Lisp and Fortran programs , for example . We believe nonetheless
that syntax is important ; the power of a good notation is well known from mathematics
. An integral part of a good syntax for Prolog is the ability to specify and
use operators .
122 Arithmetic 8.1
Operators have been used in earlier chapters , for example , i = and < . We assume
Prolog provides several operators , and introduce them as they arise . Most
Prologs give the user the ability to define his own binary infix , and unary prefix
and postfix operators . Some form of operator declaration is necessary to specify
the relative precedence , name , and associative behavior of each operator . The
mechanism for specifying this information varies . The form of operator declarations
in Edinburgh and Wisdom Prolog is given in Appendix C , together with a
list of all operators used in this book and their relative precedences .
The basic query to the evaluator has the form Value : = Expression ? , and is
read " Value is Expression . " It is interpreted as follows . Expression is evaluated
as an arithmetic expression . The result of a successful evaluation is unified with
Value , the goal succeeding or failing accordingly .
Here are some examples of simple addition , illustrating the use and behavior
of the evaluator . The goal ( X : = 9 + 5 ) ? has the solution X = 8 . This is the
standard use of the evaluator , instantiating a variable to the value of an arithmetic
expression . The goal ( 8 : = 9 + 5 ) ? succeeds . Having both arguments to " : = "
instantiated allows checking of the value of an arithmetic expression . ( 9 + 5 : =
9 + 5 ) ? fails because the left - hand argument , 9 + 5 , does not unify with 8 , the
result of evaluating the expression .
The evaluator allows the standard operators for addition , subtraction , multiplication
and division ( + , - , * , f ) , with their precedence from mathematics . We
restrict ourselves in this book to integer arithmetic . Thus f denotes integer division
, and mod denotes integer remainder .
What happens if the term to be evaluated is not a valid arithmetic expression ?
An expression can be invalid for one of two reasons , which should be treated
differently , at least conceptually . A term such as 3 + x for a constant x cannot be
evaluated . In contrast , a term 3 + Yfor a variable Ymay or may not be evaluable ,
depending on the value of Y .
The semantics of any logic program is completely defined , and , in this sense ,
logic programs Ca Iillot have runtime " errors . " For example , the goal X : = 3 + Yhas
solutions { X = 3 , Y = O } . However , when interfacing logic programs to a computer ,
the limitations of the machine should be taken into account . A runtime error
occurs when the machine cannot determine the result of the computation due
to insufficient information , that is , uninstantiated variables . This is distinct from
goals that simply fail . Extensions to Prolog and other logic languages handle such
" errors " by suspending until the values of the concerned variables are known . The
execution model of Prolog as introduced does not permit suspension . Instead of
simply failing , we sayan error condition occurs .

8.2 Arithmetic logic programs revisited 123
The goal ( X : = 9 + x ) ? fails , because the right - hand argument cannot be
evaluated as an arithmetic expression . The goal ( X : = 9 + Y ) ? is an example of a
goal which that succeed if ' Ywere instantiated to an arithmetic expression . Here
an error condition should be reported .
A common misconception of the Prolog beginner is to regard " : = " ~ taking
the place of assignment that is familiar from conventional languages . It is tempting
to write a goal such ~ ( N : = N + l ) ? This is meaningless . The goal fails if N
is instantiated , or causes an error if N is a variable .
The " : = " predicate is an example of a system predicate . System predicates
are provided by the Prolog system for use by the programmer . Another term for
a system predicate is an evaluable predicate . Appendix B contains a description
of the system predicates of Wisdom Prolog used in this book .
Further system predicates for arithmetic are the comparison operators . Instead
of the logically defined < , , 5 , > , 2 , Prolog directly calls the underlying
arithmetic . We describe the behavior of < ; the others are virtually identical . To
answer the query ( A < B ) ' I , A and B are evaluated as arithmetic expressions .
The two resultant numbers are compared , and the goal succeeds if the result of
evaluating A is less than the result of evaluating B . Again if A or B is not an
arithmetic expression the goal will fail , and an error condition should result if A
or B are not ground .
Here are some simple examples . The goal ( 1 < 2 ) ? succeeds , as does the
goal ( 3 - 2 < 2 * 3 + 1 ) ? On the other hand , ( 2 < 1 ) ? fails , and ( N < 1 ) ? generates
an error when N is a variable .
Tests for equality and inequality of values of arithmetic expressions are implemented
via the system predicates = : = and = / = , which evaluate both of their
arguments and compare the resulting values .
8 . 2 Arithmetic logic programs revisited
Performing arithmetic via evaluation rather than logic demands a reconsideration
of the logic programs for arithmetic presented in Section 3 . 1 . Calculations
can certainly be done more efficiently . For example , finding the minimum of two
numbers can use the underlying arithmetic comparison . The program syntactically
need not change from Program 3 . 7 . Similarly , the greatest common divisor
of two integers can be computed efficiently using the usual Euclidean algorithm ,
given as Program 8 . 1 . Note that the explicit condition J > 0 is necessary to avoid
multiple solutions when J = O and errors from calling mod with a zero argument .
124 Arithmetic 8.2
greatest_common _divisor (X , Y,Z) . -

Z is the greatest common divisor of the integers X and Y.
greatest _common _divisor (I ,O,I ) .

greatest _common _divisor (I ,J ,Gcd ) -+-
J > 0, R := I mod J , greatest _common _divisor (J ,R ,Gcd ) .
Program 8 .1: Computing the greatest common divisor of two integers
Two features of logic programs for arithmetic are missing from their Prolog
counterparts . First , multiple uses of programs are restricted . Suppose we wanted
a predicate plus (X , Y,Z) that performed as before , built using " := " . The obvious
definition is
plus(X,Y ,Z) f - Z := X+ Y.
This works corre Gtly if X and Yare instantiated to integers . However , we cannot
use the same program for subtraction with a goal such as plus ( 9,X ,8) ?, which
raises an error condition . Metalogical tests are needed if the same program is
to be used for both addition and subtraction . We defer this until metalogical
predicates are introduced in Chapter 10.
Programs effectively become specialized for a single use, and it is tricky to
understand what happens when the program is used differently . Program 3.7 for
minimum , for example , can be used reliably only for finding the minimum of two
integers .
The other feature missing from Prolog programs for arithmetic is the recursive
structure of numbers . In logic programs , the structure is used to determine
which rule applies , and to guarantee termination of computations . Prugram 8.2 is
a Prolog program for computing factorials closely corresponding to Program 3.6.
The recursive rule is more clumsy than before . The first argument in the recursive
call of factorial must be calculated explicitly , rather than emerging as a result
of unification . Furthermore , the explicit condition determining the applicability
of the recursive rule , N > 0, must be given . This is to prevent nonterminating
computations with goals such as factorial ( - 1,N) ? or even factorial (3,F) ? Previously
, in the logic program , unification with the recursive structure prevented
nonterminating computations .
Program 8.2 corresponds to the standard recursive definition of the factorial
function . Unlike Program 3.7, the program can be used only to calculate the
factorial of a given number . A factorial query where the first argument is a
variable will cause an error condition .
jactorial (N,F) +-
F is the integer N factorial .
factorial(N,F) +-
N > 0, Nl := N- l , factorial(Nl ,Fl ), F := N*Fl .
factorial(Oil).
Program 8.2: Computing the factorial of a number
We must modify the concept of correctness of a Prolog program to accommodate

behavior wit ,h respect to arithmetic tests . Other system predicates that
generate runtime "errors " are handled similarly . A Prolog program is totally correct
over adomainD of goals if for all goals in D the computation terminates ,
does not produce a runtime error , and has the correct meaning . Program 8.2 is
totally correct over the domain of goals where the first argument is an integer .
(i) The Nfh triangular number is the sum of the numbers up to and including N.
Write a program for the relation triangle (N, 1) where T is the Nfh triangular
number .
(Hint : Adapt Program 8.2.)

(ii ) Write a Prolog program for power (X ,N , V) , where V equals XN . Which way
can it be used?
(Hint : Model it on Program 3.5 for exp.)
(iii ) Write Prolog programs for other logic programs for arithmetic given in the
text and exercises in Section 3.1.
8.3 Transforming recursion into iteration
In Prolog there are no iterative constructs as such, and a more general concept
, namely recursion , is used to specify both recursive and iterative algorithms .
The main advantage of iteration over recursion is in efficiency , mostly space efficiency
. In the implementation of recursion , a data structure (called a stack -frame )
has to be maintained for every recursive call that has not terminated yet . A recursive
computation involving n recursive procedure calls would require , therefore ,
space linear in n. On the other hand , an iterative program typically uses only a
constant amount of memory , independent of the number of iterations .
126 Arithmetic 8.3
factorial (N);
1 .. -- O., T .-
. -
1 .,
while 1 < N do
1 := 1+ 1 ; T := T * 1 end ;
return T
Figure 8 .1: Computing factorials iteratively
Nevertheless , there is a restricted class of recursive programs that corresponds

quite closely to conventional iterative programs . Under some conditions , to be
explained further in Section 11.2 on tail recursion optimization , such Prolog programs
can be implemented almost with the same efficiency as iterative programs
in conventional languages . For this reason , it is preferable to express a relation
using an iterative program ) if possible . In this section we show how recursive
programs can be made iterative using accumulators .
Recall that a pure Prolog clause is iterative if it has one recursive call in the
body . We extend this notion to full Prolog , and allow zero or more calls to Prolog
system predicates before the recursive call . A Prolog procedure is iterative if it
contains only unit clauses and iterative clauses.
Most simple arithmetic calculations can be implemented by iterative pro -

grams .
Factorials can be computed , for example , in a loop where the numbers up

to the desired factorial are multiplied together . A procedure in a Pascal-like
language using a while loop is given in Figure 8.1. Its iterative behavior can be
encoded directly in Prolog with an iterative program .
Prolog does not have storage variables , which can hold intermediate results of
the computation and can be modified as the computation progress es. Therefore to
implement iterative algorithms , which require the storage of intermediate results ,
Prolog procedures are augmented with additional arguments , called accumulators .
Typically , one of the intermediate values constitutes the result of the computation
upon termination of the iteration . This value is unified with the result variable
using the unit clause of the procedure .
This technique is demonstrated by Program 8.3, which is a Prolog definition
of factorial that mirrors the behavior of the while loop in Figure 8.1. It uses
factorial (I ,N, T,F) which is true if F is the value of N factorial , and I and Tare
the values of the corresponding loop variables before the (1+ 1)th iteration of the
loop .
The basic iterative loop is performed by the iterative procedure factorial/ 4.
factorial (N ,F)
factorial ( N ,F ) +- factorial ( O ,N , I ,F ) .
factorial ( I ,N ,T ,F ) +-
I < N , 11 := 1+ 1 , Tl := T * Il , factorial ( Il , N , Tl ,F ) .
factorial ( N ,N ,F ,F ) .
Program 8 .3 : An iterative factorial
factorial ( N ,F) +-
factorial ( N ,F ) +- factorial ( N , 1 ,F ) .
factorial ( N ,T ,F ) +-
N > 0 , Tl := T * N , Nl := N- l , factorial(Nl ,Tl ,F).

factorial ( O ,F ,F ) .
Program 8 .4 : Another iterative factorial
Each reduction of a goal using factorial / 4 corresponds to an iteration of the while
loop . The call of factorial / 4 by factorial / ! ! corresponds to the initialization stage .
The first argument of factorial / 4 , the loop counter , is set to o .
The third argument of factorial / ; ' is used as an accumulator of the running
value of the product . It is initialized to 1 in the call to factorial / ; ' by factorial / 2 .
The handling of both accumulators in Program 8 . 3 is a typical programming
technique in Prolog . It is closely related to the use of accumulators in Programs
3 . 16b and 7 . 10 for collecting elements in a list .
Accumulators are logical variables , rather than locations in memory . The
value is passed between iterations , not an address . Since logical variables are
" write - once , " the updated value , a new logical variable , is passed each time . Stylis -
tically , we will use variable names with the suffix 1 , for example , T1 and 11 , to
indicate updated values .
The computation terminates when the counter I equals N . The rule for factorial
/ 4 in Program 8 . 3 no longer applies , and the fact succeeds . With this successful
reduction , the value of the factorial is " returned . " This happens as a result of the
unification with the accumulator in the base clause . Note that the logical variable
representing the solution , the final argument of factorial / 4 , had to be carried
throughout the whole computation to be set on the final call of factorial . This
passing of values in arguments is characteristic of Prolog programs , and might

128 Arithmetic 8.3
between(I ,J,K) +-
K is an integer between the integers I and J, inclusive .
between(I ,J ,1) +- I ~ J.
between(I ,J,K ) +- I < J, 11 := 1+ 1, between(ll ,J,K ).
Program 8 .5: Generating a range of integers
seem strange to the newcomer .
Program 8.3 shows the exact reflection of the while loop for factorial given in
Figure 8.1. Another iterative version of factorial can be written by counting down
from N to 0 , rather than up from 0 to N . The basic program structure remains
the same, and is given as Program 8.4. There is an initialization call that sets the
value of the accumulator , and recursive and base clauses implementing the while
loop .
Program 8.4 is marginally more efficient than Program 8.3. In general , the
fewer arguments a procedure has , the more readable it becomes, and the faster it
runs .
A useful iterative predicate is between(I ,J,K) , which is true if K is an integer

between I and J inclusive . It can be used to generate non determinist ically integer
values within a range . This is useful in generate- and-test programs , explained in
Section 14.1, and in failure - driven loops , explained in Section 12.5.
Iterative programs can be written for calculations over lists of integers as
well. Consider the relation sumlist(IntegerList ,Sum) where Sum is the sum of the
integers in the list Integer List . We present two programs for the relation . Program
8.6a is a recursive formulation . To sum a list of integers , sum the tail , and then
add the head . Program 8.6b uses an accumulator to compute the progressive
sum precisely as Program 8.3 for factorial uses an accumulator to compute a
progressiveproduct . An auxiliary predicate sumlist/ 9 is introduced with an extra
argument for the accumulator , whose starting value , 0, is set in the initial call to
sumlist/ 9. The sum is passedout in the final call by unification with the basefact.
The only difference between Program 8.6b and the iterative versions of factorial
is that the recursive structure of the list is used to control the iteration rather
than a counter .
Let us consider another example . The inner product of two vectors Xi , Yi

is the sum Xl . Y 1 + . . . + Xn . Y n . If we represent vectors as lists it is immediate to
write a program for the relation inner_product(Xs, Ys,IP ) where IP is the inner
product of Xs and Ys. Programs 8.7a and 8.7b are recursive and iterative versions ,
respectively . The iterative version of inner _product bears the same relation to the
8.3 Thansforming recursion into iteration 129
sumlist ( ls , Sum ) + -
Sum is the sum of the list of integers Is .
sumlist ( ( I I Is J , Sum ) + - sumlist ( Is , Is Sum ) , Sum := I + Is Sum .
sumlist ( ( ] ,0 ) .
Program 8 . 6a : Summing a list of integers
sumlist ( Is , Sum ) + -
Sum is the sum of the list of integers Is .
sumlist ( Is , Sum ) + - sumlist ( Is , O , Sum ) .
sumlist ( [ I I Is ] , Temp , Sum ) ~
TempI := Temp + I , sumlist ( Is , TempI , Sum ) .
sumlist ( [ ] , Sum , Sum ) .
Program 8 . 6b : Iterative version of summing a list
of integers using an accumulator
recursive inner _product that Program 8.6b for sumlist bears to Program 8.6a.
Both Programs 8.7a and 8.7b are correct for goals inner _product (Xs , Ys,Zs)
where Xs and Y s are lists of integers of the same length . There is a built -in check
that the vectors are of the same length . The programs fail if Xs and Y 8 are of
different lengths .
The similarity of the relationship between Programs 8.6a and 8.6b , and between
Programs 8.7a and 8.7b suggests that one may be automatically transformed
to the other . The transformation of recursive programs to equivalent
iterative programs is an interesting research question . Certainly it can be done
for the simple examples shown here .
The sophistication of a Prolog program depends on the underlying logical
relationship it axiomatizes . Here is a very elegant example of a simple Prolog
program solving a complicated problem .
Consider the following problem : Given a closed planar polygon chain
{ Pl ,P2,. . .,Pn } , compute the area of the enclosed polygon , and the orientation of
the chain . The area is computed by the line integral
1/ 2 Jxdy - ydx
where the integral is over the polygon chain .
The solution is given in Program 8.8, which defines the relation area( Chain ,
130 Arithmetic 8.3
inner _ product ( Xs , Ys , Value ) t -
Value is the inner product of the vectors
represented by the lists of integers Xs and Ys .
inner _ product ( [X I Xs ] , [ YIYs ] , IP ) + -
inner _ product ( Xs , Ys , IP1 ) , IP := X * Y + IPI .
inner _ product ( [ ] , [ ] ,0 ) .
Program 8 . 7a : Computing inner products of vectors
inner _ product ( Xs , Ys , Value ) + -
Value is the inner product of the vectors
represented by the lists of integers Xs and Y s .
inner _ product ( Xs , Ys , IP ) + - inner _ product ( Xs , Ys , O , IP ) .
inner _ product ( [X I Xs ] , [ YIYs ] , Temp , IP ) + -
Tempi := X * Y + Temp , inner _ product ( Xs , Ys , Tempi , IP ) .
inner - product ( [ ] , [ ] , IP , IP ) .
Program 8 . 7b : Computing inner products of vectors iteratively
area ( Points , Area ) + -
Area is the area of the polygon enclosed by the list of points Points ,
where the coordinates of each point are represented by a pair ( X , Y )
of integers .
area ( [ Tuple ] ,O ) .
area ( [ ( Xl , Yl ) , ( X2 , Y2 ) IX Ys ] , Area ) + -
area ( [ ( X2 , Y2 ) IXY s ] , Areal ) ,
Area := ( Xl * Y2 - Yl * X2 ) / 2 + Areal .
Program 8 . 8 : Computing the area of polygons
Area ) . Chain is given as a list of tupies , for example , [( 4 , 6 ) , ( 4 , 2 ) , ( 0 , 8 ) , ( 4 , 6 ) ] . The
magnitude of Area is the area of the polygon bounded by the chain . The sign of
Area is positive if the orientation of the polygon is counterclockwise , and negative
if it is clockwise . Program 8 .8 defines area .
The query area ( [ ( 4 , 6 ) , ( 4 , 2 ) , ( 0 , 8 ) , ( 4 , 6 ) ] , Area ) '? has the solution Area = - 8 .
The polygon gains opposite orientation by reversing the order of the tupies . The
solution of the query area ( [ ( 4 , 6 ) , ( 0 , 8 ) , ( 4 , 2 ) , ( 4 , 6 ) ] , Area ) ' ? is Area = 8 .
The program shown is not iterative . Converting it to be iterative is the
subject of Exercise ( v ) below .

maximum ( Xs , N ) ~
N is the maximum of the list of integers Xs .
maximum ( [X I Xs ] , M ) + - maximum ( Xs ,X , M ) .
maximum ( [X I Xs ] ,Y , M ) + - X ~ Y , maximum ( Xs ,Y , M ) .
maximum ( [X I Xs ] ,Y , M ) + - X > Y , maximum ( Xs ,X , M ) .
maximum ( [ ] , M , M ) .
Program 8 . 9 : Finding the maximum of a list of integers
length ( Xs , N ) + -
Xs is a list of length N .
length ( [X I Xs ] , N ) + - N > 0 , Nl : = N - l , length ( Xs , Nl ) .
length ( [ ] , 0 ) .
Program 8 . 10 : Checking the length of a list
length ( Xs , N ) + -
N is the length of the list Xs .
length ( [X I Xs ] , N ) + - length ( Xs , Nl ) , N : = Nl + l .
length ( [ ] , 0 ) .
Program 8 . 11 : Finding the length of a list
range ( M , NiNs ) + -
N 8 is the list of integers between M and N inclusive .
range ( M , N , [ MINs ] ) ~ M < N , Ml : = M + l , range ( Ml , NiNs ) .
range ( N , N , [N ] ) .
Program 8 . 12 : Generating a list of integers in a given range
An iterative program can be written to find the maximum of a list of integers .
The relation scheme is maximum ( Xs , Max ) , and the program is given as Program
8 . 9 . An auxiliary predicate maximum ( Xs , X , Max ) is used for the relation that
Max is the maximum of X and the elements in the list Xs . The second argument
of maximum / 3 is initialized to be the first element of the list . Note that the
maximum of an empty list is not defined by this program .
The standard recursive program for finding the maximum of a list of integers
constitutes a slightly different algorithm . The recursive formulation finds the
maximum of the tail of the list , and compares it to the head of the list , to find the
132 Arithmetic 8.3
maximum element . In contrast , Program 8.9 keeps track of the running maximum
as the list is traversed .
Program 3.17 for finding the length of a list is interesting , affording several
ways of translating a logic program into Prolog , each of which has its separate features
. One possibility is Program 8.10, which is iterative . Queries length (Xs ,N) ?
are handled correctly if N is a natural number , either testing if the length of
a list is N , generating a list of N uninstantiated elements , or failing . The program
is unsuitable , however , for finding the length of a list with a call such as
length ( [1,2, 9],N) ? This query generates an error .
Finding the length of a list can be done using Program 8.11. This program
cannot be used , however , to generate a list of N elements .. In contrast to Program
8.10, the computation does not terminate if the first argument is an incomplete
list . Different programs for length are needed for the different uses.
Similar considerations about the intended use of a program occur when trying
to define the relationship range(M ,NiNs ) , where Ns is the list of integers
between M and N inclusive . Program 8.12 has a specific use: generating a list
of numbers with the desired range . The program is totally correct over all goals
range(M ,NiNs ) where M and N are instantiated . The program cannot be used,
however , to find the upper and lower limits of a range of integers , due to the
test M < N . Removing this test would allow the program to answer a query
range(M ,N ,[1,.2,9]) if, but then it would not terminate for the intended use, solving
queries such as range(1,3,Ns) ?
(i) Write an iterative version for triangle(N, 11 posed as Exercise 8.2(i).

(ii ) Write an iterative version for power(X ,N, V) posed as Exercise 8.2(ii ).
(iii ) Rewrite Program 8.5 so that the successiveintegers are generated in descending
order.
(iv ) Write an iterative program for the relation timeslist(IntegerList,Product)

computing the product of a list of integers, analogousto Program 8.6b for
sumlist.
(v) Rewrite Program 8.8 for finding the area enclosedby a polygon so that it
is iterative .
(vi) Write a program to find the minimum of a list of integers.
(vii ) Rewrite Program 8.11 for finding the length of a list so that it is iterative .
(Hint : Use a counter as for Program 8.3.)
8.4 Background 133
(viii ) Rewrite Program 8.12 so that the range of integers is built bottom -up rather
than top -down .
8.4 Background
A program for transforming recursive programs to iterative ones, which handles

the examples in the text , is described in Bloch ( 1984) .
Program 8.8, computing the area of a polygon , was shown to us by Martin

Nilsson .
Chapter 9
Structure Inspection
All Prolog implementations have a number of system predicates related to

the structure of terms . This chapter discusses the predicates to be used in this
book .
9 .1 Type predicates
Type predicates are unary relations concerning the type of a term . The predicates
test whether a given term is a constant or a structu ,re . Further distinctions
are made between particular constants , such as integers and atoms . Four type
predicates are assumed in this book : integer / l , atom / l , constant / l and compound
/ l . These predicates are listed in Figure 9 . 1 , together with their intended

mean Ing .
Each of the type predicates in Figure 9 . 1 behaves as if it was defined via
an infinite table of facts . A table of integers : integer (0) , integer (1) , integer (
- 1) , " " ; a table of the atoms in the program : atom ( foo ) , atom ( bar ) , . . . ; and
a table of the function symbols in the program with variable arguments : compound
( father ( X , Y) ) , compound ( son ( X , Y) ) , . . . . The relation constant is defined

by a table which is the union of the tables of integers and atoms . This is expressed
in two rules :
constant (X ) + - integer (X ) .
constant (X ) +- atom (X ) .
Although most Prolog implementations handle the predicates differently , w ~ regard

the program behavior as if they were defined by a table . However , they can
be used by goals that have only a finite number of solutions . If such a predicate
9.1 Type predicates 135
integer ( X) +- X is an integer .
atom (.x) +- X is an atom .
constant ( X) +- X is a constant (integer or atom ) .
compound ( X) +- X is a compound term .
Figure 9 .1: System type predicates
is called with a goal that has an infinity of solutions , an error condition occurs .
Consider the goal integer(X) 'I. If Xis an integer the call succeeds;if it is an atom
or structure the call fails . If X is a variable , an error condition is reported . This
is analogous to evaluating arithmetic expressions which contain variables . Note
that most Prologs do not follow this convention, and in them integer(X) , where
X is a variable , simply fails .
It is tempting to use a query such as atom(X) ? to give all the atoms known in
the system on backtracking . This way of using atom is usually not implemented .
The only terms not covered by the predicates in Figure 9.1 are variables .
Prolog doesprovide system predicates relating to variables. The use of such predicates
, however, is conceptually very different from the use of structure inspection
predicates described in this chapter. Metalogical predicates (their technical
name) are the subject of the next chapter.
We give an example of the use of a type predicate as part of a program for
flattening a list of lists . The relation flatten (Xs, Ys) is true if Ys is the list of
elements occurring in the list of lists Xs . The elements of Xs can themselves be
lists or elements , so elements can be arbitrarily deeply nested . An example of a
goal in the meaning of flatten is flatten ([[a],[b,[c,dJ],e],[a,b,c,die]).
The simplest program for flattening uses double recursion . To flatten an
arbitrary list [.X1Xs
] where X can itself be a list , flatten the head of the list X ,
flatten the tail of the list Xs and concatenate the results :
flatten ([X IXs],Ys) +-

flatten (X ,Ysl ) , flatten (Xs,Ys2), append(Ysl ,Ys2,Ys) .
What are the base cases? The empty list is flattened to itself . A type predicate
is necessary for the remaining case. The result of flattening a constant is a list
containing the constant :
flatten (X ,[X ]) i - constant(X ), Xf [ ].
The condition constant(X) is necessaryto prevent the rule being used when X is
a list . The complete program for flatten is given as Program 9.la .
136 StructureInspection 9.1
ftatten ( Xs , Ys ) + -
Y s is a list of the elements of Xs .
flatten ( [X IXs ] ,Y8 ) + -

Flatten ( X , Y 81 ) , Flatten ( X8 , Y 82 ) , appendY 81 , Y 82 , Y 8 ) .
Flatten ( X , [X ] ) + -
constant (X ) , X # [ ] .
Flatten ( ( ] ,[ ]) .
Program 9 . la : Flattening a list with double recursion
jlatten ( Xs , Ys ) + -
Ys is a list of the elements of Xs .
flatten ( Xs , Y s ) + - fiatt en ( Xs , [ ] , Y s ) .
flatten ( [X IXs ] , S ,Ys ) + -

list ( X ) , flatten ( X , [XsIS ] , Ys ) .
flatten ( [X IXs ] , S , [X I Ys ] ) + -
constant ( X ) , X # [ ] , flatten ( Xs ,S ,Ys ) .

flatten ( [ ] , [XIS ] ,Ys ) + -
flatten ( X ,SY s) .
flatten ( [ ],[ ] ,[ ]) .
list ( [X IXs ] ) .
Program 9 . tb : Flattening a list using a stack
Program 9 . la , although very clear declaratively , is not the most efficient way
of flattening a list . In the worst case , which is a left - linear tree , the program
would require a number of reductions whose order is quadratic in the number of
elements in the flattened list .
A program for flatten which constructs the flattened list top - down is a little
more involved than the doubly recursive version . It uses an auxiliary predicate
flatten ( Xs , Stack , Ys ) where Ys is a flattened list containing the elements in Xs and

a stack Stack to keep track of what needs to be flattened . The stack is represented
as a list .
The call of flattenS by flatten / 2 initializes the stack to the empty list . We
discuss the cases covered by flatten / So The general case is flattening a list [- XlXs ]
where X is itself a list . In this case Xs is pushed onto the stack , and X is recursively
flattened . The predicate list ( X ) is used to recognize a list . It is defined by the

fact list ( [XlXs ]) :
flatten ( [X I Xs ] , S , Ys ) + - list { X ) , flatten (X , [ XsIS ] , Ys ) .
When the head of the list is a constant other then the empty list , it is added to
the output , and the tail of the list is flattened recursively :
flatten ( [X I Xs ] , S , [X I Ys ] ) t - constant ( X ) , Xi = [ ] , flatten ( Xs , S , Ys ) .
When the end of the list is reached , there are two possibilities , depending on the
state of the stack . If the stack is nonempty , the top element is popped , and the
flattening continues :
flatten ( [ ] , [ XIS ] , Ys ) + - flatten (X , S , Ys ) .
If the stack is empty , the computation terminates :
flatten ( [ ] , [ ] , [ ] ) .
The complete program is given as Program 9 . lb .
A general technique of using a stack is demonstrated in Program 9 . lb . The
stack is managed by unification . Items are pushed onto the stack by recursive
calls to a " consed " list . Items are popped by unifying with the head of the list
and recursive calls to the tail . Another application of stacks appears in Programs
14 . 13 and 14 . 15 simulating pushdown automata .
Note that the stack parameter is an example of an accumulator .
The reader can verify that the revised program requires a number of reductions
linear in the size of the flattened list .
( i ) Rewrite Program 9 . la for ftatten ( Xs , Ys ) to use an accumulator instead of
the call to append , keeping it doubly recursive .
9 . 2 Accessing compound terms
Recognizing a term as compound is one aspect of structure inspection . A
further aspect is provided by predicates that give access to the functor name ,
arity and arguments of a compound term . One system predicate for delving
into compound terms is functor ( Term , F , Arity ) . This predicate is true if Term
is a term whose principal functor has name F and arity Arity . For example ,
functor ( father ( haran , lot ) , father , . 2) if succeeds .

138 StructureInspection 9.2
The functor predicate can be defined , analogously to the type predicates ,

by a table of facts of the form functor (J(Xl ," .,XN ),f,N) for each functor f of
arity N. ~"or example, functor (father(X , Y) ,father,2) ) functor (son(X , Y) ,son,2), . . .
Most Prologs consider constants to be functors of arity 0, with the appropriate
extension to the functor table .
Calls to functor can fail for various reasons. A goal such as functor
(father(X , Y) ,son,2) does not unify with an appropriate fact in the table . Also,
there are type restrictions on the arguments of functor goals . For example , the
third argument of functor , the arity of the term , cannot be an atom or acom -
pound term . If these restrictions are violated , the goal fails . A distinction can
be made between calls that fail , and calls that should give an error because there
are infinitely many solutions, such as functor (X , Y,2) ?
The predicate functor is commonly used in two ways . The first use finds
the functor name and arity of a given term . For example, the goal functor
(Jather(haran,lot),X , II) ? has the solution { X =fatherY = 2} . The second use
builds a term with a particular functor name and arity . A sample query is functor
( T,father, 2) ? with solution T=father(X , II) .
The companion system predicate to functor is arg(N, Term,Arg) which ac-
cesses the arguments of a term rather than the functor name . The goal
arg(N, Term,Arg) is true if Arg is the Nth argument of Term. For example,
arg(l ,father (haran,lot),haran) is true .
Like junctor / !], arg/ !] is commonly used in two ways. One use finds a
particular argument of a compound term . A query exemplifying this use is
arg(2,Lather(haran,lot),X) ? with solution X = lot. The other use instantiates a
variable argument of a term . For example, the goal arg(l ,Lather(X,lot),haran) ?
succeeds, instantiating X to haran .
The predicate arg is also defined as if there is an infinite table of facts . A
fragment of the table is
arg(l ,father (X ,Y ),X ). arg(2,father (X ,Y ),Y ). arg(l ,son(X ,Y ),X ). . . . .
Calls to arg fail if the goal does not unify with the appropriate fact in the table , for
example, arg(1,/ather(haran, lot), abraham). They also fail if the type restrictions
are violated , for example , if the first argument is an atom . An error is reported
with a goal such as arg(l ,X , Y) .
Let us consider an example of using functor and arg to inspect terms. Program
9.2 axiomatizes a relation subterm( Tl , T2), which is true if Tl is a subterm
of T2 . For reasons that will become apparent later , we restrict Tl and T2 to be
ground .
subterm (Sub, Term ) +-

Sub is a subterm of the ground term Term.
subterm (Term ,Term ) .

subterm (Sub,Term ) +-
compound(Term), functor (Term,F ,N), subterm(N,Sub,Term) .
subterm (N ,Sub,Term) -f-
N > 1, ni := N- 1, subterm(ni ,Sub,Term) .
subterm(N ,Sub,Term) +-
arg(N,Term,Arg ) , subterm(Sub,Arg ).
Program 9.2: Finding subterms of a term
The first clause of Program 9.2 defining subterm / 2 states that any term is a
subterm of itself . The second clause states that Sub is a subterm of a compound
term Term if it is a subterm of one of the arguments . The number of arguments ,
i .e., the arity of the principal functor of the term , is found and used as a loop
counter by the auxiliary subterm / 3, which iteratively tests all the arguments .
The first clause of subterm / 9 decrements the counter and recursively calls
subterm . The second clause covers the case when Sub is a subterm of the Nth
argument of the term .
The subterm procedure can be used in two ways : to test whether the first
argument is indeed a subterm of the second; and to generate subterms of a given
term . Note that the clause order determines the order in which subterms are
generated . The order in Program 9.2 gives subterms of the first argument before
subterms of the second argument , and so on. Swapping the order of the clauses
changes the order of solutions .
Consider the query subterm ( a,J( X , Y) ) '?, where the second argument is not
ground . Eventually the subgoal subterm ( a, X) is reached . This succeeds by the
first subterm rule , instantiating X to a. The subgoal also matches the second
subterm rule , invoking the goal compound (X) which generates an error . This is
undesirable behavior .
We defer the issues arising when performing structure inspection on nonground

terms to the next chapter where metalogical predicates with suitable
expressive power are introduced . For the rest of this chapter all programs are
assumed to take only ground arguments unless otherwise stated .
Program 9.2 is typical code for programs that perform structure inspection .
We look at another example , substituting for a subterm in a term .
140 Structure Inspection 9.2
substitute( Old,New, Old Term,NewTerm) +-

New Term is the result of replacing all occurrences of Old
in Old Term by New .
substitute (Old ,New,Old ,New).

substitute (Old ,New,Term,Term) +-
constant(Term), Term i Old .
substitute (Old ,New,Term,Terml ) +-
compound(Term),
functor (Term,F ,N),
functor (Terml ,F ,N),
substitute (N ,Old,New,Term,Terml ).
substitute (N ,Old ,New,Term,Terml ) i0-
N > 0,
arg(N ,Term,Arg ),
substitute (Old ,New,Arg ,Argl ),
arg(N ,Terml ,Argl ) ,
Nl := N - l ,
substitute (Nl ,Old,New,Term,Terml ).
substitute (O,Old ,New,Term,Terml ).
Program 9 .3 : A program for substituting in a term
The relation schemefor a general program for substituting subterms is substitute

( Old,New, OldTerm,NewTerm) where NewTerm is the result of replacing all
occurrences of Old in Old Term by New. Program 9.3 implementing the relation
generalizessubstituting for elementsin a list , proposed as Exercise 3.3(i ) and the
logic program (Program 3.26) for substituting for elements in binary trees.
Program 9.3 is a little more complicated than Program " 9.2 for subterm , but
conforms to the same basic pattern . The clausesfor substitute/ .4 cover three different
cases. The last, handling compound terms, calls an auxiliary predicate
substitute/ 5 which iteratively substitutes in the subterms. The arity of the principal
functor of the term is used as the initial value of a loop counter which is
successively decremented to control the iteration . We present a particular example
to illustrate the interesting points lurking in the code. A trace of the query
substitute( cat,dog,owns(jane,cat),X) ? is given in Figure 9.2.
The query fails to unify with the fact in Program 9.3. The second rule is also
not applicable as owns(jane,cat) is not a constant.
The third substitute rule is applicable to the query . The second call of junctor
substitute (cat ,dog ,owns (jane ,cat ) ,X ) { X = owns (jane ,cat ) }

constant (owns (jane ,cat ) ) f
substitute (cat ,dog ,owns (jane ,cat ) ,X )
compound ( owns (jane ,cat )) ,
functor ( owns (jane ;cat ) ,F ,N ) {F= owns,N= 2}
functor (X ,owns,2) {X= owns(Xl ,X2) }
substitute (2,cat,dog,owns(jane,cat) ,owns(xi ,X2))
2 > 0
-
arg(2,owns(jane,cat) ,Arg ) Arg= cat}
substitute (cat,dog,cat,Arg1) Argl = dog}
arg(2,owns(Xl ,X2) ,dog) X2= dog}
ni := 2- 1 Nl = l }
substitute ( 1,cat,dog,owns(jane,cat) ,owns(xi ,dog))
1 > 0
arg(l ,owns(jane,cat) ,Arg2) { Arg2 = jane }

substitute (cat,dog,jane,Arg3) { Arg3 = jane }
constant(jane)
jane # cat .
arg(1,owns(xi ,dog)jane ) {Xl =jane}
N2 := 1- 1 {N2=O}
substitute
(O,cat,dog,owns(jane,cat),owns(jane,dog))
0 > 0 f
substitute (O,cat,dog,owns(jane,cat) ,owns(jane,dog))
true
Output : X = owns(jane,dog)
Figure 9 .2 : Tracing the substitute predicate
is interesting . Name and Arity have been instantiated to owns and .2, respectively ,
in the previous call of functor , so this call builds a term that serves as the answer
template to be filled in as the computation progress es. This explicit term
building has been achieved by implicit unification in previous Prolog programs .
The call to substitute/ 5 successivelyinstantiates the arguments of Terml . In our
example, the second argument of owns(Xl ,X .2) is instantiated to dog, and then
Xl is instantiated to jane .
The two calls to arg serve different tasks in substitute/ 5. The first call selects
an argument , while the second call of arg instantiates an argument .
Substitution in a term is typically done by destructive assignment in con-
ventionallanguages . Destructive assignment is not possible directly in Prolog .
Program 9.3 typifies how Prolog handles changing data structures . The new term
subterm (Sub,
. Term ,) +-
Sub is a subterm of the ground term Term.
subterm ( Term , Term ) .
subterm ( Sub , Term ) + -
compound ( Term ) , Term = . . [FIArgs ] , subterm -list (Sub ,Args ) .

subterm Jist ( Sub , [ Arg I Args ] ) + -
subterm ( Sub , Arg ) .
subterm Jist ( Sub , [ Arg I Args ] ) + -
subterm Jist ( Sub , Args ) .
Program 9 . 4 : Subterm defined using = ..
is recursively built as the old term is being traversed , by logically relating the
corresponding subterms of the terms .
Note that the order of the second arg goal and the recursive call to substitute
/ .5 can be swapped. The modified clausefor substitute/ 5 is logically equivalent
to the previous one, and givesthe sameresult in the context of Program 9.3. Pro-
cedurally, however
, they are radically different.
Another system predicate for structure inspection is a binary operator = ..,
called , for historical reasons, univ . The goal Term = .. List succeeds if List is a list
whose head is the functor name of the term Term , and whose tail is the list of ar-
guments of Term . For example, the goal (father( haran, lot) =.. [father
,haran
,lot])?
succeeds .
Like functor and arg, univ has two uses. Either it builds a term given a list ,
for example, (X = .. [father,haran,lot]) ? with solution X =father(haran,lot), or it
builds a list given a term , for example, (father(haran,lot) = .. Xs) ? with solution
Xs= [father ,haran,lot].
In general, programs written using functor and arg can also be written with
univ. Program 9.4 is an alternative definition of 8ubterm, equivalent to Program
9.2. As in Program 9.2, an auxiliary predicate investigates the arguments; here
it is subterm _list . Univis used to access the list of arguments, Args , of which
subterms are recursively found by subterm _list .
Programs using univ to inspect structures are usually simpler . However ,
programs written with functor and ara are in general more efficient than those
using univ , since they avoid building intermediate structures .
A np~.t 11~P ()f "1.'11
.i ." i~ f ()rml11~.tin !T
-
thp rh ~in r111pfor ~vmh
-
()lir r1iffprpT1ti~tioT1
The chain rule states that dfdx { f (g (x ) } = dfdg (x ) { f (g (x ) } x dfdx { g (x ) } . In
Term = . . List +-
List is a list containing the functor of Term followed
by the arguments of Term .
Term = .. [FIArgs] +-
functor (Term,F ,N), args(O,N ,Term,Args).
args(I ,N,Term,(Arg IArgs]) +-
I < N , 11 := 1+ 1, arg(11,Term,Arg ), args(11,N ,Term,Args).
args(N,N ,Term,( ]) .
Program 9 .5a : Constructing the list corresponding to a term
Term = . . List +-
The functor of Term is the first element of the list List ,
and its arguments are the rest of List ' s elements .
Term = .. [FIArgs] ~
length(Args,N), functor (Term,F ,N), args(Args,Term,l ).
args([Arg IArgs],Term,N) +-
arg(N,Term,Arg ), ni := N+ 1, args(Args,Term,ni ).
args([ ],Term,N).
length(Xs,N) +- SeeProgram 8.11
Program 9 .Sb : Constructing the term corresponding to a list
Section 3 .5 we noted that this rule could not be expressed as a single clause of
a logic program as part of Program 3 . 29 . A Prolog rule encapsulating the chain
rule is
derivative ( F _ G . x , X , DF * DG ) t -
F _G . x = .. [F ,G . x ] ,
derivative ( F _ G . x , G . x , DF ) ,
derivative ( G . x ,X , DG ) .
The function F- G_X is split up by univ into its function F and argument G_X ,
checkingthat is a function of one argument at the.sametime . The derivative of F
with respect to its argument is recursively calculated, as is the derivative of G_X .
These are combined to give the solution.
Univ can be defined in terms of functor and argoTwo different definitions are
necessary, however, to cover both building lists from terms, and building terms
from lists . One definition does not suffice due to errors causedby uninstantiated
variables . Other system predicates are similarly precluded from flexible use.
Program 9.5a behaves correctly for building a list from a term . The functor
F is found by the call to functor , and the arguments are recursively found by the
predicate args. The first argument of args is a counter that counts up , so that
the arguments will appear in order in the final list . If Program 9.5a is called
with Term uninstantiated , an error will be generated due to an incorrect call of
functor .
Program 9.5b behaves correctly for constructing a term from a list . The
length of the list is used to determine the number of arguments . The term template
is built by the call to functor , and a different variant of args is used to fill
in the arguments . Program 9.5b results in an error if used to build a list , due to
the goal length ( A rgs,N) being called with uninstantiated arguments .
(i ) Define a predicate occurrences(Sub, Term ,N) true if N is the number of oc-

currences of subterm Sub in Term . Assume that Term is ground .
(ii ) Define a predicate position (Subterm , Term ,Position ) where Position is a list
of argument positions identifying Subterm within Term . For example , the
position of X in 2.sin (X) is [2,lJ , since sin (X) is the second argument of the
binary operator " ." , and X is the first argument of sin (X) .
(Hint : Add an extra argument for Program 9.2 for subterm , and build the
position list top -down .)
(iii ) Rewrite Program 9.5a so that it counts down .
(Hint : Use an accumulator .)
(iv ) Define functor and arg in terms of univ . How can the programs be used?
(v ) Rewrite Program 9.3 for substitute so that it uses univ .
9.3 Background
The standard Prolog approach does not distinguish between object - and
meta -level type predicates . We have taken a different approach , by defining the
type test predicates to work only on instantiated terms , and by treating the metalogical
test predicates (e.g., var/ l to be discussed in Section 10.1) separately . The
predicates for accessing and constructing terms , functor , arg, and = .., originate
from the Edinburgh family . The origin of the = .. is in the old Prolog - 10 syntax
9.3 Background 145
for lists, which usedthe operator ",.." instead of the current "I" in lists, e.g.,
[a,b,c,..Xs] instead of [a,b,cIXs]. The ".." on the right-hand side suggestedor
remindedthat the right-hand sideof the equalityis a list.
Severalof the examplesin this sectionwereadaptedfrom O'Keefe(1983).
Exercises(i) and (ii ) will be usedin the equationsolverin Chapter22.
Chapter 10
MetaLogical Predicates
A useful extension to the expressive power of logic programs is provided

by the metalogical predicates . These predicates are outside the scope of first -
order logic , as they query the state of the proof , treat variables (rather than the
terms they denote ) as objects of the language , and allow the conversion of data
structures to goals.
Metalogical predicates allow us to overcome two difficulties involving the use

of variables encountered in previous chapters . The first difficulty is the behavior
of variables in system predicates . For example , evaluating an arithmetic expression
with variables gives an error . So does calling type predicates with variable
arguments . A consequence of this behavior is to restrict Prolog programs to have
a single use in contrast to the multiple uses of the equivalent logic programs .
The second difficulty is the accidental instantiation of variables during structure
inspection . Variables need to be considered 'as specific objects rather than
standing for an arbitrary unspecified term . In the previous chapter we handled
the difficulty by restricting inspection to ground terms only .
This chapter has four sections , each for a different class of metalogical predicates
. The first section discuss es type predicates that determine whether or not a
term is a variable . The second section discusses term comparison . The next sections
describe predicates enabling variables to be treated as manipulable objects .
Finally , a facility is described for converting data into executable goals .
10 . 1 Metalogical type predicates
The basic metalogical type predicate is var ( Term ) which tests whether a
given term is at present an uninstantiated variable . Its behavior is similar to the
plus (X , Y, Z) +-
The sum of the numbers X and Y is Z .
plus (X ,Y ,Z ) +- nonvar (X ) , nonvar (Y ) , Z := X + Y .

plus (X ,Y ,Z ) +- nonvar (X ) , nonvar ( Z ) , Y := Z - X .
plus (X ,Y ,Z ) +- nonvar (Y ) , nonvar (Z ) , X := Z - Y .
Program 10 . 1 : Multiple uses for plus
type predicates discussedin Section 9.1. The query var( Term) ? succeedsif Term
is a variable and fails if Term is not a variable. For example, var(X) ? succeeds,
whereaB both var( a) ? and var([XjXs ]) fail .
The predicate vaT is an extension to pure Prolog programs . A table cannot
be used to give all the variable names. A fact var(X) means that all instances
of X are variables , rather than meaning that the letter " X" denotes a variable .
Being able to refer to a variable name is outside the scope of first -order logic in
general or pure Prolog in particular .
The predicate nonvar( Term) has the opposite behavior to vaT. The query
nonvar( Term) succeedsif Term is not a variable and fails if Term is a variable.
The metalogical type predicates can be used to restore some flexibility to
programs using system predicates , and can also be used to control goal order . We
demonstrate this by revising some programs from earlier chapters .
Consider the relation plus(X , Y,Z) . Program 10.1 is a version of plus which can
be used for subtraction as well as addition . The idea is to check which arguments
~1
- -'P- ---
in .qt,;=I,ntiated before calling the arithmetic evaluator . For example , the second
rule says that if the first and third arguments , X and Z , are not variables , the
second argumentY , can be determined as their difference . Note that if the
arguments are not integers , the evaluation will fail , the desired behavior .
The behavior of Program 10.1 is closer to Program 3.3, the logic program
for plus . Further , it does not generate any errors . Nonetheless , it does not have
the full flexibility of the recursive logic program : it cannot be used to partition a
number into two smaller numbers , for example . To partition a number involves
generating numbers , for which a different program is needed . It is posed as an
exercise at the end of the section .
Metalogical goals placed initially in the body of a clause to decide which

clause in a procedure should be used are called metalogical tests. The plus program
above is control led by metalogical tests . These tests refer to the current
state of the computation . Knowledge of the operational semantics of Prolog is
148 MetaLogical Predicates 10.1
length(Xs,N) +-
The list Xs has length N.
length(Xs,N) +- nonvax(Xs), lengthl (Xs,N).
length(Xs,N) +- vax(Xs), nonvax(N), length2(Xs,N).
lengthl (Xs,N) +- SeeProgram 8.11
length2(Xs,K ) +- SeeProgram 8.10
Program 10.2: A multipurpose length program
grandparent (X ,Z) +-
X is the grandparent of Z .
grandparent (X ,Z ) +- nonvar ( X ) , parent ( X , Y ) , parentY ,Z ) .
grandparent (X ,Z ) +- nonvar ( Z ) , parentY , Z ) , parent ( X ,Y ) .
Program 10 .3 : A more efficient version of grandparent
required to understand them .
Many Prologs in fact endow the type predicates with a metalogicalability .
For example , in Edinburgh Prolog , the goal integer (X) fails if X is a variable ,
rather than giving an error . This enables the rules from Program 10 . 1 to be
written using the system predicate integer rather than nonvar , for example ,
plus ( X ,Y , Z ) +- integer ( X ) , integerY ) , Z := X + Y .
We feel it is preferable to separate type - checking , which is a perfectly legitimate
first - order operation , from metalogical tests , which are a much stronger tool .
Another relation that can have multiple uses restored is length ( Xs ,N) determining
the length N of a list Xs . Separate Prolog programs ( 8 . 10 and 8 . 11 ) are
needed to find the length of a given list and to generate an arbitrary list of a
given length , despite the fact that one logic program ( 3 . 17 ) performs both functions
. Program 10 . 2 uses meta - lo .gical tests to define a single length relation . The
program has an added virtue over Programs 8 . 10 and 8 . 11 . It avoids the nonterminating
behavior present in both , when both arguments are uninstantiated .
Metalogical tests can also be used to make the best choice of the goal order
of clauses in a program . Section 7 .3 discuss es the definition of grandparent :
grandparent (X ,Z ) +- parent ( X , Y ) , parentY ,Z ) .
The optimum goal order changes depending on whether you are searching for the
grandchildren of a given grandparent , or the grandparents of a given grandchild .

ground( Term) +-
Term is a ground term .
ground(Term) +-
nonvar(Term) , constant(Term).
ground(Term) +-
nonvar(Term) ,
compound(Term) ,
functor (Term,F ,N),
ground (N ,Term).
ground(N,Term) +-
N > 0,
arg(N ,Term,Arg ) ,
ground(Arg ),
Nl := N - l ,
ground(N l ,Term).
ground (0,Term) .
Program 10 .4 : Testing if a term is ground
Program 10.3 is a version of grandparent that will search more efficiently .

The basic metalogical type predicates can be used to define more involved
metalogical procedures. Consider a relation ground( Term) which is true if Term
is ground . Program IDA gives a definition .
The program is in the style of the programs for structure inspection given
in Section 9.2, in particular Program 9.3 for substitute . The two clauses for
ground/ l are straightforward . In both cases, a metalogical test is used to ensure
that no error is generated . The first clause says that constant terms are ground .
The second clause deals with s~ructures. It calls an auxiliary predicate ground/ 2
which iteratively checks that all the arguments of the structure are ground .
We look at a more elaborate example of using metalogical type predicates ;
writing a unification algorithm . The necessity of Prolog to support unification
for matching goals with clause heads, means that explicit unification is readily
available . Prolog 's underlying unification can be used to give a trivial definition
umfy (X ,X ).
which is the definition of the system predicate =/ 2, namely X = X .

Note that this definition depends on Prolog 's underlying mechanism for unification
, and hence does not enforce the occurs check.
150
MetaLogical Predicates 10.1
unify( Terml JTerm2) +-

Terml and Term2 are unified, ignoring the occurs check.
unify(X,Y) +-
var(X), var(Y), X=Y.
unify(X,Y) +-
var(X), nonvar(Y), X=Y.
unify(X,Y) +-
var(Y), nonvar(X), Y=X.
unify(X,Y) +-
nonvar(X), nonvar(Y), constant(X), constantY), X= Y.
unify(X,Y) +-
nonvar(X), nonvar(Y), compound(X), compoundY), term_unify(X,Y).
term-unify(X,Y) +-
functor(X,F ,N), functorY ,F ,N), unify_args(N,X,Y).
unify_args(N,X,Y) +-
N > 0, unify_arg(NiX,Y), Nl := N- l , unify_args(Nl ,X,Y).
unify_args(O,X,Y).
unify _ arg ( N ,X , Y ) + -
arg ( NiX , ArgX ) , arg ( N ,Y , ArgY ) , unify ( ArgX , ArgY ) .
Program 10 . 5 : Unification algorithm
A more explicit definition of Prolog ' s unification is possible using metalogical
type predicates . Although more cumbersome and less eflicient , this definition
is useful as a basis for more elaborate unification algorithms . One example is
unification with occurs check as described in the next section . Another example
is unification in other logic programming languages which can be embedded in
Prolog , such as read - only unification of Concurrent Prolog .
Program 10 . 5 is an explicit definition of unification . The relation
unify ( Terml , Term2 ) is true if Terml unifies with Term2 . The clauses of unify
outline the possible cases . The first clause of the program says that two variables
unify . The next clause is an encapsulation of the rule for unification that if X is
a variable then X unifies with Y .
The other case bearing discussion in Program 10 . 5 is unifying two compound
terms , as given in the predicate term _ unify ( X , Y ) . This predicate checks that the
two terms X and Y have the same principal functor and arity , and then checks
that all the arguments unify , using unify _ args , in a way similar to the structure
inspection programs shown before .

10.2 Comparing non ground terms 151
Write a version of range Program 8.12 that can be used to in multiple ways .
Write a version of Program 10.1 for plus that partitions a number as well as
performing addition and subtraction .
(Hint: Use between to generate numbers .)
10.2 Comparing nonground terms
Consider the problem of extending the explicit unification program , Program

10.5, to handle the occurs check . Recall that the occurs check is part of the formal
definition of unification , which requires that a variable not be unified with a term
containing this variable . In order to implement it in Prolog , we need to check
whether two variables are identical (not just unifiable , as any two variables are) .
This is a metalogical test .
Prolog provides a system predicate , = = / 2, for this purpose . The goal

(X = = Y) If succeeds if X and Yare identical constants , identical variables , or
both structures whose principal functors have the same name and arity and recursively
(Xi = = Yi ) If succeeds for all corresponding arguments Xi and Yi of X
and Y. The goal fails otherwise . For example , X = = 5 fails (in contrast to X =
5) .
There is also a system predicate that has the opposite behavior to = = . The
goal X \ = = Y ? succeeds unless X and Yare identical terms .
The predicate \ = = can be used to define a predicate not _occurs_in (Sub, Term)
which is true if Sub does not occur in Term , the relationship that is needed in
the unification algorithm with the occurs check. not _occurs_in (Sub, Term ) is a
metalogical structure inspection predicate . It is used in Program 10.6, a variant
of Program 10.5, to implement unification with the occurs check.
Note that the definition of not _occurs_in is not restricted to ground terms .
Lifting the restriction on Program 9.2 for subterm is not as easy. Consider the
query subterm (X , Y) ? This would succeed using Program 9.2, instantiating X to
Y.
We define a metalogical predicate occurs_in (Sub, Term ) that has the desired
behavior .
The predicate = = allows a definition of occurs_in based on Program 9.2 for

subterm . All the subterms of the given term are generated on backtracking and
unify( Terml , Term2) +-

Term1and Term.2are unifiedwith the occurscheck.
unify(X,Y) (--
var(X), var(Y), X=Y.
unify(X,Y) (--
var ( X ) , nonvar ( Y ) , not _occurs - in ( X , Y ) , X = Y .
unify ( X ,Y ) ~
var ( Y ) , nonvar ( X ) , not _occurs - in ( Y ,X ) , Y = X .
unify ( X ,Y ) ~
nonvar ( X ) , nonvar ( Y ) , constant ( X ) , constantY ), X = Y .

unify ( X ,Y ) ~
nonvar ( X ) , nonvar ( Y ) , compound ( X ) , compoundY ) , term _unify ( X ,Y ) .
not _occurs - in ( X , Y ) + -
var (Y ) , X \ = = Y .
not _occurs Jn ( X , Y ) + -
nonvar ( Y ) , constantY ).
not _occurs Jn ( X , Y ) + -
nonvar ( Y ) , compoundY ) , functorY , F ,N ) , not _occurs - in ( N ,x , V ) .
not _occursin ( NiX ,Y ) + -
N > O , arg ( N ,Y ,Arg ) , not _occursin ( X ,Arg ) , Nl := N - l ,
not _occurs - in ( Nl ,X , Y ) .
not _occursin ( O ,X , Y ) .
term _unify ( X ,Y ) + - See Program 10 . 5
Program 10 . 6 : Unification with the occurs check
tested to see if they are identical to the variable . The code is given in Program
10.7a.
As defined , subterm works properly only for ground terms . However , by

adding metalogical type tests , as in the definition of not _occurs_in in Program
10.6, this problem is easily rectified .
10.3 Variables as objects

The delicate problem associated with explicit manipulation of variables in
defining occurs_in in the previous section highlights a deficiency in the expressive
power of Prolog . Variables are not easily handled , and when trying to manipulate
10.3 Variables as objects 153
and inspect terms , variables can be unwittingly instantiated .

A similar problem occurs with Program 9.3 for substitute . Consider the goal
substitute ( a,b,X , Y) , substituting a for b in a variable X to give Y. There are two
plausible behaviors for substitute in this case. Logically there is a solution when
X is a and Y is b. This is the solution actually given by Program 9.3, achieved
by unification with the base fact substitute ( Old,New, Old,New) .
In practice another behavior is usually preferred . The two terms X and a
should be considered different , and Y should be instantiated to X . The other base
case from Program 9.3
substitute (Old ,New ,Term ,Term ) +- constant (Term ) , Term =f Old .
covers this behavior . However , the goal would fail because a variable is not a
constant .
We can prevent the first (logical ) solution by using a metalogical test to

ensure that the term being substituted in is ground . The unification implicit in
the head of the clause is then only performed if the test succeeds, and so must be
made explicit . The base fact becomes the rule
substitute (Old ,New ,Term ,New ) +- ground (Term ) , Old = Term .
Treating a variable as different from a constant is handled by a special rule , again

relying on a metalogical test :
substitute (Old ,New ,Var ,Var ) +- var (Var ) .
Adding the above two clauses to Program 9.3 for substitute , and adding other
metalogical tests allows it to handle nonground terms . However , the resultant
program is inelegant . It is a mixture of procedural and declarative styles , and demands
of the reader an understanding of Prolog 's control flow . To make a medical
analogy , the symptoms have been treated (undesirable instantiation of variables ) ,
but not the disease (inability to refer to variables as objects ) . Additional metalogical
primitives are necessary to cure the problem .
The difficulty of mixing object and metalevel manipulation of terms stems
from a theoretical problem . Strictly speaking metalevel programs should view
object -level variables as constants , and be able to refer to them by name .
Prolog can be extended with two system predicates , freeze( Term ,Frozen) and
melt (Frozen, Thawed) , to partially solve these problems . Freezing a term Term
makes a copy of the term , Frozen , where all the uninstantiated variables in the
term become unique constants . A frozen term looks like , and can be manipulated
as, a ground term .
occursJn (Sub,Term) +-
Sub is a subterm of the (possibly non-ground term ) Term.
a: Using = =
occurs-in (X ,Term) +-
subterm(Sub,Term), X = = Sub.
b : Using freeze
occursJn (X ,Term) +-
freeze(X ,Xf ), freeze(Term,Termf), subterm(Xf ,Termf ).
subterm(X ,Term) +- SeeProgram 9.2
Program 10 .7 : Occurs in
Frozen variables are regarded as ground atoms during unification . Two frozen
variables unify if and only if they are identical . Similarly , if a frozen term and an
uninstantiated variable are unified , they become an identical frozen term . The
behavior of frozen variables in system predicates is the behavior of the constants .
For example , arithmetic evaluation involving a frozen variable will fail .
The predicate freeze is metalogical in a similar sense to var . It enables the
state of a term during the computation to be manipulated directly .
The predicate freeze allows an alternative definition of occursin from the
previous section . The idea is to freeze the term so that variables become ground
objects . This makes Program 9.2 for subterm , which works correctly for ground
terms , applicable . The definition is given as Program 10.7b.
Freezing gives the ability to tell whether two terms are identical . Two frozen
terms , X and Y, unify if and only if their unfrozen versions are identical , that is ,
X = = Y. This property is essential to the correct behavior of Program 10.7b .
The difference between a frozen term and a ground term is that the frozen
term can be "melted back " into a nonground term . The companion predicate to
freeze is melt ( Frozen, Thawed) . The goal melt (X , Y) produces a copy Y of the term
X where frozen variables become "regular " Prolog variables . Any instantiations
to the variables in X during the time when X has been frozen are taken into
account when melting Y.
The combination of freeze and melt allows us to write a variant of substitute ,
non _ground _substitute , where variables are not accidentally instantiated . The procedural
view of non _ground _substitute is as follows . The term is frozen before
substitution ; the substitution is performed on the frozen term using the version
10.4 The metavariable facility 155
of substitute which works correctly on gr .ound terms ; and then the new term is
melted :
non _ ground - Bubstitute ( X , Y , Old , New ) +-
freeze ( Old , Oldl ) , substitute ( X , Y , Old , Oldl ) , melt ( Oldl , New ) .
The frozen term can also be used as a template for making copies . The
system predicate melt _ new ( Frozen , Term ) makes a copy Term of the term Frozen
where frozen variables are replaced by new variables .
One use of melt _ new is to copy a term . The predicate copy ( Term , Copy )
produces a new copy of a term . It can be defined in a single rule
copy ( Term , Copy ) +- freeze ( Term , Frozen ) , melt Jlew ( Frozen , Copy ) .
The primitives freeze , melt and melt _ new are useful in expressing and explaining
the behavior of the extra - logical predicates to be introduced in Chapter
12 .
10 . 4 The metavariable facility
A feature of Prolog is the equivalence of programs and data - both can be
represented as logical terms . In order for this to be exploited , programs need to be
treated as data , and data must be transformed into programs . In this section we
mention a facility which allows a term to be converted into a goal . The predicate
call (X) calls the goal X for Prolog to solve .
In practice , most Prolog implementations relax the restriction we have imposed

on logic programs , that the goals in the body of a clause must be nonvariable
terms . The metavariable facility allows a variable to appear as a goal
in a conjunctive goal or in the body of the clause . During the computation , by
the time it is called , the variable must be instantiated to a term . It will then get
treated as usual . If the variable is not instantiated when it comes to be called ,
an error is reported . The metavariable facility is a syntactic convenience for the
system predicate call .
The metavariable facility greatly facilitates metaprogramming , in particular
the construction of metainterpreters and shells . Two important examples to be
discussed in later chapters are Program 12 . 6 , a simple shell , and Program 19 . 1 ,
a meta - interpreter . It is also essential for defining negation ( Program 11 . 5 ) and
allowing the definition of higher order predicates to be described in Section 17 . 3 .

156 MetaLogical Predicates
lOA
x ,. y ~
X or Y .
X ; y + - X .
XjY + - Y .
Program 10 . 8 : Logical disjunction
We give an example of using the metavariable facility with a definition of
logical disjunction , denoted by the binary infix operator ": ' . The goal ( Xi Y) is
true if X or Y is true . The definition is given as Program 10 . 8 .
10 .5 Background
An excellent discussion of metalogical system predicates in Prolog - la , and
how they are used , can be found in O ' Keefe ( l983b ).
The unification procedure for Concurrent Prolog , written in Prolog , is in
Shapiro ( 1983 ).
The predicates free , melt and melt _new are introduced in N aka Bhima and
Ueda ( 1984 ) , where an implementation of them in Prolog - 10 is discussed .
The name freeze has been suggested for other additions to pure Prolog . Most
notable is Colmerauer ' s geler ( Colmerauer , 19S2a ) , which allows the suspension
of a goal and gives the programmer more control over goal order .
Chapter 11
Cuts and Negation
Prolog provides a single system predicate , called cut , for affecting the procedural
behavior of programs . Its main function is to reduce the search space
of Prolog computations by dynamically pruning the search tree . The cut can
be used to prevent Prolog from following fruitless computation paths that the
programmer knows could not produce solutions .
The cut can also be used, inadvertently or purpose fully , to prune computation
paths that do contain solutions . By doing so, a weak form of negation can be
effected . '.
The use of cut is controversial . Many of its uses can only be interpreted
procedurally , in a contrast to the declarative style of programming we encourage
. Used sparingly , however , it can improve the efficiency of programs without
compromising their clarity .
11 . 1 Green cuts : expressing determinism
Consider ' the program merge(Xs , Ys,Zs) (Program 11.1) which merges two
sorted lists of numbers Xs and Y s into the combined sorted list Zs.
Merging two lists of sorted numbers is a deterministic operation . Only one

of the five merge clauses applies for each nontrivial goal in a given computation .
Specifically , when comparing two numbers X and Y, only one of the three tests
x < Y, X = Y and X > Y can be true . Once a test succeeds, there is no possibility
that any other test will succeed.
The cut , denoted I, can be used to express the mutually exclusive nature of
the tests . It is placed after the arithmetic tests . For example , the first merge
clause is written
158 Cuts and Negation 11.1
merge(Xs, Ys,Zs) +-
Zs is an ordered list of integers obtained from merging
the ordered lists of integers Xs and Ys.
merge([X IXs],[YIYs],[X IZs]) +- X < Y , merge(Xs,[YIYs],Zs).
merge([X IXs],[YIYs],[X ,YIZs]) +- X = Y , merge(Xs,Ys,Zs).
merge([X IXs],[YIYs],[YIZs]) +- x > Y , merge([X IXs],Ys,Zs).
merge(Xs,[ ] ,Xs).
merge([ ],Ys,Ys).
Program 11.1: Merging ordered lists
merge([X IXs],[YIYs],[X IZs]) +- X < Y , I, merge(Xs,[YIYs],Zs).
Operationally , the cut is handled as follows . The goal succeeds and commits
Prolog to all the choices made since the parent goal was unified with the head of
the clause the cut occurs in .
Although this definition is complete and precise , its ramifications and implications
are not always intuitively clear or apparent .
Misunderstandings concerning the effects of a cut are a major source for bugs
for experienced and inexperienced Prolog programmers alike . The misunderstandings
fall into two categories : assuming that the cut prunes computation paths it
does not , and assuming that it does not prune solutions where it actually does.
The following implications may help clarify the cryptic definition above:
. First , a cut prunes all clauses below it . A goal p unified with a clause
containing a cut that succeeded would not be able to produce solutions
using clauses that occur below that clause.
. Second, a cut prunes all alternative solutions to the conjunction of goals
which appear to its left in the clause, that is , a conjunctive goal followed
by a cut will produce at most one solution .
. On the other hand , the cut does not affect the goals to its right in the
clause. They can produce more than one solution , in the event of backtracking
. However , once this conjunction fails , the search proceeds from
the last alternative prior to the choice of the clause containing the cut . Let
us consider a fragment of the search tree of the query merge([1,3,5],[2,3],
Xs) ? with respect to Program 11.2, a complete version of mergewith cuts
added . The fragment is given as Figure 11.1. The query is first reduced
to the conjunctive query 1< 2,!,merge([3,5],[2,3],Xs1) ?, the goal 1< 2 is
11.1 Green cuts: expressingdeterminism 159
merge([1,3,5] ,[2,3] ,Xs)
1< 2,!,merge(f3,51,r2,31,Xs1)
~(a) ~
1= 2,!,merge( [3,5], [3] ,Xs1)
(b)
1> 2,!,merge([1,3,5] ,[3] ,Xs1)
~
(*) !,merge([3,5],[2,3],Xsl )
~
merge([3,5],[2,3] ,Xsl )
Figure 11.1: The effectof cut
success fully solved, reaching the node marked (*) in the searchtree. The
effect of executing the cut is to prune the branches marked (a) and (b).
We return to discussing Program 11.2. The placement of the cuts in the
three recursive clauses of merge is after the test . ! The two base cases of merge
are also deterministic . The correct clause is chosen by unification , and thus a
cut is placed as the first goal (and in fact the only goal) in the body of the rule .
Note that the cuts eliminates the redundant solution to the goal merge([ ],[ ],Xs) .
Previously, this was accomplishedmore awkwardly, by specifying that Xs (or Ys)
had at least one element .
We restate the effect of a cut in a general clause C= A +- B1,. . .,Bk , !,Bk + 2' . ' "
Bn in a procedure defining A . If the current goal G unifies with the head of C,
and Bl ,. . .,Bk further succeed, the cut has the following effect . The program is
committed to the choice of C for reducing G; any alternative clauses for A that
might unify with G are ignored . Further should Bi fail for i > k, backtracking goes
back only as far as the I. Other choices remaining in the computation of Bi , i ~ k,
are pruned from the search tree . H backtracking actually reaches the cut , then
the cut fails , and the search proceeds from the last choice made befor ~ G chose
C.
The cuts used in the merge program express that merge is deterministic .
That is , for every applicable goal , only one of the clauses can be used successfully
for proving it . The cut commits the computation to such a clause, once the
computation has progressed enough to determine that this is the only clause to
1 The cut after the third merge clause is unnecessary in any practical sense . Procedurally , it
will not cause any reduction of search . But it makes the program more symmetric , and like
the old joke says about chicken soup , it doesn ' t hurt .
merge(Xs, Ys,Zs) +-
Zs is an ordered list of integers obtained from merging
the ordered lists of integers Xs and Ys.
merge([X IXs],[YIYs],[X IZs]) t -
X<Y, !, merge (Xs,[YIYs],Zs).
merge([XIXs],[YIYs],[X,YIZs]) t -
X=Y, f, merge (Xs,Ys,Zs).
merge([X IXs],[YIYs],[YIZs]) t -
x >Y, I, merge ([X IXs],Ys,Zs).
merge (Xs ,[ ] ,Xs ) +- !.
merge ( [ ],Ys ,Ys ) +- !.
Program 11 .2 : Merging with cuts
minimum (X
. ,- Y,Min ). +-
Min is the minimum of the numbers X and Y.
minimum
(X,Y,X) t- X~Y, t.
minimum
(X,Y,Y) t- X>Y, !.
Program 11.3: Minimum with cuts
be used.
The information conveyed by the cut prunes the search tree , and hence shortens
the path traversed by Prolog , which reduces the computation time . In practice
, using cuts in a program is even more important for saving space. Intuitively ,
knowing that a computation is deterministic means that less information needs
to be kept for use in the event of backtracking . This can be exploited by Prolog
implementations with tail recursion optimization , discussed below .
Let us consider some other examples . Cuts can be added to the program for
computing the minimum of two numbers (Program 3.7) in precisely the same way
as to merge. Once an arithmetic test succeeds there is no possibility for the other
test succeeding . Program 11.3 is the appropriately modified version of minimum .
A more substantial example where cuts can be added to indicate that a
program is deterministic is provided by Program 3.28. The program defines the
relation polynomial ( Term ,X) for recognizing if Term is a polynomial in X . A
typical rule is
polynomial (Term1+ Term2,X )+-

polynomial (Terml ,X ), polynomial (Term2,X ).
11.1 Green cuts : expressing determinism 161
polynomial( Term,X) +-
Term is a polynomial in X .
polynomial (X ,X ) ~ !.
polynomial (Term,X ) ~
constant(Term), !.
polynomial (Term 1+ Term2,X ) ~
I, polynomial (Terml ,X ), polynomial (Term2,X ).
polynomial (Terml - Term2,X ) ~
I, polynomial (Terml ,X ), polynomial (Term2,X ).
polynomial (Terml *Term2,X ) ~
!, polynomial (Terml ,X ), polynomial (Term2,X ).
polynomial (Termlj Term2,X ) ~
I, polynomial (Terml ,X ), constant(Term2).
polynomial (TermiN ,X ) ~
!, natural -ilumber (N), polynomial (Term,X ).
Program 11.4: Recognizing polynomials
Once the term being tested has been recognized as a sum (by unifying with
the head of the rule ) , it is known that none of the other polynomial rules will
be applicable . Program 11.4 gives the complete polynomial program with cuts
added . The result is a deterministic program , which has a mixture of cuts after
conditions and cuts after unification .
When discussing the Prolog programs for arithmetic , which use the underlying
arithmetic capabilities of the computer rather than a recursive logic program ,
we argued that the increased efficiency is often at the price of flexibility . The
logic programs lost their multiple uses when expressed as Prolog programs . Prolog
programs with cuts also have less flexibility than their "cut -free" equivalents .
This is not a problem if the intended use of a program is one- way to begin with ,
as is often the case.
The examples so far have demonstrated pruning useless alternatives for the
parent goal . We give an example where cuts greatly aid efficiency by removing
redundant computations of sibling goals. Consider the recursive clause of an
interchange sort program ,
sort(Xs,Ys) +-
append(As,[X ,YIBs],Xs),
X>Y.
append(As,[Y,X IBs],Xsl ),
sort(Xsl ,Ys).
sort (Xs , Ys) +-

Y 8 is an ordered permutation of the list of integers Xs .
sort(Xs,Ys) +-
append(As,[X,YIBs],Xs),
X>Y,
,.,
append(As,[Y,X IBs],Xsl ),
sort(Xsl ,Ys).
sort(Xs,Xs) +-
ordered(Xs) ,
!.
ordered(Xs) +- SeeProgram3.20
Program 11.5: Interchangesort
The program search es for a pair of adjacent elements which are out of order ,
swaps them , and continues until the list is ordered . The base clause is
sort (Xs ,Xs ) +- ordered (Xs ) .
Consider a goal sort ([3,2,1],Xs ) ? This is sorted by swapping 3 and 2, then 3

and 1, and finally 2 and 1 to produce the ordered list [1,2, 3]. It could also be sorted
by first swapping 2 and 1, then swapping 3 and 1, and finally swapping 3 and 2, to
arrive at the same solution . We know there is only one sorted list . Consequently
there is no point in searching for another alternative once an interchange is made .
This can be indicated by placing the cut after the test X > Y. This is the earliest
it is known that an interchange is necessary. The interchange sort program with
cut is given as Program 11.5.
The addition of cuts to the programs described in this section does not alter
their declarative meaning ; all solutions to a given query are found . Conversely ,
removing the cuts would similarly not affect the meaning of the program . Unfortunately
this is not always the case. A distinction has been made in the literature
between green cuts and red cuts. Green cuts have been considered in this section .
The addition and removal of green cuts from a program do not affect the pro -
gram 's meaning . Green cuts prune only computation paths that do not lead to
new solutions . Cuts that are not green are red.
(i ) Add cuts to the partition program from quicksort , Program 3.22.

11.2 Tail recursion optimization 163
( ii ) Add cuts to the differentiation program , Program 3 . 29 .
( iii ) Add cuts to the insertion sort program , Program 3 . 21 .
11 . 2 Tail recursion optimization
As noted before , the main difference from a performance point of view between
recursion and iteration is that recursion requires , in general , space linear
in the number of recursive calls to execute , whereas iteration can be executed in
constant space , independently of the number of iterations performed .
Although recursive programs , defined free of side - effects , might be considered
more elegant and pleasing then their iterative counterparts , defined in terms of
iteration and local variables , an order of magnitude in space complexity seems an
unacceptable price for such pleasures as aesthetics . Fortunately , there is a class of
recursive programs , precisely those that can be translated directly into iterative
ones , which can be executed in constant space .
The implementation technique which achieves this space saving is called tail
recursion optimization , or , more precisely , last call optimization . Intuitively , the
idea of tail recursion optimization is to execute a recursive program as if it were
an iterative one .
Consider the reduction of a goal A using the clause
A ' + - Bl , B2 ' . . . , Bn .
with most general unifier (J 0 The optimization is potentially applicable to the last
call in the body of a clause , Bno It re - uses the area allocated for the parent goal
A for the new goal Bn 0
The key precondition for this optimization to apply is that there are no choice
points left from the time the parent goal A reduced to this clause , to the time
the last goal Bn is reduced . In other words , that A has no alternative clauses for
reduction left , and that no choice points left in the computation of goals to the
left of Bn , namely the computation of the conjunctive goal ( Bl , B2 ' " . , Bn - l ) {) '
was deterministic .
Most implementations of tail recursion optimization can recognize to alim -
ited extent at runtime whether this condition occurs , by comparing backtracking -
related information associated with the goals Bn and A . Another implementation
technique , clause indexing , also interacts closely with tail recursion optimization ,
and enhances the ability of the implementation to detect that this precondition
occurs . Indexing performs some analysis of the goal , to detect which clauses
are applicable for reduction , before actually attempting to do the unifications .

Typically indexing is done on the type and value of the first argument of the goal .
Consider the append program :
append([X IXs],Ys,[X IZs]) +- append(Xs,Ys,Zs).

append([ ],Ys,Ys).
If it is used to append two complete lists , then by the time the recursive
append goal is executed , the preconditions for tail recursion optimization hold .
No other clauseis applicable to the parent goal (if the first argument unifies with
[XlXs ], it certainly won't unify with [ ], since we assumedthat the first argument
is a complete list ). There are no other goals in the body besides append, so that
the second precondition holds vacuously .
However , for the implementation to know that the optimization applies , it
needs to know that the second clause , although not tried yet , is not applicable .
Here index.ing comes into play . By analyzing the first argument of append, it is
possible to know that the second clause woUld fail even before trying it , and to
apply the optimization in the recursive call to append.
Not all implementations provide indexing , and not all cases of determinism
can be detected by the indexing mechanisms available . Therefore it is in the interest
of the programmer to help an implementation , which supports tail recursion
optimization , to recognize that the preconditions for applying it hold .
There is a sledgehammer technique for doing so: add a cut before the last
goal of a clause, in which tail recursion optimization should always apply , as in
Al +- BI ,B2 ,. . .,!,Bn .
This cut prunes both alternative clauses left for the parent goal A , and any alter -
natives
leftforthecomputation
of (Bl,B2'" .,Bn- l )()'
In general , it is not possible to answer if such a cut is green or red , and the
programmer 's judgment should be applied .
It should be noted that the effect of tail recursion optimization is enhanced
greatly when accompanied with a good garbage collector . Stated negatively , the
optimization is not very significant without garbage collection . The reason is
that most tail recursive programs generate some data structures on each iteration .
Most of these structures are temporary , and can be reclaimed (see, e.g., the editor
in Program 12.5) . Together with a garbage collector , such programs can run ,
in principle , forever . Without it , although the stack space they consume would
remain constant , the space allocated to the uncollected temporary data structures
would overflow .
11.3 Negation 165
not X +-
X is not provable .
not X +- X , ! , fail .
not X .
Program 11 .6 : Negation as failure
11.3 Negation
The use of green cuts does not change the declarative meaning of Prolog
programs . However , by considering the procedural behavior of cut , it can be used
to express negative information to a limited extent .
The cut is the basis of implementing a limited form of negation in Prolog
called negation as failure . Program 11.6 is the standard definition of not ( GoaQ,
which is true if Goal fails . It uses the metavariable facility , and a system predicate
fail that fails (i .e., there are no clauses defined for it ) . A conjunction of cut and
fail is referred to as a cut -fail combination . We assume that not has been defined
as a prefix operator .
Let us consider the behavior of Program 11.6 in answering the query not
G ? The first rule applies and G is called using the metavariable facility . If G
succeeds, the cut is encountered . The computation is then committed to the first
rule , and not G fails . If the call to G fails , then the second rule of Program 11.6
is used, which succeeds. Thus not G fails if G succeeds and succeeds if G fails .
The rule order is essential for Program 11.6 to behave as intended . This introduces
anew , not entirely desirable , dimension to Prolog programs . Previously ,
changing the rule order only changed the order of solutions . Now the meaning
of the program can change . Procedures where the rule order is critical in this
sense must be considered as a single unit , rather than as a collection of individual
clauses.
The termination of a query not G depends on the termination of G. If G

terminates then so does not G. If G does not terminate , then not G mayor may
not terminate depending on whether a success node is found in the search tree
before an infinite branch . Consider the nonterminating program :
married ( abraham ,sarah ) .

married (X ,Y ) +- married (Y ,X ) .
The query not married ( abraham,sarah) ? terminates (with failure ) eyen though
married ( abraham,sarah) ? does not terminate .
The meaning of not defined by Program 11 . 6 differs from strict logical
negation . 2 Nor is the program a correct or complete implementation of negation
by failure as described by the theory of Chapter 5 .
The incompleteness of Program 11 . 6 as an implementation of negation by
failure arises from Prolog ' s incompleteness in realizing the computation model of
logic programs . The definition of negation as failure for logic programs is in terms
of a finitely failed search tree . A Prolog computation is not guaranteed to find
one , even if it exists . There are goals that could fail by negation as failure , that
do not terminate under Prolog ' s computation rule . For example , the query not
( p ( X ) , q ( X ) ) ? does not terminate with respect to the program
p ( s ( X ) ) + - p ( X ) .
q ( a ) .
The query would succeed if the q ( X ) goal were selected first , since that gives a
finitely failed search tree .
The inadequacy of Program 11 . 6 also stems from the order of traversal of the
search tree , and arises when not is used in conjunction with other goals . Consider
using not to define a relationship unmarried _ student ( X ) for someone who is both
not married and a student , as done in Program 5 . 1 :
unmarried - atudent ( X ) + - not married ( X ) , student ( X ) .
student ( bill ) .
married ( joe ) .
The query unmarried _ student ( X ) ? fails with respect to the data above , ignoring
that X = bill is a solution logically implied by the rule and two facts . The failure
occurs in the goal not married ( X ) since there is a solution X = joe . The problem
can be avoided here by swapping the order of the goals in the body of the rule .
A similar example to the one above is the query not ( X = l ) , X = 2 ? which
fails although it is true .
The implementation of negation as failure using the cut - fail combination does
not work correctly for nonground goals , as the examples above demonstrate . In
most standard implementations of Prolog , it is the responsibility of the programmer
to ensure that negated goals are ground before they are solved . This can be
done either by a static analysis of the program , or by a runtime check , using the
predicate ground defined in Program 10 . 4 .
The predicate not is very useful . It allows us to define interesting concepts .
2 Prolog - tO in fact calls the predicate \ + instead of not , so as not to mislead .

11.3 Negation 167
X :i=Y +-
X and Y are not unifiable.
x :/: x +- !, fail.
X :/: Y.
Program 11.7: Implementing =1=
For example , consider a predicate disjoint (Xs , Ys) true if two lists Xs and Ys have
no elements in common . It can be defined as
disjoint (Xs ,Ys ) +- not (member (Z ,Xs ) , member (Z ,Ys ) ) .
Many other examples of using not will appear in the programs throughout the
book .
The cut -fail combination used in Program 11 .6 is a technique that can be

used more generally . It allows early failure . A clause with a cut -fail combination
says that the search need not (and will not ) proceed .
Some cuts in a cut -fail combination are green cuts . That is , the program has
the same mea Jling if the clause containing the cut -fail combination is removed . For
example , consider Program 10 .4 defining the predicate ground . An extra clause
CaJl be added , which CaJl reduce the search , without affecting the meaning .
ground (Term ) +- var (Term ) , !, fail .
The use of cut in Program 11 .6 implementing not is not green , but red . The
program does not behave as intended if the cut is removed .
The cut -fail combination is used to implement other system predicates involving
negation . For example , the predicate =1= can be simply implemented via
unification and cut -fail , rather than via an infinite table , with Program 11 .7 . This
program also works correctly only for ground goals .
With ingenuity , and a good understanding of unification and the execution

mechanism of Prolog , interesting definitions can be found for many metalogical
predicates . A sense of the necessary contortions can be found in the program for
.same _var (X , Y) which succeeds if X and Yare the same variable , and otherwise
fails :
same _var (foo ,Y ) +- var (Y ) , I, fail .

same _var (X ,Y ) +- var (X ) , var (Y ) .
The argument for its correctness follows : " If the arguments to same _vaT are the
same variable , binding X to foo will bind the second argument as well , so the first
clause will fail , and the second clause will succeed . If either of the arguments is
not a variable , both clauses will fail . If the arguments are different variables , the
first clause will fail , but the cut stops the second clause from being considered "
(0 'Keefe 83).
(i) Define the system predicate \ = = using = = and cut-fail .

(ii ) Define nonvaTusing vaTand cut-fail .
11 .4 Red cuts : omitting explicit conditions
Prolog 's sequential choice of rules and its behavior in executing cut are the
key features necessary to compose the program for not . The programmer can
take into account that Prolog will only execute a part of the procedure if certain
conditions hold . This suggests anew , and misguided , style of programming in
Prolog , where the explicit conditions governing the use of a rule are omitted .
The prototypical (bad) example in the literature is a modified version of
Program 11.3 for minimum . The comparison in the second clause of the program
can be discarded to give the program
minimum (X ,Y ,X ) +- X :$:Y , !.
minimum (X ,Y ,Y ).
The reasoning offered to justify the program is as follows : "If X is less than or
equal to Y, then the minimum is X . Otherwise the minimum is Y, and another
comparison between X and Y is unnecessary ." Such a comparison is performed ,
however , by Program 11.3.
There is a severe flaw with this reasoning . The modified program has a
different meaning from the standard program for minimum . It succeeds on the
goal minimum (2,5,5) . The modified program is a false logic program.
The incorrect minimum goal implied by the modified program can be avoided .
It is necessary to make explicit the unification between the first and third arguments
, which is implicit in the first rule . The modified rule is
minimum (X ,Y ,Z) +- X :$:Y , !, Z= X .
This technique of using the cut to commit to a clause after part of the unification
has been done is quite general . But for minimum the resultant code is contrived .
11.4 Red cuts : omitting explicit conditions 169
It is far better to simply write the correct logic program , adding cuts if efficiency
is important , as done in Program 11.3.
Using cut with the operational behavior of Prolog in mind is problematic . It

allows the writing of Prolog programs that are false when read as logic programs ,
that is , have false conclusions , but behave correctly because Prolog is unable
to prove the false conclusions . For example , if minimum goals are of the form
minimum (X, Y,Z) where X and Y are instantiated , but Z is not , the modified
program behaves correctly .
The only effect of the green cuts presented in Section 11.1 is to prune branch es
from the search tree , which are known to be useless . Cuts , whose presence in a
program changes the meaning of that program , are called red cuts. The removal
of a red cut from a program changes its meaning , i .e., the set of goals it can prove .
A standard Prolog programming technique using red cuts is the omission of
explicit conditions . Knowledge of the behavior of Prolog , the order it uses rules in
a program , is relied on to omit conditions that could be inferred to be true . This
is sometimes essential in practical Prolog programming , since explicit conditions ,
especially negative ones, are cumbersome to specify , and inefficient to run . But
making such omissions is error -prone .
Omitting an explicit condition is possible if the failure of the previous clauses

implies the condition . For example , the failure of the comparison , X ~ Y in the
minimum code implies that X is greater than Y. Thus the test X > Y can be
omitted . In general the explicit condition is effectively the negation of the previous
conditions . By using red cuts to omit conditions , negation is being expressed
implicitly .
Consider Program 11.5 for interchange sort. The first (recursive) rule applies
whenever there is an adjacent pair of elements in the list that are out of order .
When the second sort rule is used, there are no such pairs and the list must be
sorted. Thus the condition ordered(Xs) can be omitted , leaving the second rule
as the fact sort(Xs,Xs) . As with minimum , this is an incorrect logical statement.
Once the ordered condition is removed from the program , the cut changes
color from green to red . Removing the cut from the variant without the ordered
condition leaves a program which gives false solutions .
Let us consider another example of omitting an explicit condition . Consider
Program 3.18 for deleting elements in a list . The two recursive clauses cover
distinct cases, corresponding to whether or not the head of the list is the element
to be deleted . The distinct nature of the cases can be indicated with cuts as given
in Program 11.8a.
By reasoning that the failure of the first clause implies that the head of the
170 Cuts and Negation
11.4
delete(Xs,X , Ys)
Y s is the result of deleting all occurrences of X from the list Xs .
delete (:[X IYs],X ,Zs) . - !, delete(Ys,X ,Zs).

delete ~:[YIYs],X ,[YIZs]) . - Y i = X , !, delete(Ys,X ,Zs).
delete ~:[ ],X ,[ ]).
Program 11 .8a : Deleting elements from a list
delete(Xs,X , Ys) . -
Y s is the result of deleting all occurrences of X from the list Xs .
delete ( [X I Ys],X ,Zs) . - !, delete(Ys,X ,Zs).

delete ( [YIYs],X ,[YIZs]) . - !,delete(Ys,X ,Zs).
delete ( [ ],X ,[ ]).
Program 11 . 8b : Deleting elements from a list
if-then_else(P, Q,R) . -
Either P and Q, or not P and R .
if _then_else(P,Q,R) . - P, !, Q.
if _then_else(P,Q,R) . - R.
Program 11 .9 : If then else statement
list is not the same as the element to be deleted , the explicit inequality test can
be omitted from the second clause. The modified program is given as Program
11.8b . The cuts in Program 11.8a are green in comparison to the red cut in the
first clause of Program 11.8b .
In general omitting simple tests as in Program 11.8b is inadvisable . The

efficiency gain by their omission is minimal compared to the loss of readability
and modifiability of the code.
Let us investigate the use of cut to express the if -then - else control structure .
Program 11.9 defines the relati ~n if-then_else(P,Q,R) . Declaratively, the relation
is tru ,e if P and Q are true , or not P and R are true . Operationally , we prove P
and , if successful, prove Q, else prove R .
The utility of a red cut to implement this solution is self-evident . The alternative
to using a cut is to make explicit the condition under which R is run . The
second clause would read :
11.5 Default rules 171
if _ then _ else ( P , Q , R ) + - not P , R .
This could be expensive computationally . The goal P will have to be computed a
second time in the determination of not .
We have seen so far two kinds of red cuts . One kind is " built - into " the
program , as in the definitions of not and ~ . A second kind was a green cut that
became red when conditions in the programs were removed . However , there is a
third kind of red cut . A cut that is introduced into a program as a green cut that
just improves efficiency , can turn out to be a red cut that changes the program ' s
.
mean Ing .
For example , consider trying to write an efficient version of member that does
not succeed several times when there are multiple copies of an element in a list .
Taking a procedural view , one might use a cut to avoid backtracking once an
element is found to be a member of a list . The corresponding code is
member ( X , [X I Xs ] ) + - ! .
member ( X , [ YIYs ] ) + - member ( X , Ys ) .
Adding the cut indeed changes the behavior of the program . However it is now not
an efficient variant of member , since , for example , on the goal member ( X , [ 1 , 2 , 3 ] ) ?
it gives only one solution , X = l . It is a variant of member - check , given as Program
7 . 3 , with the explicit condition X : f = Yomitted , and hence the cut is red .-
( i ) Discuss where cuts could be placed in Program 9 . 3 for substitute . Consider
whether a cut - fail rule would be useful , and whether explicit conditions can
be omitted . /
( ii ) Analyze the relation between Program 3 . 19 for select and the program obtained
by adding a single cut :
select ( X , (X I Xs ] , Xs ) + - ! .
select ( X , ( YIYs ] , ( YIZs ] ) + - select ( X , Ys , Zs ) .
( Hint : Consider variants of select . )
11 . 5 Default rules
Logic programs with red cuts are essentially comprised of a series of special
cases , and a default rule . For example , Program 11 . 6 for not had a special case
pension ( Person , Pension )

Pension is the type of pension received by Person .
pension ( X ,invalid - pension ) +- invalid (X ) .
pension ( X , old _age _pension ) +- over _65 ( X ) , paid - up ( X ) .

pension ( X ,supplementary _benefit ) +- over _65 ( X ) .
invalid ( mc _tavish ).
over _65 ( mc _tavish ). over _65 ( mc _donald ). over _65 ( mc _dufI ).
paid _up ( mc _tavish ). paid _up ( mc _donald ).
Program ll . I Oa : Determining welfare payments
pension ( Person , Pension ) +-

Pension is the type ' of pension received by Person .
pension ( X ,invalid _pension ) +- invalid (X ) , t .

pension ( X , old - age _pension ) +- over - 65 ( X ) , paid _up ( X ) , t .
pension ( X ,supplem - benefit ) +- over _65 ( X ) , t .

pension ( X ,nothing ).
Program ll . lOb : Determining welfare payments
when the goal G succeeded , and a default fact not Gused otherwise .
The second
rule for if - then _ else in Program 11 .9 is
if - then _ else ( P , Q , R ) + - R .
It is usedby default if P fails.

Using cuts to achieve default behavior is in the logic programming folklore .
We argue , using a simple example , that often it is better to compose an alternative
logical formulation than use cuts for default behavior .
Program lI . 10a is a naive program for determining social welfare payments .

The relationship pension ( Person , Pension ) determines which pension , Pension , a
person , Person , is entitled to . The first pension rule says that a person is entitled
to an invalid pension if he is an invalid . The second rule states that people over
the age of 65 are entitled to an old age pension if they have contributed to a
suitable pension scheme for long enough , in short they must be paid _up . People
who are not paid up are still entitled to supplementary benefit if they are over 65 .
Consider extending Program lI . 10a to include the rule that people receive
nothing if they do not qualify for one of the pensions . The procedural " solution "
11.6 Background 173
is to add cuts after each of the three rules , and an extra default fact
pension (X , nothing ).
This version is given as Program 11.10b.
Program 11 . 10b behaves correctly on queries to determine the pension to
which people are entitled , for example , pension ( mc _ tavish , X ) ? The program is
not correct , though . The query pension ( mc _ tavish , nothing ) ? succeeds which
mc _ tavish wouldn 't be too happy about , and pension ( X , old _ age _ pension ) ? has
the erroneous unique answer X = mc _ tavish . The cuts prevent alternatives being
found . Program 11 . 10b only works correctly to determine the pension a given
person is entitled to .
A better solution is to introduce a new relationship entitlement ( X , Y ) which
is true if X is entitled to Y . It is defined with two rules and uses Program II . I Oa
for pension :
entitlement (X ,Y ) + - pension (X ,Y ) .
entitlement (X , nothing ) + - not pension (X ,Y ) .
This program has all the advantages of Program 11 . 10b , and neither of the
disadvantages mentioned above . It shows that making a person entitled to nothing
as the default rule is really a new concept and should be presented as such .
11 . 6 Background
The cut was introduced already in Marseille Prolog ( Colmerauer et al . , 1973 ) ,
and was perhaps one of the most influential design decisions in Prolog . Colmerauer
experimented with several other constructs , which corresponded to special cases
of the cut , before coming up with its full definition .
The terminology of green cuts and red cuts was introduced by van Emden
( 1982 ) , in order to try and separate between legitimate and illegitimate uses of
cuts . Alternative control structures , which are more structured then the cut , are
constantly being proposed , but the cut still remains the workhorse of the Prolog
programmer . Some of the extensions are if - then - else constructs ( O ' Keefe , 1985 ) ,
and notations for declaring that a relation is functional , or deterministic , as well
as , " weak - cuts ," " snips ," remote - cuts ( Chikayama , 1984 ) , and not itself , which ,
as presently implemented , can be viewed as a structured application of the cut .
The cut is also the ancestor of the commit operator of concurrent logic languages
, which was first introduced by Clark and Gregory ( 1981 ) in their Relational
Language . The commit cleans up one of the major drawbacks of the cut , which
is destroying the modularity of clauses. The cut is asymmetric , as it eliminates
alternative clauses below the clause in which it appears , but not above . Hence a
cut in one clause affects the meaning of other clauses . The commit , on the other
hand , is symmetric , and therefore cannot implement negation -as-failure , and does
not destroy the modularity of clauses.
Attempts have been made to give cut a semanticswithin Prolog. One treatment
can be found in Lloyd (1984).
Tail recursion optimization was first described by Warren (1981) and implemented
in Prolog-10. It was implemented concurrently by Bruynooghe (1982) in
his Prolog system .
References to negation in logic programming can be found in the background

section in Chapter 5. Implementations of a sound negation as failure rule in
dialects of Prolog can be found in Prolog-II (van Caneghem, 1982), and MU -
Prolog (Naish, 1985a).
The program for same _vaT and its argument for correctness are due to
O'Keefe (1983).
Program 11.I Oa for pension is a variant of an example due to Sam Steel
for a Prolog course at the University of Edinburgh - hence the Scottish flavor .
Needless to say, this is not intended as, nor is it , an accurate expression of the
Scottish , or British , social welfare system .
Chapter 12
Extra -Logical Predicates
There is a class of predicates in Prolog that lie outside the logic programming
model , and are called extra-logical predicates . These predicates achieve a side effect
in the course of being satisfied as a logical goal . There are basically three
types of extra -logical system predicates : predicates concerned with I / O, predicates
for accessing and manipulating the program , and predicates for interfacing
with the underlying operating system . Prolog I / O and program manipulation
predicates are discussed in this chapter . The interface to the operating system
is too system dependent to be discussed in the text . Appendix B lists system
predicates for Wisdom Prolog running under Unix .
12.1 Input / Output
A very important class of predicates that produces side effects is that concerned
with I / O . Any practical programming language must have a mechanism
for both input and output . The execution model of Prolog , however , precludes
the expression of I / O within the pure component of the language .
The basic predicate for input is read(. X) . This goal reads a term from the
current input stream , usually from the terminal . The term that has been read is
unified with X , and read succeeds or fails depending on the result of unification .
The basic predicate for output is write (. X) . This goal writes the term X on
the current output stream , as defined by the underlying operating system , usually
to the terminal . Neither read nor write give alternative solutions on backtracking .
The normal use of read is with a variable argument X , which acquires the
value of the first term in the current input stream . The instantiation of X to
176 Extra -Logical Predicates 12.1
writeln ((X IXs]) +- write (X ), writeln (Xs).

writeln (( ]) +- ill .
Program 12 .1: Writing a list of terms
something outside the program lies outside the logical model , since each time the
procedure is called , read ( X ) succeeds with a ( possibly ) different value for X .
Read attempts to parse the next term on the input stream . If it fails , it prints
an error message on the terminal , and attempts to read the next term .
There is an asymmetry between the extra - logical nature of read and write . If
all calls to write were replaced with a goal true which always succeeds once , the
semantics of the program is unaffected . That is not true for read .
Different Prolog systems have different extra utilities that are system dependent
A useful utility is a predicate writeln ( Xs ) , analogous to the Pascal command .
The goal writeln ( Xs ) writes the list of terms Xs as a line of output . It is defined
in Program 12 . 1 . It uses the system predicate nl , which causes the next output
to be on a new line .
Character strings are inserted by quoting them . For example , the goal
writeln ( ( ' The value of X is ', ~ ) would produce the output
The value of X is 9
if X were instantiated to 3 .
More generally , Prolog supports string manipulation by handling strings as
lists of character codes . Assuming ASCII codes , the list [ 80 , 114 , 111 , 108 , 111 , 103 ]
represents " Prolog . " The ASCII code for P is 80 , for r 114 , etc . Doubly quoted
strings are an alternative notation for lists of ASCII values , for example , " Prolog . "
Such strings are just syntactic sugar for the list . Manipulating strings can be done
via standard list processing techniques .
The system predicate name ( X , Y ) is used to convert names of constants to
character strings , and vice versa . The goal name ( X , Y ) succeeds if X is an atom ,
and Y is the list of ASCII codes corresponding to the characters in X , for example ,
name ( log , [ 108 , 111 , 109 ] ) ? succeeds .
A lower level of I / O than the term level , characterized by read and write , is
the character level . The basic output predicate at the character level is put ( N ) ,
which places the character corresponding to ASCII code N on the current output
12.1 Input / Output 177
read _ word Jist ( Ws ) + -
get ( C ) ,
read _ word Jist ( C , Ws ) .
read _ word Jist ( C , [ WIWs ] ) + -
word _ char ( C ) ,
read _ word ( C , W , C1 ) ,
read _ word Jist ( Cl , Ws ) .
read _ word Jist ( C , Ws ) + -
fill _ char ( C ) ,
get ( C1 ) ,
read _ word Jist ( Cl , Ws ) .
read _ word Jist ( C , ( ] ) + -
end _ of _ words _ char ( C ) .
read _ word ( C , W , C1 ) + -
word _ chars ( C , Cs , Cl ) ,
name ( W , Cs ) .
word _ chars ( C , ( CICs ] , CO ) + -
word _ char ( C ) ,
,
. ,
get ( C1 ) ,
word _ chars ( C 1 , as , CO ) .
word _ chars ( C , ( ] , C ) + -
not word _ char ( C ) .
word _ char ( C ) + - 97 : : : ; C , C : : : ; 122 .

% Lower - case letter
word _ char ( C ) + - 65 : : : ; C , C : : : ; 90 .
% Upper -case letter
word _ char ( 95 ) .
% Underscore
fill _ char ( 32 ) .
% Blank
end _ of _ words _ char ( 46 ) .

% Period
Program 12 . 2 : Reading in a list of words
stream . The basic input predicate is get(X) 1 which returns in X the ASCII code
of the first character on the input stream .
Program 12.2 is a utility predicate read_word_list ( Words) that reads in a list
of words , Words. It is built using get. The words can be separated by arbitrarily
many blanks (ASCII code 32) , and may contain any mixture of uppercase and
- --
1 This is slightly different from Edinburgh Prolog.
lowercase letters , and underscores . The words are terminated by a full -stop .
The predicate read_ward_list reads a character , C, and calls read_word- list ( C,
Words) . This predicate does one of three actions , depending on what C is . If C
is a word character , then the next word is found , and recursively the rest of the
words are found that is an uppercase letter , a lowercase letter or an underscore .
The second action is to ignore filling characters , and so the next character is read ,
and the program continues recursively . Finally , if the character denoting ends of
words is reached , the program terminates and returns the list of words .
It is important that the program must always read a character ahead , and
then test what it should do . If the character is useful , for example , a word
character , it must be passed down to be part of the word . Otherwise characters
can get lost on the event of backtracking . Consider the following read and process
loop :
process ( [ ]) +-
get (C) , end_of- words _char ( C) .
process( [W IWords ]) +-
get (C ) , word _char (C) , get _word (C ,W ) , process (Words ) .
If the first character in a word is not an end_of_words_char , the first clause will
fail , and the second clause will cause the reading of the next character .
Returning to Program 12.2, the predicate read_word ( O, W, Ol ) reads a word
Wgiven the current character Cand returns the next character after the word , 01 .
The list of characters comprising the word are found by word_chars/ 9 (with the
same arguments as read _word ) . The word is created from the list of characters
using the system predicate name . In word _chars there is the same property of
looking ahead one character at a time , so that no character is lost .
Predicates such as.fill _char/ l and word_char/ l exemplify data abstraction in
Prolog .
(i) Extend Program 12.2 so that it handles apostrophes (39) and numbers (48-
57) as word characters , and question marks (63) and exclamation marks (33)
as terminators . What would be involved in using it to read in sentences, with
commas , etc .?
12.2 Program access and manipulation 179
12 . 2 Program access and manipulation
So far our programs have been assumed to be resident in the computer 's
memory , without discussion of how they are represented or how they got there .
Many applications depend on accessing the clauses in the program . Furthermore ,
if programs are to be modified at runtime , there must be a way of adding ( and
deleting ) clauses .
The system predicate for accessing the program is clause ( Head , Body ) . The
goal clause ( Head , Body ) ? must be called with Head instantiated . The program is
searched for the first clause whose head unifies with Head . The head and body
of this clause are then unified with Head and Body . On backtracking , the goal
succeeds once for each unifiable clause in the procedure . Note that clauses in the
program cannot be accessed via their body .
Facts have the atom true as their body . Conjunctive goals are represented
using the binary functor " ," . The actual representations can be easily abstracted
away , however .
Consider Program 3 . 12 for member :
member ( X , [X I Xs ] ) .
member (X , [ YIYs ] ) + - member (X , Ys ) .
The goal clause ( member ( X , Ys ) , Body ) has two solutions : { Ys = [X ] Xs ] , Body = true }
and { Ys = [ 11 Ysl ] , Body = member ( X , Ysl ) } . Note that a fresh copy of the variables
appearing in the clause is made each time a unification is performed . In terms of
the metalogical primitives freeze and melt , the clause is stored in frozen form in
the program . Each call to clause causes a new melt of the frozen clause . This is
the logical counterpart of the classic notion of reentrant code .
System predicates are provided both to add clauses to the program , and to
remove clauses . The basic predicate for adding clauses is assert ( Clause ) , which
adds Clause as the last clause of the corresponding procedure . For example ,
assert ( father ( haran , lot ) ) ? adds the father fact to the program . When describing
rules an extra level of brackets is needed for technical reasons concerning the
precedence of terms . For example , assert ( ( parent ( X , Y ) + - father ( X , Y ) ) ) is the
correct syntax .
There is a variant of assert , assert a , that adds the clause at the beginning of
a procedure .
If Clause is uninstantiated ( or if Clause has the form H + - B with H uninstantiated
) , an error condition occurs .

-
The predicate retract ( 0 ) removes from the program the first clause in the
program unifying with C . Note that to retract a clause such as a ~ b , c , d , you need
to specify retract (( a ~ C) ) . A call to retract may only mark a clause for removal ,
rather than physically removing it , and the actual removal would occur only when
Prolog ' s top - level query is solved . This is due to implementation reasons , and may
lead to anomalous behavior in some Prologs .
Asserting a clause freezes the terms appearing in the clause . Retracting the
same clause melts a new copy of the terms . In many Prologs this is exploited to
be the ea Biest way of copying a term . The predicate copy aBsumed in Chapter 10
can thus be defined aB
copy ( X ,Y ) + - assert a ( $ tmp ( X ) ) , retract ( $ tmp (Y ) ) .
assuming $ tmp is not used elsewhere in the program .
The predicates assert and retract introduce to Prolog the possibility of programming
with side effects . Code depending on side effects for its successful
execution is hard to read , hard to debug , and hard to reason about formally .
Hence these predicates are somewhat controversial , and using them is sometimes
a result of intellectual laziness and / or incompetence . When programming , they

should be used as little as possible . Many of the programs to be given in this book
can be written using assert and retract , but the result is less clean and less efficient
. Further , as Prolog compiler technology advances , the inefficiency in using
assert and retract will become more apparent .
It is possible , however , to give logical justification for some limited uses of

assert and retract . Asserting a clause is justified , for example , if the clause already
logically follows from the program . In such a case adding it will not affect the
meaning of the program , since no new consequences can be derived from it , but
perhaps only its efficiency , as some consequences could be derived faster . This
use is exemplified in the lemma construct , introduced in Section 12 . 3 below .
Similarly , retracting a clause is justified if the clause is logically redundant . In

this case retracting constitutes a kind of logical garbage collection , whose purpose
is to reduce the size of the program .
We identify a few other legitimate uses for assert and retract . One is setting
up and using global switch es that affect program execution . This will be discussed
in Section 13 . 2 on programming hacks . Another is for solving problems which by
definition require the modification of the program ( e . g . , consult in Section 12 . 5 ,
and meta - programs such as editors ).

12.3 Memo -functions 181
hanoi ( N , A , B , C , Moves ) ~
Moves is the sequence of moves required to move N discs
from peg A to peg B using peg C as an intermediary
according to the rules of the Towers of Hanoi puzzle .
hanoi ( 1 ,A ,B ,C , [A to B ] ) .
hanoi ( N ,A ,B ,C ,Moves ) +-
N > 1,
N1 := N - 1 ,
lemma (hanoi ( ni ,A ,C ,B ,Ms1 ) ) ,
hanoi ( ni ,C ,B ,A ,Ms2 ) ,
append ( Ms1 , [A to BIMs2 ] ,Moves ) .
lemma ( P ) +- P , assert a ( ( P +- I) ) .
Testing
test - hanoi ( N ,Pegs ,Moves ) +-

hanoi ( N ,A ,B ,C ,Moves ) , Pegs = [A ,B ,C ] .
Program 12 . 3 : Towers of Hanoi using a memo - function
12 . 3 Memo ~functions
Memo - functions save the results of subcomputations to be used later in a

computation . Remembering partial results is impossible within pure Prolog , so
memo - functions are implemented using side effects to the program . Programming
in this way can be considered bottom - up programming .
The prototypical memo - function is lemma ( Goal ) . Operationally it attempts

to prove the goal Goal , and , if successful , stores the result of the proof as a lemma .
It is implemented as
lemma ( P ) +- P , assert a ( ( P +- I) ) .
The next time the goal P is attempted , the new solution will be used , and there
will be no unnecessary recomputation . The cut is present to prevent the more
general program being used . Its use is justified only if P does not have multiple
solutions .
Using lemmas is demonstrated with Program 12 .3 for solving the Towers

of Hanoi problem . The performance of Program 3 .30 in solving the problem is
dramatically improved . It is well known that the solution of the Towers of Hanoi
with N discs requires fN - l moves . For example , 10 discs require 1023 moves , or
182 Extra-LogicalPredicates 12.3
echo +- read(X ), echo(X ).

echo(X ) +- end_of-.file(X ), I.
echo(X ) +- write (X ), nl , read(Y ) , I, echo(Y ).
Program 12 .4 : Basic interactive loop
in terms of Program 3.30, 1023 calls of hanoi(l ,A ,B, C,Xs) . The overall number
of general calls of hanoi/ 5 is significantly more.
The solution to the Towers of Hanoi repeatedly solves subproblems moving
the identical number of discs . A memo - function can be used to recall the moves
made in solving each subproblem of moving a smaller number of discs. Later
attempts to solve the subproblem can use the computed sequence of moves rather
than recomputing them .
The idea is seen with the recursive clause of hanoi in Program 12 .3 . The first
call to solve hanoi with N - 1 discs is remembered , and can be used by the second
call to hanoi with N - 1 discs.
The program is tested with the predicate test_hanoi (N ,Pegs,Moves) . Nis the
number of discs, Pegs is a list of the three peg names , and Moves is the list of moves
that must be made . Note that in order to take advantage of the memo -functions ,
a general problem is solved first . Only when the solution is complete , and all
memo -functions have recorded their results , are the peg names instantiated .
Exercise for Section 12.3
(i ) Two players take turns to say a number between 1 and 3 inclusive . A sum is
kept of the numbers , and the player who brings the sum to 20 wins . Write a
program to play the game to win , using memo-functions .
12 .4 Interactive programs
A common form of a program requiring side effects is an interactive loop .

A commarld is read from the terminal , responded to , and the next command
read . Interactive loops are implemented typically by while loops in conventional
languages . Program 12.4 gives the basic skeleton of such programs , where a
command is read then echoed by being written on the screen.
The read / echo loop is invoked by the goal echo. The heart of the program
is the relation echo(X) , where Xis the term to be echoed. The program assumes
a predicate end_of-file (X) which is true if X is the end-of-file marker . What is
the end-of-life marker is system dependent . If the end-of-file marker is found , the
loop terminates ; otherwise the term is written and a new term is read .
Note that the testing of the term is separate from its reading . This is necessary
to avoid losing a term : terms cannot be reread . The same phenomenon
occurred in Program 12.2 for processing characters . The character was read and
then separately processed .
Program 12.4 is iterative and deterministic . It can be run efficiently on a

system with tail recursion optimization , always using the same small amount of
space.
We give two examples of programs using the basic cycle of reading a term
then processing it . The first is a line editor . The second interactive program is a
shell for Prolog commands , which is essentially a top- level interpreter for Prolog
in Prolog .
The first decision in writing a simple line editor in Prolog is how to represent
the file . Each line in the file must be accessible, together with the cursor position ,
that is the current position within the file . We use a structure file (Before ,After )
where Before is a list of lines before the cursor , and After is a list of lines after the
cursor . The cursor position is restricted to be at the end of some line . The lines
before the cursor will be in reverse order to give easier access to the lines nearer
the cursor . The basic loop accepts a command from the keyboard , and applies it
to produce a new version of the file . Program 12.5 is the editor .
An editing session is invoked by edit, which initializes the file being processed
to the empty file , file ( [ ],[ ]) ) . The interactive loop is control led by edit (File ) . It
writes a prompt on the screen, using edit_prompt , then reads and process es a
command . The processing uses the basic predicate edit ( File , Command ) which
applies the command to the file . The application is performed by the goal apply
( Command ,File ,Filel ) where Filel is the new version of the file after the command
has been applied . The editing continues by calling edit/ l on Filel . The
third edit/ 2 clause handles the case when no command is applicable , indicated by
the failure of apply. In this case an appropriate message is printed on the screen
and the editing continues . The editing session is terminated by the command
exit , which is separately tested for by edit/ 2.
Let us look at a couple of apply clauses, to give the flavor of how commands
are specified . Particularly simple are commands for moving the cursor . The clause
apply(up,file([XI:XS
] ,Ys),file(:XS
,[X I Ys])).
edit(File,exit) +- !.
edit(File,Command ) +-
apply(Command,File,Filel ), !, edit(Filel ).
edit(File,Command ) +-
writeln([Command ,' is not applicable']), !, edit(File).
apply(up,file([X IXsJ,Ys),file(Xs,[X IYsJ)).
apply(up(N) ,file(Xs,Ys) ,file(Xs1,Y si )) ~
N > 0, up(NiXs,Ys,Xs1,Ys1).
apply(down,file(Xs,[YIYs]),file([YIXsJ,Ys)).
apply(insert(Line),file(Xs,Ys) ,file(Xs,[LineIYs])).
apply(delete,file(Xs,[YIYsJ),file(Xs,Ys)).
apply(print,file([X IXsJ,Ys),file([X IXs],Ys)) ~
write(X), nl.
apply(print (* ),file(Xs,Ys),file(Xs,Ys)) ~
reverse(Xs,Xs1), write..file(Xs1), write le(Ys).
up ( N , [ ] , Ys , [ ] , Ys ) .
up ( O , Xs ,Y siXs ,Y s ) .
up ( N , [X I Xs ] , Ys , Xsl , Ysl ) + -
N > 0, Nl is N- l , up(Nl,Xs,[XIYs],Xsl,Ysl).
write - fiIe ( [X I Xs ] ) + -
write (X ) , nl , write - fiIe ( Xs ) .
write - file ( [ ] ) .
write _ prompt + - write ( ' ~ ') , nl .
Program 12 . 5 : A line editor
says that we move the cursor up by moving the line immediately above the cursor
to be immediately below the cursor . The command fails if the cursor is at the
top of the me . The command for moving the cursor down is analogous to moving
the cursor up , and is also in Program 12.5.
Moving the cursor up N lines , rather than a single line , involves using an
auxiliary predicate up/ 5 to change the cursor position in the file . Issues of robustness
surface in its definition . Note that apply tests that the argument to up
is sensible , i .e., a positive number of lines , before up is invoked . The predicate up
itself handles the case when the number of lines to be moved up is greater than
the number of lines in the file . The comm ~~nd succeeds with the cursor placed at
the top of the file . Moving a cursor down N lines is requested in the exercises.
Other commands given in Program 12.5 insert and delete lines . The command
for insert , in ~ert (Line ) , contains an argument , namely the line to be inserted
. The command for delete is straightforward . It fails if the cursor is at the
bottom of the screen. Also in the editor are commands for printing the line above
the cursor , print , and for printing the whole file , print ( * ) .
The editor commands are mutually exclusive . Only one apply clause is applicable
for any command . This is indicated by the cut in the second edit/ 2
clause. As soon as an apply goal succeeds, there are no other possible alternative
paths . This method of imposing determinism is a little different than described
in Section 11.1 where the cuts would have been applied directly to the apply facts
themselves . The difference between the two approach es is merely cosmetic .
A possible extension to the editor is to allow each command to handle its
own error messages. For example , suppose you wanted a more helpful message
than " Command not applicable " when trying to move up when at the top of the
file . This would be handled by ertending the apply clause for moving up in the
file .
We shift from editors to shells . A shell accepts commands from a terminal

and executes them . We illustrate with an example of a shell for answering Prolog
goals . This is presented as Program 12.6.
The shell is invoked by shell. The code is similar to the editor . The shell
gives a prompt , using shell_prompt , then reads a goal and tries to solve it using
shell ( Goa~ . A distinction is made between solving ground goals, where a yes/ no
answer is given , and solving nonground goals where the answer is the appropriately
instantiated goal . These two cases are handled by shell_salve_ground and
shell _solve respectively . The shell is terminated by the goal exit .
Both shell_solve_ground and shell_solve use the metavariable facility to call
the goal to be solved . The success or failure of the goal determines the output
message. These predicates are the simplest examples of metainterpreters , a
subject discussed in Chapter 19.
The shell_solve procedure shows an interesting solve-write -fail combination ,
which is useful to elicit all solutions to a goal by forced backtracking . Since we
do not wish the shell to fail , an alternative clause is provided , which succeeds
when all solutions to the goal are exhausted . It is interesting to note that it is not
possible to collect all solutions to goals in a straightforward way without using
some sort of side effect . This is explained further in Chapter 17 on second-order
programmIng .
shell-solve(Goal) +-
Goal, write (Goal), nl , fail .
shell-solve(Goal) +-
write ('No (more) solutions'), nl .
shell-solve_ground(Goal) +-
Goal, !, write ('Yes'), nl .
shell-solve_ground(Goal) +-
write ('No'), nl .
shell-prompt +- write ('Next command? ').
Program 12.6: An interactive shell
The shell can be used as a basis for a logging facility to keep a record of a
session with Prolog . Such a facility is given as Program 12 . 7 . This new shell is
invoked by log , which calls the basic interactive predicate shell ( Flag ) with Flag
initialized to log . The Hag takes one of two values , log or nolog , and indicates
whether the output is currently being logged , or not .
The logging facility is an extension of Program 12 .6 , the major difference
being that the principal predicates take an extra argument , indicating the current
state of logging . Two extra commands are added , log and nolog , to turn logging
on and off .
The Hag is used by the predicates concerned with I / O . Each message written
on the screen must also be written in the logging file . Also each goal read is
inserted in the log to increase the log ' s readability . Thus calls to read in Program
12 .6 are replaced by a call to shell _read , and calls to write replaced by calls to
shell _ write .
The definition of shell _write specifies what must be done .
shell _write ( X ,nolog ) +- write (X ) .
shell _write ( X ,log ) + - write ( X ) , file _write ( [X ] , ' prolog .log ' ) .
If the flag is currently nolog , the output is written normally to the screen . If
log +-- shelI (log ) .

shelI (Flag ) +--
shell _ prompt , shell . . xead ( Goal , Flag ) , shell ( Goal , Flag ) .
shell ( exit , Flag ) + -
! , close Jogging - . file .
shell ( nolog , Flag ) + -
! , shell ( nolog )
shell ( log , Flag ) + -
! , shell ( log ) .
shell ( Goal , Flag ) + -
ground ( Goal ) , ! , shell - solve _ ground ( Goal , Flag ) , shell ( Flag ) .
shell ( Goal , Flag ) + -
shell - solve ( Goal , Flag ) , shell ( Flag ) .
shell . . solve ( Goal , Flag ) + -
Goal , shell _ write ( Goal , Flag ) , nl , fail .
shell . . solve ( Goal , Flag ) + -
shell _ write ( ' No ( more ) solutions ' , Flag ) , nl .
shell - 8olve _ ground ( Goal , Flag ) + -
Goal , f , shell _ write ( ' Yes ' , Flag ) , ill .
shell - 8olve _ ground ( Goal , Flag ) + -
shell _ write ( ' No ' , Flag ) , ill .
shell _ prompt + - write ( ' Next command ? ' ) .
shell - read ( X , log ) + - read ( X ) ,
file _ write ( ( ' Next command ? ' , X ] , ' prolog . log ' ) .
shell - read ( X , nolog ) + - read ( X ) .
shell _ write ( X , nolog ) . f - write ( X ) .
shell _ write ( X , log ) . f - write ( X ) , file _ write ( Xi prolog . log ' ) .
file _ write ( X , File ) + - telling ( Old ) , tell ( File ) , write ( X ) , ill , tell ( Old ) .
close Jogging le + - tell ( ' prolog . log ' ) , told .
Program 12 . 7 : Logging a session
the flag is log , an extra copy is written to the file prolog . log . The predicate
jile _ write ( X , File ) writes the line X to me File .
Only two of the predicates in Program 12 . 7 are system dependent ; file _ write
and close _ logging - file . They depend on additional system predicates for dealing
188 Extra-LogicalPredicates 12.4
with files . Their definition uses the Edinburgh Prolog primitives tell , told and
telling which are discussed in Appendix B . The other assumption built into the
code is that the logged output will be recorded in a file prolog .log.
(i) Extend Program 12.5, the editor , to handle the following comlI lands
a. Move tne cursor down N lines .
b . Delete N lines .
c. Move to a line containing a given term .
d . Replace one term by another .
e. Any command of your choice .
(ii ) Modify the loggihg facility , Program 12.7, so the user can specify the destination
file of the logged output .
12 .5 Failure - driven loops
The interactive programs in the previous section were all based on tail recursive
loops . There is an alternative way of writing loops in Prolog that are
analogous to repeat loops in conventional languages . These loops are driven by
failure and are called failure -driven loops. These loops are useful only when used in
conjunction with extra -logical predicates which cause side effects . Their behavior
can be understood only from an operational point of view .
A simple example of a failure-driven loop is a query Goal, write ( GoaQ, nl,
fail ? which causes all solutions to a goal to be written on the screen. Such a loop
is used in the shells of Programs 12.6 and 12.7.
A failure-driven loop can be used to define the system predicate tab(N) for
printing N blanks on the screen. It uses Program 8.5 for between:
tab (N) +- between(liN ,1), put (32), fail .
Each of the interactive programs in the previous section can be rewritten

using a failure -driven loop . The new version of the basic interactive loop is given as
Program 12.8. It is based on a nonterminating system predicate repeat, which can
be defined by the minimal recursive procedure in Program 12.8. Unlike Program
12.4, the goal echo(X) fails unless X is the end of file marker. The failure causes
backtracking to the repeat goal , which succeeds and the next term is read and
echoed. The cut in the definition of echo ensures that the repeat loop is not
reentered later .
12.5 Failure - driven loops 189
echo +- repeat, read(X ), echo(X ), !.

echo(X ) +- end_of-file (X ), !.
echo(X ) +- write (X ), nl , fail .
repeat .
repeat +- repeat .
Program 12 .8 : Basic interactive repeat loop
consult(File) +- see(File), consultJoop, seen.

consult Joop +-
repeat, read(Clause), process(Clause) , !.
process(X ) +-
end_of-file (X ) , !.
process(Clause) +-
assert(Clause), fail .
Program 12 .9 : Consulting a file
Failure -driven loops that use repeat are called repeat loops, and are the analogue
of repeat loops from conventional languages . Repeat loops are useful in
Prolog for interacting with the outside system to repeatedly read and/ or write .
Repeat loops require a predicate that is guaranteed to fail (the goal echo(X) in
Program 12.8), which causesthe iteration to continue. This predicate only succeeds
when the loop should be terminated . A useful heuristic for building repeat
loops is that there should be a cut in the body of the clause with the repeat
goal , which prevents a non -terminating computation in case the loop is being
backtracked into .
We use a repeat loop to define the system predicate consult(File) for reading
in a file of clauses and asserting them . Program 12.9 contains its definition . The
system predicates see(File) and seenare used for opening and closing a input file,
respectively .
Tail recursive loops are preferable to repeat loops because the latter have
no logical meaning . In practice , repeat loops are often necessary to run large
computations, especially on Prolog implementations without tail recursion optimization
and/ or without garbage collection. Explicit failure typically initiates
some implementation dependent reclamation of space.
Exercise for Section 12.5
(i ) Define the predicate abolish(FiN) that retracts all the clauses for the procedure
F of arity N .
12 .6 Background
Input / output has never really blended well with the rest of the language
of Prolog . Its standard implementation , with side effects , relies solely on the
procedural semantics of Prolog , and has no connection to the underlying logic
programming model . For example , if an output is issued on a failing branch of a
computation , it is not undone upon backtracking . If an input term is read , it is
lost on backtracking , as the input stream is not backtrackable .
Concurrent logic languages attempt to remedy the problem and to integrate

input / output better with the logic programming model , by identifying the input
/ output streams of devices with the logical streams in the language (Shapiro ,
1984) . Perpetual recursive process es can produce or consume incrementally those
potentially unbounded streams .
Self-modifying programs are a bygone concept in computer science. Modern

programming languages preclude this ability , and good assembly-language
practice also avoids such programming tricks . It is a historical irony that a programming
language which attempts to open a new era in computer programming
opens the front door to such archane techniques , using the predicates assert and
retract .
These program manipulation predicates of Prolog were devised initially as a

low -level mechanism for loading and reloading programs , implemented inProlog -
10 by the consult and reconsult predicates . However , like any other feature of a
language , they ended up being used for tasks that , we believe , were not intended
by their original designers .
Modern implementations of Prolog attempt to remedy some of the damage

by introducing alternative constructs , such as slots in ESP (Chikayama , 1984) ,
or special declarations for modifiable predicates , as in Quintus Prolog (Quintus ,
1985) . .
Concurrent logic languages can and do eliminate this feature altogether (Silverman
et al ., 1986) , since global , modifiable , data structures can be implemented
in them by monitors , which have a pure logical definition as a perpetual recursive
process (Shapiro , 1984) .
12.6 Background 191
In Edinburgh Prolog there are two system predicates for reading characters ,
get O ( X ) and get ( X ) . The distinction between them is that get O returns the next
character , while get gets the next printable character , that is one with an ASCII
code greater than 32 . Only one , the more general , is necessary , which we call get
rather than get O .
The program for the Towers of Hanoi was shown to us by Shmuel Sarra .
The line editor is originally due to Warren ( 1982b ) .

Chapter 13
Pragll1atics
Programs in the previous chapters on pure Prolog and its extensions emphasized
clarity of underlying concepts . In practice , issues of efficiency , constraints of
a particular implementation , programming environment , and so forth , also arise .
The logic programming folklore has a large body of techniques and tricks that are
necessary to construct practical nontrivial Prolog systems . This chapter changes
focus to more pragmatic issues in writing Prolog programs .
Software engineering considerations are equally relevant for programming in
logic programming languages as in procedural languages . Prolog is no different
from any other language in its need for a methodology to build and maintain
large programs . A good programming style is important , as is a good program
development methodology .
The four sections discuss efficiency , assorted programming tricks , programming
style and layout , and program development .
13 . 1 Efficiency of Prolog programs
Practical Prolog programming requires consideration of efficiency . In order to
discuss this issue , we need to set out the criteria for evaluating different programs .
The main factor is the number of unifications performed and attempted in the
course of a computation . This is related to time . Another criterion is depth of
recursion - if the computation exceeds the maximum depth , the computation
aborts . In practice this is a major problem . The third issue is the number of data
structures generated . Each is discussed in turn .
One should expect that an intelligent translation of a deterministic , sequential
algorithm into Prolog would preserve the expected performance of the algorithm .
13.1 Efficiency of Prolog programs 193
Typically , the resulting Prolog programs would rely neither on general unification
nor on deep backtracking .
A difficulty may arise in the implementation of algorithms that rely heavily
on destructive manipulation of data structures , e.g., destructive pointer manipulation
and arrays . Such data structures can be simulated directly in Prolog , with a
logarithmic overhead , using standard techniques (e.g., simulation by trees ) . However
, in many c~ es it would be more natural to modify the algorithm itself , to
accommodate for the single -~ signment nature of the logical variable .
For such algorithms , standard techniques for analyzing the complexity of

programs apply . If full unification (the unification of two arbitrary terms in the
goal ) is not employed , then the reduction of a goal using a clause can be shown to
take time bounded by a constant , whose size is program dependent . As a result
analyzing the number of reductions a program performs as a function of the size
of its input is a good way to determine its time complexity .
When programming in Prolog , its full power might be used. One writes
nondeterministic programs , and programs that employ full unification . Analyzing
the complexity of such programs is a more difficult task , and requires reasoning
about the size of the search space traversed and the size of the input terms being
unified .
The first answer to improved performance is better algorithms . Although a

declarative language , the notion of an algorithm applies equally well to Prolog as
to other languages . Examples of good and bad algorithms for the same problem ,
together with their Prolog implementations , are shown in previous chapters . Linear
reverse using accumulators (Program 3.16b) is clearly more efficient than naive
reverse (Program 3.16a) . Quicksort (Program 3.22) is better than permutation
sort (Program 3.20) .
Besides coming up with better algorithms , one can do several other things
to influence the performance of one's Prolog programs . One is to choose a better
implementation . An efficient implementation is characterized by its raw speed,
its indexing capabilities , support for tail recursion optimization , and garbage collection
. The speed of logic programming languages is usually measured in LIPS ,
or logical inferences per second. A logical inference corresponds to a reduction in
a computation .
Once the implementation is fixed , the programs themselves can be tuned by :
. Good goal ordering , where the rule is : Fail as early as you can .
. Elimination of nondeterminism using explicit conditions and cuts .
. Exploitation of the indexing facility , by ordering arguments appropriately .

194 Pragmatics 13.1
Issues in ordering goals are mentioned in Section 7.3. How to use green cuts
to express determinism of a program is discussed in Section 11 . 1 .
Indexing is important in conjunction with Tail recursion optimization , as

discussed in Section 11.2. Even for nontail recursive programs , indexing can
improve the performance of programs , by reducing the search for an applicable
clause. This is important in programs that represent tables as a set of facts , e.g.,
a parser and a compiler .
Minimizing the number of data structures being generated is a subject that
has not received much attention in the Prolog literature . We give an example
analysis to show the reasoning. The predicate sublist(Xs, Ys) for determining
whether Xs is a sublist of Y s has several definitions . Let us discuss the relative
efficiency of two of them with respect to creating data structures , and with respect
to a particular use, testing whether one given list is a sublist of another given list .
The two versions of sublist we consider involve Program 3.13 for calculating
the prefix and suffix. of a list . Clause (i) defines a sublist as a prefix of a suffix.,
while clause (ii ) defines a sublist as a suffix. of a prefix :
sublist(Xs,A X Bs) ~ suffix(XBs,A X Bs), prefix (Xs,XBs). (i)
sublist(Xs,A X Bs) ~ prefix (AXs ,A X Bs), suffix(Xs,AXs ). (ii )
Although logically the same, there is a difference in the performance of the

two programs. If the two arguments to sublist are complete lists, clause (i) simply
goes down the second list , returning a suffix of it , then goes down the first list ,
checking if the suffix is a prefix of the first list . This execution does not generate
any new intermediate data structures. On the other hand, clause (ii ) creates a
new list , which is a prefix of the second list , then checks if this list is a suffix of
the first list . If the check fails , backtracking occurs , and a new prefix of the first
list is created .
Even though , on the average, the number of reductions performed by the

two clauses is the same, they are different in their efficiency . The first does not
generate new structures (does not cons, in Lisp jargon) . The second one doe~.
When analyzing Lisp programs , it is common to examine the consing performance
in great detail , and whether a program conses or not is an important efficiency
consideration . We feel that the issue is just as important for Prolog programs , but
perhaps the state of the art of studying the performance of large Prolog programs
has not matured enough to dictate this as yet .
verify (Goal ) +- not not Goal .

Program 13 .1: Verifying a goal
numbervars('$VA R'(N),N,Nl ) +-
Nl := N+ l .
numbervars(Term,Nl ,N2) +-
nonvar(Term) , functor (Term,Name,N),
numbervars(O,N,Term,Nl ,N2).
numbervars(N ,N,Term,Nl ,Nl ) .
numbervars(I ,N,Term,Nl ,N3) +-
1 < N,
11 := 1+ 1,
arg(ll ,Term,Arg ),
numbervars(Arg ,Nl ,N2) ,
numbervars(ll ,N,Term,N2,N3).
Program 13.2: Numbering the variables in a term
13 .2 Programming tricks
Every programming language has its collection of programming tricks , and

Prolog is no exception . Here we give a handful of useful Prolog tricks . The tricks
in this section are predicates that either manipulate variable instantiations , or
show the use of global flags .
An interesting property of not is that it never instantiates its arguments . This
is due to the explicit failure after the goal succeeds, which undoes any bindings
made. This property is exploited to define a procedure verify( Goa~, Program
13.1, which determines whether a goal is true without affecting the current state
of the variable bindings . Double negation provides the means .
We note , for curiosity only , that negation as implemented in Prolog has a feature
in common with negation in natural language . A doubly negated statement
is not the same as the equivalent affir ~ ative statement .
A useful system predicate in Edinburgh Prolog is numbervars( Term,Nl ,N2)
which successively instantiates the distinct variables in Term using the string
'$ VA R'(N) where N ranges from Nl to N2- 1. For example, the goal number-
vars(foo(X , Y) ,1,N) ? succeedsinstantiating X to '$ VA R'(l ), Y to '$ VAR '(2) and
Nto 9.
It is another example of a predicate performing structure inspection , and is

196 Pragmatics 13.2
variant (Terml ,Term2) ~

verify (( numbervars(Terml ,O,N),
numbervars(Term2,O,N),
Terml = Term2 )).
Program 13.3: Variant
given as Program 13.2. The program counts up rather than counts down so that
the variables will be numbered in increasing order from left to right . In order not
to give an error , calls to numbervars must have the second argument instantiated .
Numbervars can be used in a backhanded way to define metalogical predicates
. For example ,
ground (Term ) +- numbervars (Term ,O,O) .
It CaJlalso be used to define freeze, namely freeze(X , Term ) +- copy(X , Term ) ,

numbervars ( Term , O,N) . We defer a definition of melt till Chapter 15. Another
useful example applies both verify aJld numbervars . To motivate the example , we
refer back to the discussion of Section 10.2 on metalogical term comparison .
The predicate = = / 2 defines a notion of equality much stricter than unifiabil -

ity , i .e., = / 2. An intermediate notion of equality exists in Prolog , inherited from
logic , namely whether two terms are alphabetic variants . Recall that two terms
are variants if they are equal up to renaming of variables ; that is , they can be
made syntactically identical by consistently changing names of variables in one of
them . Examples are the pairs J( X , Y) and J( Y, Z) , J( a,X) and J( a, Y) , and the pair
J( X ,X) and J( Y, Y) .
The predicate variant ( Terml , Term2 ) is true if Terml and Term2 are alphabetic
variants . It is defined in Program 13.3. The trick is to instantiate the
variables using Program 13.2 for numbervars , test whether the terms unify , then
undo the instantiation . This can be done with verify .
The three forms of comparison , = / 2, variant / 2 and = = / 2 are progressively

stronger , with unifiability being the weakest and most general . Identical terms
are alphabetic variants , and variant terms are unifiable . The distinction between
the different comparisons vanish es for ground terms ; for ground terms all three
comparisons return the same result .
Another use of verify is to provide prettier appearance of terms containing
variables . During a computation the Prolog interpreter assigns its own internal
names to variables . These are typically totally unintelligible , making it difficult
to read output with variables . Program 13. 4 defines write _vnames ( Term ) , a write
write _vnames(Term) +- lettervars(Term), write (Term), fail .

write -vnames(Term).
lettervars (Term) +-
list _of_variables(Term,Vars),
variableJIames(Names),
unify _variables(Vars,Names).
list _of_variables(V ,[V]) +- var(V ), !.
list._of_variables(V ,[ ]) +- constant(V ), !.
list _of_variables(Term,Vs) +-
functor (Term ,F ,N),
list _of_variables(N ,Term,Vsl ),
flatten (Vsl ,VB).
list -of-variables(N,Term,[VArgs IVs]) +-
N > 0)
arg(N,Term,Arg ),
list _of_variables(Arg ,VArgs) ,
Nl := N - l ,
list _of_variables(Nl ,Term,Vs).
list _of_variables(O,Term,[ ]) .
unify _variables([V I Vs],[V INs]) +- !, unify _variables(Vs,Ns).
unify _variables([V IVs],Ns) +- !, unify _variables(Vs,Ns).
unify _variables(Vs,Ns). % Exhausted variables or names
variable-names(['X ' 'y ' 'Z' 'U' 'V ' 'w ' 'Xl ' 'Yl ' 'Zl ' 'Ul ' 'Vl ' 'Wl '
" " " , , , , , ,
'X2 ' 'Y2 ' 'Z2' 'U2' 'V2' 'W2' 'X3 ' 'Y3' 'Z3' 'U3' 'V3 ' 'W3'])
, , , , , , , , , " .
flatten (Lists,Xs) +- SeeProgram 9.la

Program 13 .4 : Writing out a term with non -numeric variable names
set~ ag(Name,X ) +-
nonvar(Name),
retract (flag(Name,Val)), !,
asserta(flag(Name,X ) ).
set~ ag(Name,X ) +-
nonvar(Name), asserta(flag(Name,X )).
Program 13 .5: Using global flags
utility that writes variables with names rather than numbers . The predicate
lettervars(X) given in Program 13. transforms the variables in X to alphanumeric
198 Pragmatics 13.2
gensym(Prefix ,V ) +-
var (V ),
atom(Prefix),
old-value(Prefix ,N),
Nl := N+ l ,
set-Hag(gensym(Prefix),Nl ),
string _concatenate(Prefix ,N 1,V) ,
t.
old-value(Prefix ,N) +- flag(gensym(Prefix) ,N), !.
old_value(Prefix ,O).
string _concatenate(X ,Y ,XY ) i -
name(X ,Xs), name(Y ,Ys), append(Xs,Ys,XYs ), name(XY ,XYs).
set- Hag(Flag ,Value ) +- See Program 13.5
Program 13 .6 : Generating new symbols
strings according to a predefined list of names .
Another programming trick uses assert and retract to simulate global variables
. The predicate flag (Name , Value) is used to maintain the current value of
the flag , while set_flag (Name , Value) sets the value of the flag . The definition of
set-flag is given as Program 13.5.
One application of the flag procedures is to facilitate the generation of names

of constants during a computation . We note , however , that the need for such a
function is much smaller than in other languages . Usually such "gensym " functions
are used to mimic some subset of the functionality of the logical variables .
Having logical variables to begin with decreases most of its utility .
A common choice for implementing a "gensym " function is to have a root
prefix , e.g., x, and add on suffix es with increasing numeric values , e.g., xi ;x2,. . .,
etc . The flag is used to keep a counter of the last numeric suffix chosen. The
predicate gensym(Prefix , Constant ) , given as Program 13.6, returns a new ' constant
name Constant from the root prefix .
13 .3 Programming style and layout
One basic concern in composing the programs in this book has been to make
them ''as declarative as possible " to increase program clarity and readability .
13.3 Programming style and layout 199
A program must be considered as a whole . Its readability is determined by its
physical layout , and by the choice of names appearing in it . This section discuss es
the guidelines we use when composing programs .
An important influence in making programs easy to read is the naming of
the various objects in the program . The choice of all predicate names , variable
names , constants and structures appearing in the program affect its clarity . The
aim is to emphasize the declarative reading of the program .
We choose predicate names to be a word ( or several words ) that names relationships
between objects in the program , rather than describes what the program
is doing . Coining a good declarative name for a procedure does not come easily .
The activity of programming is procedural . It is often easier to name procedurally
rather than declaratively ( and programs with procedural names usually ran
faster ) . Once the program works , however , we often revise the predicate names
to be declarative . Composing a program is a cyclic activity in which names are
constantly being reworked to reflect our improved understanding of our creation ,
and to enhance readability by us and others .
Mnemonic variable names also have an effect on program readability . A name
can be a meaningful word ( or words ) , or a standard variable form such as Xs for
lists .
Variables that appear only once in a clause can be handled separately . They
are in effect anonymous , and from an implementation viewpoint need not be
named . Several Prologs adopt a special syntactic convention for referring to
anonymous variables . Edinburgh Prolog , for example , uses a single underscore .
Using this convention , Program 3 . 12 for member would be written
member ( X , [ XI - ] ) .
member ( X , [ - I Xs ] ) + - member ( X , Xs ) .
The advantage of the convention is to highlight the significant variables for unification
. The disadvantage is related ; the reading of clauses becomes procedural
rather than declarative .
We use different syntactic conventions for separating multiple words in variable
names and predicate functors . For variables , composite words are run together
, each new word starting with a capital letter . Multiple words in predicate
names are linked with underscores . Syntactic conventions are a matter of taste ,
but it is preferable to have a consistent style .
The layout of individual clauses also has an effect on how easily programs
can be understood . We have found the most helpful style to be

200 Pragmatics 13.3
foo( (Arguments)) +-
bart ((Argumentsl ))'
barz((Argumentsz)),
.
barn ( (Argumentsn}).
The heads of all clauses are aligned , the goals in the body of a clause are
indented and occupy a separate line each. A blank line is inserted between procedures
, but there is no space between individual clauses of a procedure .
Layout in a book and the typography used are not entirely consistent with
actual programs . If all the goals in the body of a clause are short , then have them
on one line . Occasionally we have tables of facts with more than one fact per line .
A program can be self-documenting if sufficient care is taken with these two

factors , and the program is sufficiently simple . Given the natural aversion of
programmers to comments and documentation , this is very desirable .
In practice , code is rarely self-documenting and comments are needed. One

important part of the documentation is the relation scheme, which can be presented
before the clauses defining that relation , augmented with further explanations
if necessary. The explanations used in the book define the relation a
procedure computes . It is not always easy to come up with a precise , declarative ,
natural -language description of a relation computed by a logic program . However
, the inability to do so usually indicates that the programmer does not fully
understand his creation , even if his creation actually works . Hence we encourage
the use of the declarative documentation conventions adopted in the book . They
are a good means of communicating to others what a program defines , as well as
a discipline of thought , enabling a programmer to think about and reflect on his
own creation .
13 .4 Program development
Since programming in (pure ) Prolog is as close to writing specifications as

any practical programming language has gotten , one might expect pure Prolog
programs to be bug free . This , of course, is not the case. Even when axiomatizing
one's concepts and algorithms , a wide spectrum of bugs , quite similar to ones
found in conventional languages , can be encountered .
Stating it differently , for any formalism there are sufficiently complex problems
, for which there are no self-evidently correct formulations of solutions . The
13.4 Program development 201
difference between low -level and high -level languages , then , is only the threshold
after which simple examination of the program is insufficient to determine its
correctness .
There are two schools of thought on what to do on such an occasion . The

"verification " school suggests that such complex programs be verified , by proving
that they behave correctly with respect to an abstract specification . It is not
clear how to apply this approach to logic programs , as the distance between the
abstract specification and the program is much smaller then in other languages .
If the Prolog axiomatization is not self-evident , there is very little hope that the
specification , no matter in what language it is written , would be .
One might suggest to use full first -order logic as a specification formalism
for Prolog . It is the authors ' experience that very rarely a specification in full
first -order logic is shorter , simpler , or more readable then the simplest Prolog
program defining the relation .
Given this situation , there are weaker alternatives . One is to prove that one
Prolog program , perhaps more efficient though more complex , is equivalent to a
simpler Prolog program , which , though less efficient , could serve as a specification
for the first . Another is to prove that a program satisfies some constraint , such
as a "loop invariant ," which , though not guaranteeing the program 's correctness ,
increases our confidence in it .
In some sense, Prolog programs are executable specifications . The alternative

to staring at them , trying to convince ourselves that they are correct , is to
execute them , and see if they behave the way we want them to . This is the
standard testing and debugging activity , carried in program development in any
other programming language . All the classical methods , approach es, and common
wisdom concerning program testing and debugging apply equaly well to Prolog .
What is the difference , then , between program development in conventional ,
even symbolic languages and Prolog ?
One answer is that although Prolog programming is "just " programming ,

there is a factor of improvement in ease of expression and speed of debugging
compared to other lower -level formalisms - we hope the reader has already sensed
a glimpse of it .
Another aJlswer is that declarative programming clears your mind . Said less
dramatically , programming one's ideas in general , and programming in adeclarative
and high -levelia Jlguage in particular , clarifies one's thoughts aJld concepts .
For experienced Prolog programmers , Prolog is not just a formalism for "coding "
a computer , but also a formalism in which ideas Call be expressed aJld evaluated
-- a tool for thinking .
202 Pragmatics 13.4
A third answer is that the properties of the high -level formalism of logic may
eventually lead to a set of practical program development tools that is an order of
magnitude more powerful then what is known today . Examples of such tools are
automatic program transformers , partial -evaluators , type inference programs , and
algorithmic debuggers . The latter are addressed in Section 19.3, where program
diagnosis algorithms and their implementation in Prolog are described .
Unfortunately , practical Prolog programming environments incorporating
these novel ideas are not yet widely available . In the meantime , a simple tracer ,
such as explained in Section 19.1, is most of what one can expect . Nevertheless ,
large and sophisticated Prolog programs can be developed even using the current
Prolog environments , perhaps with greater ease than in other available languages .
The current tools and systems do not dictate or support a specific program
development methodology . However , as with other symbolic programming languages
, rapid prototyping is perhaps the most natural development strategy . In
this strategy , one has an evolving , usable prototype of the system in most stages
of the development . Development proceeds by either rewriting the prototype
program or extending it . Another alternative , or complementary , approach to
program development is "think top -down , implement bottom -up ." Although the
design of a system should be top -down and goal driven , its implementation proceeds
best if done bottom up . In bottom -up programming each piece of code
written can be debugged immediately . Global decisions , such as representation ,
can be tested in practice on small sections of the system , and cleaned up and
made more robust before most of the programming has been done . Also , experience
with one subsystem may lead to changes in design decisions regarding other
subsystems .
The size of the chunks of code that should be written and debugged as a whole
varys and grows as the experience of the programmer grows . Experienced Prolog
programmers can write programs consisting of several pages of code , knowing
that what is left after writing is done is mostly simple and mundane debugging .
Less experienced programmers might find it hard to grasp the functionality and
interaction of more then a few procedures at a time .
We would like to conclude this section with a few moralistic statements . For
every programming language , no matter how clean , elegant , and high level , one
can find programmers who will use it to write dirty , contorted , and unreadable
programs . Prolog is no exception . However , we feel that for most problems that
have an elegant solution , there is an elegant expression of their solution in Prolog .
It is a goal of the book to convey both this belief and the tools to realize it
in concrete cases, by showing that aesthetics and praticality are not necessarily
opposing or conflicting goals.
13.5 Background 203
13.5 Background
The practice of analyzing the complexity of Prolog programs is not as developed

as for programs in more conventional programming languages . We believe
this is due to historical and sociological reasons and does not have much to do
with inherent properties of Prolog programs .
There has been little agreement on Prolog benchmarks , other than that LIPS
is probably the best measure . One standard is to time Program 3.16a, naive
reverse, reversing a list . There are 496 reductions for a list with 30 elements .
Several collections of Prolog programming tricks are in the public domain .
The main one is the Prolog library on the Arpanet at Stanford , which principally
draws on utilities from Edinburgh .
Programming style evolves from experience and interaction with others . A
strong influence on the first author was the Prolog programming community at
the University of Edinburgh , in particular , the influences of Lawrence Byrd and
Richard O ' Keefe .
Leonardo Da Vinci , Study of a Woman's Hands folded over her
Breast. Silver point on pink prepared paper , heightened with white .
About 1478. Windsor Castle, Royal Library
Part III
Advanced Prolog P rogr a In Ining
Techniques
The expressive power and high -level nature of logic programming can be
exploited to write programs that are not easily expressed in conventional programming
languages . Different problem solving paradigms can be supported , and
alternative data construction and access mechanisms can be used.
The simple Prolog programs of the previous part are examples of the use
of basic programming techniques , reinterpreted in the context of logic programming
. This part collects more advanced techniques that have evolved in the logic
programming community and exploit the special features of logic programs . We
show how they can be used to advantage .
Chapter 14
Nondeterministic
Programming
An aspect of the logic programming computation model lacking inconventional

programming models is nondeterminism . Nondeterminism is a technical
concept used to define , in a concise way, abstract computation models . However ,
in addition to being a powerful theoretical concept , nondeterminism is also useful
for defining and implementing algorithms . This chapter shows how , by thinking
nondeterministic ally , one can construct concise and efficient programs .
Intuitively , a nondeterministic machine is a machine that can choose its next
operation correctly , when faced with several alternatives . True nondeterministic
machines cannot be realized but can be simulated , or approximated . Inparticular
, the Prolog interpreter approximates the nondeterministic behavior of the
abstract logic programs interpreter by sequential search and backtracking , as explained
in Chapter 6. However the fact that nondeterminism is only "simulated "
without being "really present " can be abstracted away in many cases, in favor of
nondeterministic thinking , in much the same way as pointer manipulation details
involved in unification can be abstracted away in favor of symbolic thinking .
14 . 1 Generate - and - test
Generate - and-test is a common technique in algorithm design and programming

. In generate -and-test one process, or routine , generates the set of candidate
solutions to the problem , and another process, or routine , tests the candidates ,
trying to find one, or all , of the candidates which actually solve the problem .
Typically , generate- and-test programs are easier to construct than programs
that compute the solution directly , but they are also less efficient . A standard
14.1 Generate - and-test 207
technique for optimizing generate and test programs is to try and "push " the tester
inside the generator , as "deep" as possible . Ultimately , the tester is completely
intertwined with the generator , and only correct solutions are generated to begin
with .
It is easy to write logic programs that , under the execution model of Prolog
, implement the generate - and-test technique . Such programs typically have a
conjunction of two goals, in which one acts as the generator and the other tests
whether the solution is acceptable , as in the following clause:
find (X ) +- generate(X ), test(X ).
This Prolog program would actually behave like a conventional , procedural ,

generate- and-test program. When called with find (X) 'I, generate(X) succeeds,
returning some X , with which test(X) is called. If the test goal fails, execution
backtracks to generate(X) , which generates the next element. This continues
iteratively until the tester successfully finds a solution with the distinguishing
property , or the generator is exhausted of alternative solutions .
The programmer , however , need not be concerned by the generate -and-test

cycle , and can view this technique more abstractly , as an instance of nondeterministic
programming . In this nondeterministic program the generator guesses
correctly an element in the domain of possible solutions , and the tester simply
verifies that the guess of the generator is correct .
A program with multiple solutions and commonly used as a generator is

Program 3.12 for member. The query member(X ,[a,b,c]) ? will yield the solutions
X = a, X = b, and X = c successively as required . Thus member can be used to
nondeterministic ally choose the correct element of a list in a generate- and-test i
program .
Program 14.1 is a simple example of generate -and-test using member as a

generator . The program identifies parts of speech of a sentence. We assume that
a sentence is represented as a list of words , and there is a database of facts giving
the parts of speech of particular words. Each part of speech is a unary predicate
whose argument is a word, for example, noun(man) indicates that man is a
noun. The relationship verb( Sentence, Word) is true if Word is a verb in sentence
Sentence.. The analogous meanings are intended for noun/ !:! and article/ 2. The
query verb([a,man,loves,a,woman], V) ? finds the verb V= lovesin the sentenceus-
ing generate -and-test . Words in the sentence are generated by member , and tested
to see if they are a verb .
Another simple example is testing whether two lists have an element in common
. Consider the predicate intersect(Xs, Ys), which is true if Xs and Ys have an
208 NondeterministicProgramming 14.1
verb(Sentence, Verb) +-
Verb is a verb in the list of words Sentence.
verb (Sentence,Word ) +- member (Word ,Sentence) , verb (Word ) .

noun (Sentence,Word ) +- member (Word ,Sentence) , noun (Word ) .
article (Sentence,Word ) +- member (Word ,Sentence) , article (Word ) .
Vocabulary
noun (man ) . noun (woman ) .

article (a) . verb (loves) .
Program 14 . 1: Finding parts of speech in a sentence
element in common :
intersect (Xs ,Ys ) +- member (X ,Xs ) , member (X ,Ys ) .
The first member goal in the body of the clause generates members of the
first list , which are then tested by the second member goal whether they are in
the second list . Thinking nondeterministic ally , the first goal guesses an X in Xs ,
while the second verifies that the guess is a member of Ys.
Note that when executed as a Prolog program , this clause effectively implements
two nested loops . The outer loop iterates over the elements of the first
list , and the inner loop checks whether the chosen element is a member of the
second list . Hence this nondeterministic logic program achieves, under the execution
model of Prolog , a behavior very similar to the standard solution one would
compose for this problem in Fortran , Pascal , or Lisp .
The definition of member in terms of append,
member (X ,Xs ) +- append (As ,[X IBs],Xs ) .
is itself essentially generate- and- test program . The two stages however are amalgamated
by the use of unification . The append goal generates splits of the list ,
and immediately a test is made whether the first element of the second list is X .
Let us consider optimizing generate - and-test programs by pushing the tester
into the generator . Program 14.2 for permutation sort is another example of a
generate and test program . The top level is as follows :
sort (Xs ,Ys ) +- permutation (Xs ,Ys ) , ordered (Ys ) .
Abstractly , this program guessesnondeterministic ally the correct permutation via

permutation (Xs , Ys) , and ordered checks that it is actually ordered .
Figure 14.1: A solutionto the 4 queensproblem
Operationally , the behavior is as follows . A query involving sort is reduced

to a query involving permutation and ordered. A failure - driven loop ensues. A
permutation of the list is generated by permutation and tested by ordered. If
the permuted list is not ordered , the execution backtracks to the permutation
goal which generates another permutation to be tested . Eventually an ordered
permutation is generated and the computation terminates .
Permutation sort is a highly inefficient sorting algorithm , requiring time exponential
in the size of the list to be sorted . Pushing the tester into the generator ,
however , leads to a reasonable algorithm . The generator for permutation sort ,
permutation , selects an arbitrary element and recursively permutes the rest of the
list . The tester , ordered, verifies that the first two elements of the permutation
are in order , then recursively checks the rest . If we view the combined recursive
permutation and ordered goals as a recursive sorting process , we have the basis
for insertion sort , Program 3.21. To sort a list , sort the tail of the list and insert
the head of the list into its correct place in the order . The arbitrary selection of
an element has been replaced by choosing the first element .
Another example of the advantage of intertwining generating and testing can

be seen with programs solving the N queens problem .
The Nqueens problem requires the placement of Npieces on an N-by-Nrect -

angular board so that no two pieces are on the same line : horizontal , vertical or
diagonal . The original formulation called for 8 queens to be placed on a chessboard
, and the criterion of not being on the same line corresponds to two queens
not attacking each other under the rules of chess. Hence the problem 's name .
The program has been well studied in the recreational mathematics literature .
There is no solution for N = 2 and N = 9, and a unique solution up to reflection for
N = 4 shown in Figure 14.1. There are 88 (or 92 depending on strictness with
symmetries ) solutions for N = 8.
Program 14.2 is a simplistic program solving the N queens problem . The re-
210 Nondeterministic Programming 14.1
queens(N, Queens) +-
Queens is a placement that solves the N queens problem ,
representedas a permutation of the list of numbers [1,2,. . .,N] .
queens(N,Qs) +-
range(liN ,Ns) , permutation (Ns,Qs) , safe(Qs).
safe(Qs) +-
The placement Qs is safe.
safe([Q\Qs]) +- safe(Qs) , not attack(Q,Qs).

safe([ ]).
attack (X ,Xs) +- attack(X ,l ,Xs).
attack (X ,N,[YIYs]) +- X := Y+ N ; X := Y- N.
attack (X ,N,[YIYs]) +- Nl := N+ l , attack (X ,Nl ,Ys).
permutation (Xs,Y s) +- SeeProgram 3.20
range(M ,NiNs) +- SeeProgram 8.12
Program 14 .2: Naive generate-and-test for the N queens p.roblem
lation queen(N, Qs) is true if Qs is a solution to the N queensproblem. Solutions

are specified as a permutation of the list of the numbers 1 to N . The first element
of the list is the row number to place the queen in the first column , the second
element indicates the row number to place the queen in the second column , etc .
Figure 14.1 indicates the solution [2,4,1,3] to the 4 queensproblem. This specification
of solutions, and the program generating them, has implicitly incorporated
the observation that any solution to the N queens problem will have a queen on
each row , and a queen on each column .
The program behaves as follows . The predicate range creates a list N s of the
numbers from 1 to N . Then a generate- and-test cycle begins . The permutation
predicate generates a permutation Qs of Ns , which is tested whether it is a solution
to the problem with the predicate safe( Qs). This predicate is true if Qsis a correct
placement of the queens. Since two queens are not placed on the same row or
column , the predicate need only check whether two queens attack each other
along a diagonal . Safe is defined recursively . A list of queens is safe if the queens
represented by the tail of the list are safe, and the queen represented by the head
of the list doesnot attack any of the other queens. The definition of attack(Q, Qs)
uses a neat encapsulation of the interaction of diagonals . A queen is on the same
diagonal as a second queen N columns away if the second queen's row number is
N units greater than , or N units less than , the first queen 's row number . This
14.1 Generate - and - test 211
queens( NJ Queens) +-
Queens is a placement that solves the N
queens problem , represented
as a permutation of the list of numbers [1,2,...1'11.
queens(N ,Qs) +-- range (liN ,Ns) , queens(Ns ,[ ],Qs) .

queens(Unplaced Qs,SafeQs,Qs) +-
select ( Q ,Unplaced Qs,Unplaced Qsl ) ,
not attack ( Q ,SafeQs) ,
queens (Unplaced Qsl , [Q ISafeQs] ,Qs) .
queens( [ ],Qs,Qs) .
select (X ,Xs ,Ys ) +- See Program 3.19.
attack (X ,Xs ) +- See Program 14.2.
Program 14 .3 : Placing one queen at a time
is expressed by the first clause of attack / 9 in Program 14.2. The meaning of

attack ( Q, Qs) is that queen Q attacks some queen in Qs. The diagonals are tested
iteratively until the end of the board is reached .
Program 14.2 cannot recognize when solutions are symmetric . The program
gives two solutions to the query queens(4, Qs) '1, namely Qs= [2,4,1,9] and
Qs= [9,1,4,2].
Although a well written logic program , Program 14.2 behaves inefficiently .
Many permutations are generated that have no chance of being solutions . As with
permutation sort , we improve the program by pushing the tester , in this case safe,
into the generator .
Instead of generating the complete permutation , that is , placing all the queens
and then testing it , each queen can be checked as it is being placed . Program
14.3 computes solutions to the N queens problem by placing the queens one at
a time . It also proceeds by generating and testing , in contrast to insertion sort ,
which became a deterministic algorithm by the transformation . The generator in
the program is select and the tester is attack , or more precisely its negation .
The positions of the previously placed queens are necessary to test whether
a new queen is safe. Therefore the final solution is built upward using an accumulator
. This is an application of the basic technique described in Section 7.5. A
consequence of using an accumulator is that the queens are placed on the righthand
edge of the board . The two solutions to the query queens(4' , Qs) are given
in the opposite order to Program 14.2.
color _map ( Map , Colors ) +-

Map is colored with Colors , so that no two neighbors have the same color .
The map is represented as an adjacency -list of regions
region (Name , Color ,Neighbors ) , where Name is the name of the region ,
Color is its color , and Neighbors are the colors of the neighbors .
The program can be used with all colors initially uninstantiated .
color - map( [Region IRegions ] ,Colors ) +-

color -region (Region ,Colors ) ,
color - map(Regions ,Colors ) .
color - map( [ ],Colors ) .
color_region (Region, Colors ) +-
Region and its neighbors are colored using Colors so that the
region 's color is different from the color of any of its neighbors .
color ..:region (region (N arne,Color ,Neighbors ) ,Colors ) +--

select (Color ,Colors ,Colorsl ) ,
members (Neighbors ,Colorsl ) .
select (X ,Xs ,Ys ) +- See Program 3.19.
members (Xs ,Y s) +- See Program 7.6.
Program 14 .4 : Map coloring
The next problem is to color a planar map so that no two adjoining regions
have the same color . A famous conjecture , an open question for a hundred years ,
was proved in 1976 showing that four colors are sufficient to color any planar map .
Figure 14.2 gives a simple map requiring four colors to be colored correctly . This
can be proved by enumeration of the possibilities . Hence four colors are both
necessary and sufficient .
Program 14.4 which solves the map -coloring problem also uses the generate -
and-test programming technique extensively . The program implements the following
nondeterministic iterative algorithm .
For each region of the map
choose a color ,
choose (or verify ) colors for the neighboring regions from the
remaining colors .
A data structure is needed to support the algorithm . The map is represented

as a list of regions . Each region has a name , a color , and a list of colors of the
Test data
test_color(Name,Map) +-
map(Name,Map),
colors ( Name , Colors ) ,
color - nlap ( Map , Colors ) .
map ( test , [ region ( a , A , [ B , C , D ] ) , region ( biB , [ A , C , E ] ) , region ( c , C , [ A , B , DE , F ] ) ,
regiond , D , [ A , C , F ] ) , region ( e , E , [ B , C , F ] ) , region ( f , F , [ C , DiE ] ) ] ) .
map ( west - europe , [ region ( portugal , P , [ E ] ) , region ( spain , E , [ F , P ] ) ,
region ( france , F , [ E , I , SiB , WG , L ] ) , region ( belgium , B , [ F , H , L , WG ] ) ,
region ( holland , H , [ B , WG ] ) , region ( west _ germany , WG , [ F , A , S , H , B , L ] ) ,
region ( luxembourg , L , [ F , B , WG ] ) , region ( italy , I , [ F , A , S ] ) ,
region ( switzerlandS , [ F , I , A , WG ] ) , region ( austria , A , [ I , S , WG ] ) ] ) .
colors ( X , [ red , yellow , blue , white ] ) .
Program 14 .5 : Test data for map coloring
b d
Figure 14 . 2 : A map requiring 4 colors
adjoining regions . The map in Figure 14 . 2 , for example , is represented as
[ region ( a , A , [ B , C , D ] ) , region ( biB , [ A , C , E ] ) , region ( c , C , [ A , BiDiE , F ] ) ,
regiond , D , [ A , C , F ] ) , region ( e , E , [ B , C , F ] ) , region ( f , F , [ C , DiE ] ) ] .
The sharing of variables is used to ensure that the same region is not colored with
two different colors by different iterations of the algorithm .
The top - level relation is color _ map ( Map , Colors ) where the Map is represented
as above , and Colors is a list of colors used to color the map . Our colors
are red , yellow , blue and white . The heart of the algorithm is the definition of
color _ region ( Region , Colors ) :
color - region ( region ( N arne , Color , Neighbors ) , Colors ) + -
select ( Color , Colors , Colorsl ) , rnembers ( Neighbors , Colorsl ) .
Both the select and members goals can act a . s generators or testers depending on
solve_puzzle(Puzzle,Solution ) +-
Solution is a solution of the Puzzle,
where Puzzle is puzzle( Clues, Queries ,Solution ) .
solve_puzzle (puzzle ( Clues ,Queries ,Solution ) ,Solution ) +-

solve ( Clues ) ,
solve ( Queries ) .
solve([ClueIClues]) +-
Clue, solve(Clues).
solve([ ]).
Program 14.6: A puzzlesolver
whether their arguments are instantiated .

Overall the effect of the program is to instantiate a data structure , the map .
The calls to select and members can be viewed as specifying loca:} constraints .
The predicates either generate , by instantiating arguments in the structure , or
test whether instantiated values satisfy local constraints .
Our final example is solving a logic puzzle . The behavior of the program
is similar to the map -coloring program . The logic puzzle consists of some facts
about some small number of objects that have various attributes . The minimum
number of facts is given about the objects and attributes , to yield a unique way
of assigning attributes to objects .
Here is an example that we will use to describe the technique of solving logic
puzzles .
Three friends came first , second and third in a programming competition .
Each of the three had a different first name , liked a different sport , and had a
different nationality .
Michael likes basketball , and did better than the American . Simon , the
Israeli , did better than the tennis player . The cricket player came first .
Who is the Australian ? What sport does Richard play ?
Logic puzzles such as the one above are elegantly solved by instantiating the
values of a suitable data structure , and extracting the solution values . Each clue is
translated into a fact about the data structure . This can be done before the exact
form of the data structure is determined using data abstraction . Let us analyze
the first clue : "Michael likes basketball , and did better than the American ."
Two distinct peopleare referredto. One is namedMichael and whosesport is
basketball, while the other is American. Further Michael did better than the
14.1 Generate -and-test 215
American . If we assume the structure to be instantiated is Friends , then the clue
is expressed as the conjunction of goals
did _ better ( Manl , Man2 , Friends ) , name ( Manl , michael ) ,
sport ( Manl , basketball ) , nationality ( Man2 , american ) ,
Similarly the second clue can be translated to the conditions
did _ better ( Manl , Man2 , Friends ) , name ( Manl , simon ) ,
nationality ( Manl , israeli ) , sport ( Man2 , tennis ) ,
and the third clue to the conditions
first ( Friends , Man ) , sport ( Man , cricket ) .
A framework for solving puzzles is given as Program 14 . 6 . The relation
computed is solve _ puzzle ( Puzzle , Solution ) , where Solution is the solution to Puzzle .
The puzzle is represented by the structure puzzle ( Clues , Queries , Solution ) , where
the data structure being instantiated is incorporated into the clues and queries ,
and the values to be extracted are given by Solution .
The code for solve - puzzle is trivial . All it does is successively solve each
clue and query , which are expressed as Prolog goals and are executed with the
metavariable facility .
The clues and queries for our example puzzle are given in Program
14 . 7 . We describe the structure assumed by the clues to solve the puzzle .
Each person has three attributes , and can be represented by the structure
friend ( Name , Country , Sport ) . There are three friends whose order in the programming
competition is significant . This suggests an ordered sequence of three
elements as the structure for the problem , i . e . the list
[ friend ( Nl , Cl , SI ) , friend ( N2 , C2 , S2 ) , friend ( N3 , C3 , S3 ) ] .
The programs defining the conditions did _ better , name , nationality , sport , and
first are straightforward , and are given in Program 14 . 7 .
The combination of Programs 14 . 6 and 14 . 7 works as a giant generate - and -
test . Each of the did - better and member goals access people , and the remaining
goals access attributes of the people . Whether they are generators or testers
depends on whether the arguments are instantiated or not . The answer to the
complete puzzle , for the curious , is that Michael is the Australian , and Richard
plays tennis .
Test data
test_puzzle(Name,puzzle(Clues,Queries,Solution)) +-
structure (Name,Structure),
clues(Name,Structure ,Clues),
queries(Name,Structure ,Queries,Solution).
structure (test, [friend (Nl ,Cl ,Sl ) ,friend (N2,C2,S2) ,friend (N3,C3,S3))).
clues(test,Friends,
[(did _better (Manl Cluel ,Man2Cluel ,Friends) , % Clue 1
name(Manl Cluel ,michael), sport (Manl Cluel ,basketball),
nationality (Man2Cluel ,american) ),
(did_better (Manl Clue2,Man2 Clue2,Friends), %Clue2
name(Manl Clue2,simon) , nationality (Man 1Clue2,israeli),
sport (Man2 Clue2,tennis) ),
(first (Friends,Man Clue3), sport (Man Clue3,cricket)) %Clue3
J).
queries ( test , Friends ,
[ member ( Ql , Friends ) ,
name ( Ql , Name ) ,
nationality ( Ql , australian ) , % Query 1

member ( Q2 , Friends ) ,
name ( Q2 , richard ) ,
sport ( Q2 , Sport ) % Query 2

],
[['The Australian is " Name],['Richard plays " Sport]]
).
did_better (A ,B ,[ A ,B ,C ] ) .
did_better (A ,C,[ A ,B ,C ] ) .
did_better (B ,C,[A ,B , C ] ) .
name ( friend ( A ,B , C ) ,A ) .
nationality ( friend ( A ,B , C ) ,B ) .
sport ( friend ( A ,B , C ) , C ) .
first ( [X I Xs ] ,X ) .
Program 14 .7 : A description of a puzzle

14.1 Generate -and- test 217
(i ) Write a program to compute the integer square root of a natural number

N defined to be the number 1 such that p. .$: N , but (1+ 1)2 > N . Use the
predicate between/ 3, Program 8.5, to generate successive natural numbers on
backtracking .
(ii ) Write a program to solve the stable marriage problem (Sedgewick , 1983)
stated as follows :
Suppose there are N men and N women who want to get married to each
other . Each man has a list of all the women in his preferred order , and each
woman likewise has a list of the men in preferred order . The problem IS to
find a set of marriages that is stable .
A set of marriages is unstable if two people who are not married both prefer
each other to their spouses. For example , suppose there are two men , A and
B , and two women , X and Y, such that A prefers X to Y, B prefersY to X ,
X prefers A to B , and Y prefers B to A . The pair of marriages A - Y and B - X
is unstable , since A prefers X to Y, while X prefers A to B .
Your program should have as input lists of preferences , and produce as output
a stable s'et of marriages , i .e., one that is not unstable . It is a theorem from
graph theory that this is always possible . Test the program on the following
5 men and 5 women with their associated preferences :
avraham : chana tamar zvia ruth sarah
binyamin : zvia chana ruth sarah tamar
chaim : chana ruth tamar sarah zvia
david : zvia ruth chana sarah tamar
elazar : tamar ruth chana zvia sarah
zvia : elazar avraham david binyamin chaim

chana : david elazar binyamin avraham chaim
ruth : avraham david binyamin chaim elazar
sarah : chaim binyamin david avraham elazar
tamar : david binyamin chaim elazar avraham
(iii ) Use Program 14.4 to color the map of Western Europe . The countries are
given in Program 14.5.
(iv ) Write a program to solve the following logic puzzle . There are five houses,
each of a different color and inhabited by a man of a different nationality ,
with a different pet , drink and brand of cigarettes .
1. The Englishman lives in the red house.

2. The. Spaniard owns the dog .

3. Coffee is drUnk in the green house.
4. The Ukrainian drinks tea .
5. The green house is immediately to the right (your right ) of the ivory
house .
6 . The Winston smoker owns snails .
7. Kools are smoked in the yellow house .
8. Milk is drunk in the middle house .
9 . The Norwegian lives in the first house on the left .
10 . Thp : m ~.n who ~mokeR Chesterfields lives in the house next to the man
with the fox .
11. Kools are smoked in the house next to the house where the horse is
kept .
12. The Lucky Strike smoker drinks orange juice .
13. The Japanese smokes Parliaments .
14. The Norwegian lives next to the blue house.
Who owns the Zebra ? Who drinks water ?
(v ) Write a program to test whether a graph is planar using the algorithm of

Hopcroft and Tarian (Deo, 1974; Even, 1979).
14 . 2 Don ' t - care and don ' t - know nondeterminism
Two forms of nondeterminism are distinguished in the logic programming

literature . They differ in the nature of the choice among alternatives that must
be made . For don't- care nondeterminism , the choice can be made arbitrarily . In
terms of the logic programming computation model , any goal reduction will lead
to a solution , and it does not matter which particular solution is found . For
don 't - know nondeterminism , the choice matters but the correct one is not known
at the time the choice is made .
Most examples of don 't -care nondeterminism are not relevant for the Prolog
programmer . A prototypical example is the code for minimum . Program 3.7
is the standard , incorporating a limited amount of don 't -care nondeterminism ,
namely when X and Yare the same:
minimum (X ,Y ,X ) -+- X ::::;: Y .

minimum (X ,Y ,Y ) -+- Y ::::;: X .
In Section 7.4, we termed this redundancy and advised against its use.
14.2 Don 't -care and don 't -know nondeterminism 219
b
y z
u v
Figure 14.3: Directed graphs
On the other hand , programs exhibiting don 't - know Il;<?ndeterminism are common
. Consider the program for testing whether two binary trees are isomorphic
(Program 3.25 reproduced below). Each clauseis independently correct, but given
two isomorphic binary trees , we dorr' t know which of the two recursive clauses
should be used to prove the isomorphism . Operationally , only when the computation
terminates successfully do we know the correct choice :
isotree(void,void).
isotree(tree(X ,Ll ,Rl ),tree(X ,L2,R2)) ~ isotree(Ll ,Rl ), isotree(L2,R2).
isotree(tree(X ,Ll ,Rl ),tree(X ,L2 ,R2)) +- isotree(Ll ,R2), isotree(L2,Rl ).
Composing Prolog programs exhibiting either form of nondeterminism can be

indistinguishable from composing deterministic programs . Each clause is written
independently . Whether inputs match only one clause or several is irrelevant to
the programmer . Indeed this is seen from the multiple uses that can be made of
Prolog programs . With one form of arguments the program is deterministic , in
another nondeterministic , for example , append.
The behavior of Prolog programs seemingly having don 't -know nondeterminism
such as isotree is known . A given logic program and a query determine
a search tree as discussed in Chapter 5, which is searched depth first by Prolog .
Writing a program possessing don 't -know nondeterminism is really specifying a
depth first "Search algorithm for solving the problem .
We consider this viewpoint in a little more detail with a particular example :
finding whether two nodes in a graph are connected . Figure 14.3 contains two
graphs that will be used to test our ideas . The left -hand one is a tree , while
the right -hand one is not , containing a cycle . Trees, or more generally directed
connected(X, Y) +-
N ode X is connected to node Y,
given an edge / 2 relation describing a DAG .
connected(A ,A ).
connected(A ,B) +- edge(A ,N), connected(NiB ).
Data
edge(a,b). edge(a,c). edge(aid). edge(aie). edge{dJ ).

edge(c,f ). edge(c,g). edge(f,h). edge(e,k) . edge(f,i ).
edge(x ,y). edge(y,z) . edge(z,x ). edge(y,u). edge(z,v).
Program 14.8: Connectivity in a finite DAG
path(X, Y,Path) +-
Path lH a nath
~ between two nodes X and Y
in the DAG defined by the relation edge / f .
path ( X ,X , [X ] ) .
path ( X , Y , [XIP ]) +- edge ( X ,N ) , path ( N , Y ,F ) .
Program 14 . 9 : Finding a path by depth - first search
connected ( X , Y) +-
Node X is connected to node Y in the graph defined by edge / 2 .
connected ( X ,Y ) + - connectd ( X , Y , [X ] ) .
connected ( A ,A , Visited ).
connected ( A , B , Visited ) +-
edge ( A ,N ) , not member ( N ,Visited ) , connected ( NiB , [N IVisited ]).
Program 14 . 10 : Connectivity in a graph
acyclic graphs ( DAGs ) , behave better than graphs with cycles as we will see in
our example programs .
Our first program is a small modification of a logic program of Section 2 .3 .
Program 14 .8 defines the relation connected ( X , Y) which is true if two nodes in a

graph , X and Y , are connected . Edges are directed ; the fact edge ( X , Y) stating
that a directed edge exists from X to Y . Declaratively the program is a concise ,
recursive specification of what it means for nodes in a graph to be connected .
Interpreted operationally as a Prolog program , it is the implementation of an

algorithm to find whether two nodes are connected using depth - first search .
14.2 Don 't -care and don 't - know nondeterminism 221
The solutions to the query connected(a,X) using the data from the left-hand
graph in Figure 14.3 gives the solutions b, c, / , h, i , g, d, j , e, k. Their order
constitutes a depth -first traversal of the tree .
Program 14.9 is an extension of this simple program that finds a path between
two nodes. The predicate pdlh(X , Y,Path) is true if Path is a path from the node
X to the node Y in a graph . Both endpoints are included in the path : The path
is built downward , which fits well with the recursive specification of the connected
relation . The ease of computing the path is a direct consequence of the depth -
first traversal . The equivalent extension of a breadth first traversal is much more
difficult , to be discussed in Sections 17 .2 and 18 . 1 .
Depth-first search, dfs, correctly traverses any finite tree or DAG (directed
acyclic graph). There is a problem, however, with traversing a graph with cycles.
The computation can becomelost iii an infinite loop (literally !) around one of the
cycles. For example, the query connected(x,Node) ?, referring to the right -hand
graph of Figure 14.3 gives the solutiony , z, and x repeatedly without reaching u
or v .
The problem is overcome by modifying connected. An extra argument is

added that accumulates the nodes visited so far . A test is made to avoid visiting
the same state twice . This is shown in Program 14.10.
Program 14.10 successfully traverses a finite directed graph depth first . The
pure Prolog program needed for searching finiteD A Gs must be extended by negation
in order to work correctly . Adding an accumulator of paths visited to avoid
entering loops effectively breaks the cycles i ~ the graph by preventing traversal
of an edge which would complete a cycle .
The program is not guaranteed to reach every node of an infinite graph . To
do so , breadth - first search is necessary . This is discussed further in Section 17 .2 .
The section is completed with a program for building simple plans in the
blocks world . The program is written nondeterministic ally , essentially performing
a depth -first search. It combines the two extensions given above - keeping an
accumulator of what has been traversed , and computing a path .
The problem is to form a plan in the blocks world , that is , to specify a
sequence of actions for restacking blocks to achieve a particular configuration .
Figure 14.4 gives the initial state and the desired final state of a blocks world
problem . There are three blocks , a,b, and c, and three places , p, q, and r . The
actions allowed are moving a block from the top of a block to a place and moving
a block from one block to another . For the action to succeed , the top of the moved
block must be clear , and also the place or block to which it is being moved .
The top level procedure of Program 14.11, that solves the problem , is trans -
transform ( Statel , State ! : !, Plan ) + -
The Plan of actions transforms Statel into State ! : !.
transform ( Statel , State2 , Plan ) + -
transform ( Statel , State2 , [ Statel ] , Plan ) .
transform ( State , State , Visited , [ ] ) .
transform ( Statel , State2 , Visited , [ Action I Actions ] ) + -
legal - action ( Action , Statel ) ,
update ( Action , Statel , State ) ,
not member ( State , Visited ) ,
transform ( State , State2 , [ State I Visited ] , Actions ) .
legal _ action ( to _ place ( Block ,Y , Place ) , State ) +- -
on ( Block ,Y , State ) , clear ( Block , State ) , place ( Place ) , clear ( Place , State ) .
legal _ action ( to _ block ( BlocklY , Block2 ) , State ) +- -
on ( BlocklY , State ) , clear ( Blockl , State ) , block ( Block2 ) ,
Blockl Block2 , clear ( Block2 , State ) . '
clear (X , State ) + - not member ( on ( A ,X ) , State ) .
on (X ,Y , State ) + - member ( on (X ,Y ) , State ) .
update ( to _ block (X ,Y , Z ) , State , Statel ) ~
substitute ( on (X ,Y ) , on ( X , Z ) , State , Statel ) .
update ( to _ place (X ,Y , Z ) , State , Statel ) ~
substitute ( on (X ,Y ) , on (X , Z ) , State , Statel ) .
substitute (X ,Y , Xs , Ys ) + - See Exercise 3 .3 (i )
Program 14 . 11 : A depth - first planner
Testing and data
test _plan (Name ,Plan ) +-

initial ..state(Name,I), final..state(Name,F), transform(I ,F ,Plan).
initial -state (test ,(on ( a,b) ,on (b ,p ) ,on ( c,r )]) .
final -state (test ,(on (a,b ) ,on (b ,c) ,on (c,r )]) .
block ( a) . block (b ) . block (c) .
place (p) . place (q) . place (r ) .
Program 14 . 12 : Testing the depth -first planner
14.2 Don 't -care and don 't - know nondeterminism 223
__ffi______EJ
p
- q r p q r
Figure 14.4: Initial and final states of a blocks world problem
jorm (Statel ,State2,Plan). A plan of actions, Plan, is produced which transforms

..c;'tatel into State2.
States are represented by a list of relations of the form on(X , Y) where X
is a block and Y is a block or place. They represent the facts that are true in
the state. For example, the initial and final states in Figure 14.5 are, respec-
tively , (on(a,b),on(b,p),on(c,r)) and (on(a,b),on(b,c),on(c,r)). The on relation for
a precedesthat of b, which precedesthe on relation for c. The state descriptions
allow easy testing whether a block or place X is clear in a given state by checking
that there is no relation of the form on(A ,X) . The predicates clear/ 2 and on/ 3 in
Program 14.11 take advantage of this representation.
The nondeterministic algorithm used by the planner is given by the recursive
clause of trans/ orm/ .4 in the program:
while the desired state is not reached,
find a legal action,
update the curre:tit state,
check that it has not been visited before.
There are two possible actions , moving to a block and moving to a place . For
each, the conditions for which it is legal must be specified , and how to update it .
Program 14.11 successfully solves the simple problem given as Program 14.12.
The first plan it produces is horrendous , however , being
[to _place ( a,b ,q) ,to _block ( a,q,c) ,to _place (b ,p ,q) ,to _place ( a,c,p) ,
to _block ( a,p ,b ) ,to _place (c,rip ) ,to _place ( a,b ,r ) ,to _block (a,r ,c) ,
to _place (b ,q,r ) ,to _place ( a,c,q) ,to _block ( a,q,b) ,to _place ( c,p ,q) ,
to _place ( a,b ,p ) ,to _block (a,pic ) ,to _place (b ,rip ) ,to _place ( a,c,r ) ,
to _block (b ,p ,a) ,to -place ( c ,q,p ) ,to _block (b ,a,c) ,to _place ( a,r ,q) ,
to _block(b,c,a),to _place(c,p,r ) ,to_block(b,a,c) ,to _place(a,q,p),

to _block(a,p,b)]. l
Block a is first moved to q, then to c . After that block b is moved to q, block a

is moved to p and b, and after 20 more random moves, the final configuration is
reached .
It is easy to incorporate a little more intelligence by first trying to achieve

one of the goal states. The predicate legal_action can be replaced by apredicate
choose_action(Action ,State1,State ) where the action is chosen. A simple
definition suffices to produce intelligent behavior in our example problem :
choose-action (Action ,Statel ,State2) +-

suggest(Action ,State2), legal_action (Action ,Statel ).
choose_action(Action ,State1,State2) +-
legal_action(Action ,Statel ).
suggest(to _place(X ,Y ,Z) ,State) +-
member(on(X ,Z) ,State) , place(Z) .
suggest(to_block (X ,Y ,Z) ,State) +-
member(on(X ,Z),State), block(Z).
The first plan now produced is [to_place( a, b, q), to_block( b,p, c), to-block( a, q, b)].
14 .3 Simulating nondeterministic computation models
In this section we present simple programs simulating some basic computation

models . Interpreters for the various classes of automata are very easily
written in Prolog .
The simulation programs are a good application of a nondeterministic programming
. Th .e operation of a nondeterministic automaton well illustrates don 't -
know nondeterminism . It is interesting that nondeterministic automata are as
easily simulated as deterministic ones due to the nondeterminism of Prolog .
We begin with a (nondeterministic) finite automaton, abbreviated NDFA . An
NDFA , is defined as a 5-tuple (Q,S,D,I ,Fj where Q is the set of statesS is the
set of symbols , D is a mapping from Q x S to Q, I is the initial state , and F the
set of final states . If the mapping is a function , then the NDFA is deterministic .
In Prolog a finite automaton can be specified by three collections of facts :
initial (Q), which is true if Q is the initial state, final ( Q), which is true if Q is a
final state, and delta( Q,A, Q1), which is true if the NDFA changesfrom state Q
14.3 Simulating nondeterministic computation models 225
acceptS ) +-
The string representedby the list S is accepted by
the NDFA defined by initial / l , delta/ 9, and final / l .
acceptS ) +- initial (Q), accept(Q,S).
accept(Q,(X IXs]) +- delta(Q,X ,Ql ) , accept(Ql ,Xs).
accept(Q,( ]) +- final (Q).
Program 14.13: An interpreter for a nondeterministic finite
automaton
initial (qO).
final(qO).
delta(qO,a,q 1).
delta(ql ,b,qO).
Program 14.14: An NDFA that acceptsthe language (ab).
~;J==: ~~~~~~
b
Figure 14.5: A simple automaton
to state Ql on receipt of symbol A . The set of states and symbols are defined
implicitly as the constants that appear in the predicates .
Program 14.13 is an abstract interpreter for an NDFA . The basic predicate is
acceptS ) which is true if the stringS , represented as a list of symbols , is accepted
by the NDFA .
In order to use the interpreter to simulate the behavior of a particular finite
automaton , the automaton must be specified . That entails defining its initial
state , its final state , and the transition relation delta. Program 14.14 gives the
definitions for an NDF A which accepts the language ( ab) . . There are two states ,
qO and ql . If in state qO an a is read , the automaton moves to state ql , while the
transformation from ql to qO happens if a b is read . The automaton is pictured
in Figure 14.5.
acceptS ) +-
The string represented by the list S is accepted by
the NPDA defined by initial / l , delta / 5 , and final / l .
dccept (Xs ) + - initial ( Q ) , accept ( Q ,Xs , [ ] ) .
accept ( Q , [ x IXs ) ,S ) ~ delta ( Q ,X ,S ,Ql ,Sl ) , accept ( Ql ,Xs ,Sl ) .

accept (Q ,[ ] ,[ ]) ~ final ( Q ) .
Program 14 . 15 : A push - down automaton interpreter
initial ( qO ) . final ( q 1 ) .
delta ( qO ,X ,S ,qO , [XIS ] ) .

delta ( qO ,X ,S ,ql , [XIS ] ) .
delta ( qO ,X ,S ,ql ,S ) .
delta ( ql ,X , [XIS ] ,ql ,S ) .
Program 14 . 16 : NPDA for palindromes over a finite alphabet
Another basic computation model is a pushdown automaton , which accepts

the class of context - free languages . It extends the model of an NDFA by allowing
a single stack for memory in addition to the internal state of the automaton .
Formally a (nondeterministic ) pushdown automaton , abbreviated NPDA , is a 7 -
tuple ( Q , S , G , D , I , Z , Fj where Q , S , I , F are as before , G is the list of symbols that
can be pushed on the stack , Z is the start symbol on the stack , and D , the delta
function , is changed to take account of the stack and current symbol , as well as
the internal state .
The operation of an NPDA , defined by the delta function , is determined by

the state , the first element in the input string , and the element on the top of the
stack . In one operation the NPDA can pop or push one stack element .
An abstract interpreter for an NPDA is very similar to Program 14 . 13 simulating

an NDFA , and is given as Program 14 . 15 . As before , to simulate a particular
automaton , the predicates determining the initial and final states of the automaton
need be given . The sets of symbols are defined implicitly . Program 14 . 15
a. ssumes that the stack is initially empty . The change relation delta ( Q , A , 8 , Ql , 81 )
is slightly different from before . It is true if in state Q on input symbol A and
stack state 8 the NPDA enters state Q1 and produces the stack state 81 .
A particular example of an NPDA is given as Program 14 . 16 . This automaton

accepts palindromes over a finite alphabet . A palindrome is a non - empty
string that reads the same forward or backward , for example , abba or abaabaaba .
14.3 Simulating nondeterministic computation models 227
palindrome (Xs ) +-
The string representedby the list Xs is a palindrome.
palindrome(Xs) +- palindrome(qO,Xs,[ I).
palindrome(qO,[X IXs],S) +- palindrome(qO,Xs,[XIS]).
palindrome(qo,[X IXs],S) +- palindrome(ql ,[X IXs],S).
palindrome(qO,[X IXs],S) +- palindrome(ql ,Xs,S).
palindrome(ql ,[X IXs],[XIS]) +- palindrome(ql ,Xs,S).
palindrome(ql ,[ ],[ ]).
Program 14.17: A programacceptingpalindromes
The automaton has two states : qO, when symbols are pushed onto the stack , and
ql , when symbols are popped from the stack and compared with the symbols on
the input stream . When to stop pushing and start popping is decided nondeter -
ministically - . There are two delta facts that change the state from qOto ql to allow
for palindromes of both odd and even length .
The combination of the intervreter v Ius automaton can be exvressed in a
single program . Program 14 . 17 is an amalgamation of Programs 14 . 15 and 14 . 16 .
It defines the relation palindrome ( Xs ) which determines whether a string Xs is a

palindrome .
The amalgamation of Programs 14 . 15 and 14 . 16 is transformed to Program
14 . 17 by the technique of unfolding . Unfolding is a useful strategy for program

transformation , which is utilized in other places in the book . We digress briefly
to define it .
Consider a goal Ai in a clause H +- Al , . . . , An and a clause C = (A +-
Bl , . . . Bm ) where Ai and A unify with mgu o. Unfolding Ai with respect to

its definition C produces the clause (H +- Al , . . . , Ai - l , Bl , . . . , Bm , Ai + l , . . . , An ) O.
This definition is analogous to the definition of u . nfolding in functional programming
languages .
For example , unfolding the initial ( Q ) goal in the clause
accept (X ) ~ initial ( Q ) , accept ( Q ,X , ( ] ) .
using its definition initial ( qO ) produces the clause
accept (X ) ~ accept ( qO ,X , [ ] ) .
If the definition of a goal has several clauses , then the unfolding produces several
clauses , one for each in the definition . For example , unfolding the delta goal in
the clause
accept(Q,[X IXs],S) +- delta(Q,X ,S,Ql ,Sl ), accept(Ql ,Xs,Sl ).
using the definition of delta in Program 14.16 produces four clauses.

The derivation of Program 14.17 is now manifest. It results from unfolding
the initial goal and the delta goal in the first two clauses, respectively, of Program
14.15, as described, and unfolding the final goal in the remaining clause. Finally ,
the predicate accepthas been renamed to palindrome.
It is easy to build an interpreter for a Turing machine in a similar style to
the interpreters in Programs 14.3 and 14.5. Doing this demonstrates incidentally
that Prolog has the power of a .Turing machine and hence of all other known
computation models.
(i ) Define an NPDA that accepts the langUage n a's followed by n b's.
14.4 AI classics: ANALOGY , ELIZA , and McSAM

"The best way to learn a subject is to teach it " is a cliche commonly repeated
to new teachers . An appropriate analogue for new programmers is that the best
way to understand a program is torewrite or extend it . In this spirit , we present
logical reconstructions of three AI programs . Each is clearly understandable , and
easily extended . The exercises at the end of the section encourage the reader to
add new facts and rules to the programs .
The three programs chosen are the ANALOGY program of Evans for solving
geometric analogy questions from intelligence tests ; the ELIZA program of
Weizenbaum which simulates or , rather , parodies conversation , and McSAM , a
micro -version of SAM , a program for "understanding " stories from the Yale language
group . Each of the logical reconstructions are expressed very simply . The
nondeterminism of Prolog allows the programmer to ignore the issues of search.
Consider the task of solving the geometric analogy problems typically used in
intelligence tests . Several figures are presented in a prototypical problem . Figures
A , B and G are singled out from a list of possible answers and the following
question is posed : "A is to B as G is to which one of the ' answer ' figures ?" Figure
14.7 gives a simple problem of this type .
14.4 AI classics: ANALOGY , ELIZA , and McSAM 229
is to L
A B c
I 2
63
Figure 14.6: A geometric analogy problem
Here is an intuitive algorithm for solving the problem , where terms such as
find , apply and rule are left unspecified :
find a rule that relates A to B ,
apply the rule to C to give a figure X ,
find X , or its nearest equivalent , among the answers.
In the problem in Figure 14.6, the positions of the square and triangle are swapped
(with appropriate scaling ) between Figures A and B . The "obvious " answer is to
swap the square and the circle in Figure C. The resultant figure appears as No .
2 in the possible answers.
Program 14.18 is a simple program for solving analogy problems . The basic
relation is analogy(Pairl ,Pair2 ,Answers ) , where each Pair is of the form X is_to
Y. To parse the program , is_to must be declared as an infix operator . The two
elements in Pair1 bear the same relationship as the two elements in Pair2 , and the
second element in Pair2 appears in Answers . The definition of analogy implements
the intuitive algorithm :
analogy (A is-to B ,C is_to X ,Answers ) +-

match (A ,BiOperation ) , match (C ,X ,Operation ) , member (X ,Answers ) .
analogy ( Pairl , Pair2 , Answers ) + -
An analogy holds between the two pairs of figures Pairl and Pair2 .
The second element of Pair2 is one of the possible Answers .
analogy(A is_to B ,C is_to X ,Answers) +-

match(A ,BiRule),
match(C,X ,Rule),
member(X ,Answers) .
match ( inside ( Figure1 , Figure2 ) , inside ( Figure2 , Figure1 ) , invert ) .
match ( above ( Figure1 , Figure2 ) , above ( Figure2 , Figure1 ) , invert ) .
Program 14 . 18 : A program solving geometricanalogies
Testing and data
test -aIlalogy (Name ,X ) +-

figures (Name ,A ,B ,C) ,
answers ( Name , Answers ) ,
analogy ( A is _ to B , Cis _ to X , Answers ) .
figures ( test1 , inside ( square , triangle ) , inside ( triangle , square ) ,
inside ( circle , square ) ) .
answers ( test1 , [ inside ( circle , triangle ) , inside ( square , circle ) ,
inside ( triangle , square ) ] ) .
Program 14 . 19 : Analogy test data
A fundamental decision is how the figures in the problem should be represented .
The " intelligence " of the program is greatly affected by this decision . In Program
14 . 18 , figures are represented a . s Prolog terms . Figure A in the diagram
in Figure 14 . 6 is a square inside a triangle , and is represented a . s the term inside
( square , triangle ) .
The relationship between two figures is found by the predicate match ( A , B ,
Operation ) . This relation is true if Operation matches A and B . The operation
invert is used to solve our example problem . The behavior of invert is to swap its
arguments .
The predicate match is used in two distinct ways in this program . The first
time it produces an operation matching two given figures . The second time it
produces a second figure given an operation and a figure . These details are ,
however , irrelevant from the nondeterministic viewpoint . Finally , the predicate
find is implemented simply , checking whether a given figure appears in the list of
14.4 AI classics
: ANALOGY, ELIZA, and McSAM 231
I am unhappy .
How long have you been unhappy .
Six months . Can you help me .
~ What makes you think I help you .
You remind me of my father and brother .
Can you tell me more about father .
I like teasing father .
Does anyone else in your family like teasing father .
No , only me .
Please go on .
Figure 14 .7: Sample conversation with ELIZA
answers .
The next AI classic considered is a simplified version of ELIZA . The program
aims to simulate a conversation . A user types in a sentence , and ELIZA responds
with an appropriate question or comment . ELIZA does not understand in any
real sense , responding to its input by recognizing word patterns and replying by
using a corresponding response pattern . To make the patterns of responses more
credible , it adopted a psychiatrist setting as its domain . A sample interaction
with ELIZA is given in Figure 14 .7 . Computer responses are preceded by .
The heart of ELIZA is a procedure for matching the input sentence against
a pattern . The resulting match is applied to another pattern to determine the
program reply . The pair of patterns can be considered as a stimulus / response
pair , where the input is matched against the stimulus , and the output generated
from the response . A typical stimulus / response pair is
I am ( statement ) How long have you been ( statement ) ?
Using this pair , the response of the program to the input statement " I am unhappy
" will be the question " How long have you been unhappy ? " The ( statement )
can be viewed as a slot to be filled .
Program 14 . 20 is a simple version of ELIZA . It implements the following
algorithm :
read the input .
while the input is not bye ,
choose a stimulus / response pair ,
match the input to the stimulus ,
generate the reply from the response and the above match ,
output the response ,
read the next input .

eliza +-
Simulates a conversation via side-effects.
eliza +- read _word -list (Input ) , eliza (Input ) , !.

eliza ([bye]) +-
writeln ( ['Goodbye . I hope I have helped you ']) .
eliza (Input ) +-
pattern (Stimulus,Response),
match (Stimulus,Dictionary ,Input ) ,
match (Response,Dictionary ,Output ),
reply (Output ),
read_word-list (Input 1) ,
!, ~liza (Inputl ).
match(Pattern,Dictionary , Words) +-
Pattern matches the list of words Words, and matchings are
recorded in the Dictionary .
match([N IPattern ] ,Dictionary ,Target) +-
integer(N), lookup (N ,Dictionary ,Left Target),
append(Left Target,Right Target,Target),
match(Pattern ,Dictionary ,Right Target).
match([Word IPattern] ,Dictionary ,[Word ITarget]) +-
atom (Word), match (Pattern ,Dictionary ,Target).
match([ ],Dictionary ,[ ]) .
lookup(Key,Dictionary ,Value) +- SeeProgram 15.8
pattern(Stimulus,Response)~
Responseis an applicable responsepattern to the pattern Stimulus.
pattern ([i ,amil ] ,[how,long,have,you,been,l ,?]).
pattern ([1,you,2,me] ,[what ,makes,you,think ,i ,2,you,?]).
pattern ([i ,like,l ] ,[does,anyone,else,in ,your ,family,like,l ,?]).
pattern ([i ,feel,l ],[do,you,often,feel,that ,way,?]) .
pattern ([1,X ,2],(can,you,tell ,me,more,about,X]) +- important (X ).
Pattern((1] ,[please,go,on]).
important (father). important (mother). important (son).
important (sister). important (brother ) . important (daughter).
reply ([HeadITail]) +- write (Head), write (' '), reply (Tail ).
reply ([ ]) +- nl .
read_word Jist (Xs) +- SeeProgram 12.2
Program 14.20: ELIZA
14.4 AI classics
The stimulus/ response pairs are represented as facts of the form pattern
(Stimulus,Response ) where both Stimulus and Responseare lists of words
and slots . Slots in the patterns are represented by integers . The predicate
match(Pattern, Table, Words) is used for both the second and third steps of the
above algorithm . It express es a relationship between a pattern Pattern , a list
of words Words and a table Table where the table records how the slots in the
pattern are filled . A central part of the match procedure is played by a nondeterministic
use of append to break up a list of words . The table is represented by
an incomplete data structure , a topic to be discussed in more detail in the next
chapter. The missing procedure lookup/ 3 will be given in Section 15.3. The reply
is generated by reply( Words) which is a modified version of writeln that leaves
spaces between words .
The final program presented in this section is Micro SAM or McSAM . It is

a simplified version of the SAM (Script Applier Mechanism) program developed
in the natural language group at Yale University . The aim of McSAM is to
"understand " stories . Given a story , it finds a relevant script and matches the
individual events of the story against the patterns in the script . In the process,
events in the script not explicitly mentioned in the story are filled in .
Both the story and the script are represented in terms of Schank 's theory
of conceptual dependency . For example , consider the input story in Figure 14.8
which is used as an example in our version of McSAM . The English version
"John went to Leones , ate a hamburger and left "
is represented in the program as a list of lists :
[ [ptrans , john , john , Xl , leones],

[ingest, X2 , hamburger, X3],
[ptrans , Actor , Actor , X4 , X5] ].
The first element in each list , ptrans and ingest , for example , is a term from
conceptual dependency theory . The representation of the story as a list of lists is
chosen as a tribute to the original Lisp version .
Programming McSAM in Prolog is a triviality as demonstrated by Program
14.21. The top-level relation is mcsam(Story,Script) which expands a Story into
its "understood " equivalent according to a relevant Script . The script is found
by the predicate find (Story,Script,Defaults). The story is searched for a nonvariable
argument that triggers the name of a script . In our example of John
visiting Leones , the atom leones triggers the restaurant script , indicated by the
fact trigger( leones,restaurant) in Program 14.22.
The matching of the story to the script is done by match(Script, Story) which
mcsam( Story, Script) +-

Script describes Story .
mcsam(Story,Script) +-
find (Story,Script ,Defaults),
match(Script,Story),
name_defaults(Defaults) .
find (Story,Script ,Defaults) +-
filler (Slot,Story),
trigger (Slot,Name),
script (Name,Script ,Defaults).
match(Script,Story) +-
Story is a subsequence of Script .
match(Script ,[ ]).
match ( [Line IScript],[Line IStory]) +- match (Script ,Story ) .
match([Line IScript],Story) +- match(Script,Story) .
filler (Slot, Story) +-
Slot is a word in the Story .
filler (Slot,Story) +-
member([Action IArgs] ,Story),
member(Slot,Args) .
name_defaults(Defaults) +-
Unifies default pairs in Defaults .
name-defaults(( ]).
name_defaults([-[N,N]IL]) +- name _defaults
(L).
name_defaults([[Nl,N2 ]IL]) +- Nl # N2,name _defaults
(L).
Program 14 .21 : McSAM
associates lines in the story with lines in the script . Remaining slots in the script
are filled in by name_defaults ( Defaults ) . The "output " is
[ptrans John John ,placel ,leones]

[ptrans J ohnJ ohn ,door ,seat]
[mtrans John ,waiter ,hamburger ]
[ingest John ,hamburger , [mouth ,john ]]
[atrans John ,check John ,waiter ]
[ptrans J ohnJ ohn ,leones,place2 ].
14.4 AI classics
Testing and data
test -nlcsarn (N arne,Understood Story ) +-

story (Name ,Story ) , rncsam (Story ,Understood Story ) .
story (test,[[ptr anf I, john , john , Xl , leones],
[ingest, X2 , hamburger, X3],
[ptrans , Actor , Actor , X4 , X5] ]).
script (restaurant ,
[ [ptrans , Actor , Actor , Earlier _place , Restaurant ],
[ptrans , Actor , Actor , Door , Seat],
[mtrans , Actor , Waiter , Food ],
[ingest , Actor , Food , [mouth , Actor ] ],
[atrans , Actor , Money , Actor , Waiter ],
[ptrans , Actor , Actor , Restaurant , Gone] ],
[ [Actor , customer ], [Earlier _place , place ! ],
[Restaurant , restaurant ], [Door , door ],
[Seat, seat], [Food , meal ], [Waiter , waiter ],
[Money , check], [Gone , place2] ] ) .
trigger (leones, restaurant ) .
trigger (waiter , restaurant ) .
Program 14 .22 : Test data for McSAM
Its translation to English is given in Figure 14.8.

The work done in the original McSAM was all in the searching and pattern
matching . This is accomplished in Prolog by nondeterministic programming and
unification .
Exercises . for Secti D: . 14 .4
,..
(i ) Extend ANALOGY , Program 14 . 18 , to solve the three problems in Figure

14 . 9 .
( ii ) Extend ELIZA , Program 14 . 20 , by adding new stimulus / response patterns .
( iii ) If the seventh statement in Figure 14 . 7 is changed to be " I like teasing my
father ," ELIZA responds with " Does anyone else in your family like teasing
my father ." Modify Program 14 . 20 to " fix " this behavior , changing references
such as I , my , to you , your , etc .
( iv ) Rewrite McSAM to use structures .

236 Non
determini ~;tic Programming 14.5
Input : John went to Leones , ate a hamburger and left .
Output : John went to Leones . He was shown from the door to a seat .
A waiter brought John a hamburger , which John ate by mouth .
The waiter brought John a check , and John left Leones for
another place .
Figure 14 . 8 : A story filled in by McSAM
14 . 5 Background
Several researchers have discussed the behavior of Prolog in solving the N
queens problem and coloring maps , using generate - and - test programs . They have
used the examples as evidence of Prolog 's inadequate control . Suggestions for
improvement include co - routining incorporated in lC - Prolog ( Clark and McCabe ,
1979 ) and intelligent backtracking ( Bruynooghe and Pereira , 1984 ) . A good discussion
of how Prolog handles the N queens problem can be found in Elcock
( 1983 ) .
The zebra puzzle , Exercise 14 . 1 ( iv ) , did the rounds on the Prolog Digest in
the early 1980 's and was used as an unofficial benchmark to test both the speed
of Prolog implementations and the ability of Prolog programmers to write clear
code .
The definitive discussion of don ' t - care and don ' t - know non determinism in
logic programming appears in Kowalski ( 1979 ) .
Program 14 . 11 for planning is a variant of an example from Kowalski ( 1979 ) .
The original planning program in Prolog was Warpian ( Warren , 1976 ) , reproduced
in Coelho et al . ( 1980 ) .
Our notation for automata follows Hopcroft and Ullman ( 1979 ) .
The classic work on unfolding is by Burstall and Darling ton ( 1977 ) .
ANALOGY constituted the PhiD . thesis of Thomas Evans at MIT in the
mid 1960 ' s . A good description of the program appears in Semantic Information
Processing ( Minsky , 1968 ) . Evans ' program tackled many aspects of the problem
that are made trivial by our choice of representation , for example , identifying that
there are triangles , squares and circles in the figures . Our version , Program 14 . 17 ,
emerged from a discussion group of the first author with a group of Epistemics
students at the University of Edinburgh .

14.5 Background 237
nQ
(i ) Given
00
A B
U I
C9
2@3 DO
5 0
(ii ) Given
:
0
~ 0 F
7
00 8 9
6
10
(iii ) Given:
@
G@H [g
I
0
II
~ 12 13 14 15
Figure 14 .9 : Three analogy problems

ELIZA was originally presented in Weizenbaum (1966) . Its performance led

people to believe that a limited form of the Thring test had been passed. Weizen -
baum , its author , was horrified by people 's reactions to the program , and to AI
more generally , and wrote an impassioned plea against taking the program too
seriously (Weizenbaum , 1976) . Our version , Program 14.20, is a slight variant
of a teaching program attributed to Alan Bundy , Richard O ' Keefe and Henry
Thompson , which was used for AI courses at the University of Edinburgh .
McSAM is a version of the SAM program , which was tailored for teaching
AI programming (Schank and Riesbeck , 1981) . Our version , Program 14.21, is
due to Ernie Davis and the second author . More information about conceptual
dependency can be found in Schank and Abelson (1977) .
Chapter 15
Incolllplete Data Structures
The programs presented so far have been discussed in terms of relationships

between complete data structures . Powerful programming techniques emerge from
extending the discussion to incomplete data structures , as demonstrated in this
chapter .
The first section discuss es difference -lists : an alternative data structure to
lists for representing a sequence of elements . They can be used to simplify and
increase the efficiency of list -processing programs . Difference -lists generalize the
concept of accumulators . Data structures built from the difference of incomplete
structures other than lists are discussed in the second section . The third section
shows how tables and dictionaries , represented as incomplete structures , can be
built incrementally during a computation . The final section discuss es queues, an
application of difference -lists .
15 .1 Difference -lists
Consider the sequence of elements 1,2,9. It can be represented as the difference

between pairs of lists . It is the difference between the lists [1,2,9,4,5] and
[4,5], the difference between the lists [1,2,9,8] and [8], and the difference between
[1,2, 9] and [ ] . Each of these cases is an instance of the difference between two
incomplete lists [1,2,9IXs] and Xs .
We denote the difference between two lists as a structure As\ Bs , which is
called a difference -list . As is the head of the difference - list and Bs the tail . In the
above example [1,2, 9IXs]\ Xs is the most general difference -list representing the
sequence 1,2,9, where [1,2,3IXs] is the head of the difference -list and Xs the tail .
240 Incomplete Data Structures 15.1
. . . . . . . . .
.
Xs
. v .
Xs\ Ys
. . . . . y
N
~ cn
. . . . .
. . . . . . . . . .
. V J
Xs \ Z s
Figure 15 . 1: Concatenating difference -lists
Logical expressions are unified , not evaluated , so that the name of the binary
functor used to denote difference -lists can be arbitrary , as long as it is used consistently
. It can even be omitted entirely , the head and tail of the difference -list
becoming two separate arguments in a predicate .
Lists and difference -lists are closely related . Both are used to represent sequences
of elements . Any list L can be trivially represented as a difference -list
L\ [ ]. The empty list is representedby any difference-list whose head and tail are
identical , the most general form being As\ As.
Difference -lists are an established logic programming technique . The use of
difference - lists rather than lists can lead to more concise and efficient programs .
The improvement occurs because of the combining property of difference -lists .
Two incomplete difference -lists can be concatenated to give a third difference -list
in constant time . In contrast , lists are concatenated , using the standard append
program , in time linear in the length of the first list .
Consider the lists in Figure 15.1. The difference-list Xs\ Zs is the result of
appending the difference-list Ys\ Zs to the difference-list Xs\ Ys. This can be
expressedas a single fact. Program 15.1 defines a predicate append_dl(As,Bs,Cs)
which is true if the difference - list Cs is the result of appending the difference -list
Bs to the difference -list As . We use the suffix _dl to denote a variant of a predicate
that uses difference - lists .
15.1 Difference-lists 241
append _ dl ( As , Bs , Cs ) + -
The difference - list Cs is the result of appending Bs to As ,
where As and Bs are compatible difference - lists .
append _ dl ( Xs \ Ys , Ys \ Zs , Xs \ Zs ) .
Program 15 . 1 : Concatenating difference - lists
ftatten ( Xs , Ys ) + -
Ys is a flattenedlist containingthe elementsin Xs.

flatten(Xs,Ys) +- flatten-dl(Xs,Ys\ [ ]).
flatten_dl([X I Xs],Ys\ Zs) +-
flatten_dl(X,Ys\ Ysl ), flatten_dl(Xs,Ysl \ Zs).
flatten-dl(X,[X IXs]\ Xs) +-
constant(X), X# [ ].
flatten_dl([ ],Xs\ Xs).
Program 15.2: Flattening a list of lists usingdifference
-lists
A necessary and sufficient condition characterizing when two difference - lists
As \ Bs and Xs \ Y s can be concatenated using Program 15 . 1 is that Bs be unifi -

able with Xs . In that case the two difference - lists are compatible . If the tail of
a difference - list is uninstantiated , it is compatible with any difference - list . Furthermore

, in such a case Program 15 . 1 would concatenate it in constant time .
For example , the result of the query append _ dl ( [ a , b , cIXs ] \ Xs , [ 1 , 2 ] \ [ ] , Ys ) ? is

( Xs = [ 1 , 2 ] , Ys = [ a , b , c , 1 , 2 ] \ [ ] ) .
Difference - lists are the logic programming counterpart of Lisp ' s rplacd , which
is also used to concatenate lists in constant time and save " consing " ( allocating
new list - cells ). There is a difference between the two : the former are side - effect
free , and can be discussed in terms of the abstract computation model , whereas
rplacd is a destructive operation , which can be described only by reference to the

machine representation of S - expressions .
A good example of a program which can be improved by using difference - lists

is Program 9 . la for flattening a list . It uses double recursion to flatten separately
the head and tail of a list of lists , then concatenates the results together . We adapt
that program to compute the relation ftatten _ dl ( Ls , Xs ) , where Xs is adifference -

list representing the elements which appear in a list of lists Ls in correct order .
The direct translation of Program 9 . la to use difference - lists appears below .
flatten_dl([X IXs],Ys\ Zs) +-

flatten_dl(X,As\ Bs), flatten_dl(Xs,Cs\ Ds),
append_dl(As\ Bs,Cs\ Ds,Ys\ Zs).
flatten_dl(X,[X IXs]\ Xs) +-
flatten_dl([ ],Xs\ Xs).
The doubly recursive clause can be simplified by unfolding the append_dl goal
with respectto its definition in Program15.1. The result is
Hatten_dl([X IXs],As\ Ds) +-
Hatten_dl(X,As\ Bs), Hatten_dl(Xs,Bs\ Ds).
The program for flatten _dl can be used to implement flatten by expressing the
connection between the desired flattened list and the difference - list computed by
flatten _dl as follows :
flatten (Xs,Ys) +- flatten _dl (Xs,Ys\ ( )).
Collecting the program and renaming variables yields Program 15.2.
Declaratively Program 15.2 is straightforward . The explicit call to append is

made unnecessary by flattening the original list of lists into a difference -list rather
than a list . The resultant program is more efficient , as the size of its proof tree is
linear in the number of elements in the list of lists rather than quadratic .
The operational behavior of programs using difference -lists , such as Program

15.2, is harder to understand . The flattened list seems to be built by magic .
Let us investigate the program in action . Figure 15.2 is a trace of the query
flatten (((a),(b,(c))),Xs) ? with respect to Program 15.2.
The trace shows that the output , Xs, is built top-down (in the terminology
of Section 7.5). The tail of the difference-list acts like a pointer to the end of
the incomplete structure . The pointer gets set by unification . By using these
"pointers " no intermediate structures are built , in contrast to Program 9.la .
The discrepancy between clear declarative understanding and difficult procedural

understanding stems from the power of the logical variable . We can
specify logical relationships implicitly , and leave their enforcement to Prolog .
Here the concatenation of the difference -lists has been expressed implicitly , and
it is mysterious when it happens in the program . Programs using difference - lists
are sometimes structurally similar to programs written using accumulators. Exercise
9.1(i) asked for a doubly recursive version of flatten which avoided the
15.1 Difference -lists 243
flatten ([[aJ,[b,[c]]] ,Xs)

flatten _dl ( [[a], [b, [c]]] ,Xs \ [ ])
flatten _dl ( [aJ,Xs\ Xsl )
flatten _dl (a,Xs\ Xsl ) Xs = [aIXs2]
constant(a)
a :l: [ ]
flatten _dl ([] ,Xs2\ Xsl ) Xs2 = Xsl
flatten _dl ([[b,[c]]],Xsl \ [ ])
flatten _dl ([b,[c]],XsI \ Xs3)
flatten _dl (b,Xsl \ Xs4) Xsl = [blXs4]
constant(b)
b :l: [ ]
flatten _dl ([[c]] ,Xs4\ Xs3)
flatten -dl ([c] ,Xs4\ Xs5)
flatten _dl (c,Xs4\ Xs6) Xs4= [cIXs6
]
constant(c)
c :l: [ ]
flatten _dl ([ ] ,Xs6\ Xs5) Xs6 = Xs5
flatten _dl ([ ],Xs5\ Xs3) Xs5 = Xs3
flatten _dl ([ ],Xs3\ [ ]) Xs3 = [ ]
Output : Xs = [a,b,c]
Figure 15 .2 : Tracing a computation using difference -lists
call to append by using accumulators . A solution is the following program :
flatten (Xs,Ys) +- flatten (Xs,[ ],Ys).

flatten ([X IXs],Zs,Ys) +-
flatten (Xs,Zs,Y sl ) , flatten (X ,Y slY s).
flatten (X ,Xs,[X IXs]) +-
flatten([ ],Xs,Xs).
The similarity of this program to Program 15.2 is striking . There are only two
differences between the programs . The first difference is syntactic . The difference -
list is represented as two arguments , but in reverse order , the tail preceding the
head . The second difference is the goal order in the recursive clause of flatten .
The net effect is that the flattened list is built bottom -up from its tail , rather
than top -down from its head .
reverse ( Xs , Y s) +-
Y s is the reversal of the list Xs .
reverse ( Xs ,y s) f - reverse _ill ( Xs ,Y s \ [ ] ) .
reverse _ dl ( [X I Xs ] , Ys \ Zs ) +-
reverse - dl ( Xs , Y s \ [XI Zs ] ) .
reverse _dl ( [ ] , Xs \ Xs ) .
Program 15 .3 : Reverse with difference - lists
quicksort ( List , Sorted List ) +-
Sorted List is an ordered permutation of List .
quicksort ( Xs , Ys ) i - quicksort _ dl ( Xs , Ys \ [ ]) .
quicksort _ dl ( [X I Xs ] , Ys \ Zs ) +-
partition ( Xs ,X , Littles , Bigs ) ,
quicksort _ dl ( Littles , Ys \ [X I Ys1 ]) ,
quicksort _ dl ( Bigs , Y sl \ Zs ) .
quicksort _dl ( [ ) , Xs \ Xs ) .
partition ( Xs , X , Ls , Bs ) +- See Program 3 . 22 .
Program 15 .4 : Quicksort using difference - lists
We give another example of the similarity between difference -lists and ac-
cumulators . Program 15 .3 is a translation of "naive " reverse (Program 3 .16a )
where lists have been replaced by difference -lists , and the append operation has
been unfolded away .
When are difference -lists the appropriate data structure for Prolog programs ?
Programs with explicit calls to append can usually gain in efficiency by using
difference -lists rather than lists . A typical example is a doubly recursive program
where the final result is obtained by appending the outputs of the two recursive
calls . More generally a program that independently builds different sections of a
list to be later combined together is a good candidate for using difference -lists .
The logic program for quicksort , Program 3 .22 , is an example of a doubly

recursive program where the final J' esult , a sorted list , is obtained from concatenating
two sorted sublists . It can be made more efficient by using difference - lists .
All the append operations involved in combining partial results can be performed
implicitly , as shown in Program 15 . 4.
The call of quicksort _dl by quicksort is an initializing call as for flatten in

15.1 Difference -lists 245
Program 15.2. The recursive clause is the quicksort algorithm interpreted for
difference - lists where the final result is pieced together implicitly rather than
explicitly . The base clause of quicksort _distates that the result of sorting an empty
list is the empty difference -list . Note the use of unification to place the partitioning
element X after the smaller elements Y s and before the bigger elements Ysl in
the call quicksort_dl(Littles , Ys\ [Xl Ys1]).
Program 15. 4 is derived from Program 3.22 in exactly the same way that
Program 15.2 is derived from Program 9.la . Lists are replaced by difference -lists
and the append_dl goal unfolded away. The initial call of quicksort _dl by quicksort
express es the relationship between the desired sorted list and the computed sorted
difference - list .
An outstanding example of using difference -lists to advantage is a solution

to a simplified version of Dijkstra 's Dutch flag problem . The problem reads :
" Given a list of elements colored red , white , and blue , reorder the list so that all
the red elements appear first , then all the white elements , followed by the blue
elements . This reordering should preserve the original relative order of elements
of the same color." For example, the list [red(1), white(2), blue( 9),red(4), white( 5)]
should be reordered to [red(1) , red(4), white( 2), white( 5) ,blue( 9)].
Program 15.5 is a simple minded solution to the problem which collects the
elements in three separate lists , then concatenates the lists . The basic relation
is dutch(Xs, Ys) where Xs is the original list of colored elements and Ys is the
reordered list separated into colors .
The heart of the program is the procedure distribute which constructs three
lists , one for each color . The lists are built top -down . The two calls to append
can be removed by having distribute build three distinct difference -lists instead of
three lists . Program 15.6 is an appropriately modified version of the program .
The implicit concatenation of the difference -lists is done in the initializing
call to distribute _dls by dutch . The complete list is finally " assembled" from its
parts with the satisfaction of the base clause of distribute - 4Is.
The Dutch flag example demonstrates a program that builds parts of the
solution independently , and pieces them together at the end . It is a more complex
use of difference - lists than the earlier examples .
Although easier to read , the use of an explicit constructor for difference -lists
incurs noticeable overhead in time and space. Using two separate arguments for
that purpose is more efficient . When important , this efficiency can be gained by
straightforward manual or automatic transformation .
dutch ( Xs , Reds Whites Blues ) +-

Reds Whites Blues is a list of elements of Xs ordered
by color : red , then white , then blue .

distribute ( Xs ,Reds , Whites ,Blues ),
append ( Whites ,Blues , Whites Blues ),
append ( Reds , Whites Blues ,Reds Whites Blues ).
distribute ( Xs , Reds , Whites , Blues ) +-

Reds , Whites , and Blues are the lists of the red , white ,
and blue elements in Xs , respectively .
distribute ( [red ( X ) IXs ] , [red ( X ) I Reds ] , Whites , Blues ) +-

distribute ( Xs ,Reds , Whites ,Blues ).
distribute ( [white ( X ) IXs ] ,Reds , [white ( X ) I Whites ] ,Blues ) +-

distribute ( Xs , Reds , Whites ,Blues ).
distribute ( [blue ( X ) I Xs ] ,Reds , Whites , [blue ( X ) I Blues ]) +-

distribute ( Xs ,Reds , Whit ~ s ,Blues ).
distribute ( [ ] ,[ ] ,[ ] ,[ ]) .
append ( Xs ,Ys , Zs ) + - See Program 3 . 15
Program 15 . 5 : A solution to the Dutch flag problem

Reds Whites Blues is a list of elements of Xs ordered
by color : red , then white , then blue .

distribute _dls ( Xs ,Reds Whites Blues \ Whites Blues ,
Whites Blues \ Blues , Blues \ [ I).
distribute - dls ( Xs J Reds JWhites JBlues ) ~

Reds , Whites , and Blues are the difference - lists of the
red , white , and blue elements in Xs , resp Jctively .
distribute - dls ( (red ( X ) IXs ] , (red ( X ) I Reds ] \ Redsl , Whites ,Blues ) +-

distribute _dls ( Xs , Reds \ Redsl , Whites ,Blues ).
distribute _dls ( (white ( X ) IXs ] ,Reds , (white ( X ) I Whites ] \ Whitesl , Blues ) +-

distribute _dls ( Xs , Reds , Whites \ Whitesl ,Blues ).
distribute _dls ( (blue ( X ) IXs ] ,Reds , Whites , (blue ( X ) I Blues ] \ Bluesl ) +-

distribute _dls ( Xs , Reds , Whites ,Blues \ Bluesl ).
distribute - dls ( ( ] ,Reds \ Reds , Whites \ Whites ,Blues \ Blues ).
Program 15 . 6 : Dutch flag with difference - lists

15.2 Differen ce-structures 247
(i ) Rewrite Program 15.2 so that the final list of elements is in the reverse order
to how they appear in the list of lists .
(ii ) Rewrite Programs 3.27 for pre_order ( Tree,List ) , in _order ( Tree,List ) and
post_order ( Tree,List ) , which collect the elements occurring in a binary tree ,
to use difference -lists and avoid an explicit call to append .
(iii ) Rewrite Program 12.3 for solving the Towers of Hanoi so that the list of
moves is created as a difference - list rather than a list .
15 .2 Difference - structures
The concept underlying difference -lists is the use of the difference between
incomplete data structures to represent partial results of a computation . This
can be applied to recursive data types other than lists . This section looks at a
specific example , algebraic sums .
Consider the task of normalizing arithmetic expressions , for example sums .

Figure 15.2 contains two sums ( a+ b) + ( c+ d) and ( a+ ( b+ ( c+ d) )) (Standard Prolog
syntax brackets the term a+ b+ c as ( ( a+ b) + c) . We describe a procedure converting
a sum into a normalized one that is bracketed to the right . For example the
expression on the left in Figure 15.3 would be converted to the one on the right .
Such a procedure is useful for doing algebraic simplification , facilitating writing
programs to test whether two expressions are equivalent .
We introduce a difference -sum as a variant of a difference -list . Adifference -
sum is represented as a structure El + + E2 , where El and E2 are incomplete
normalized sums. It is assumed that + + is defined as a binary infix operator . It
is convenient to use 0 to indicate an empty sum .
Program 15.7 is a program for normalizing sums. The relation scheme is normalize
(Exp,Norm Exp) where Norm Exp is an expression equivalent to Exp which
is bracketed to the right and preserves the order of the constants appearing in
Exp .
This program is similar in structure to Program 15.2 for flattening ~ists using
difference -lists . There is an initialization stage where the difference -structure is
set up , typically calling a predicate with the same name but different arity or
different argument pattern . The base case passes out the tail of the incomplete
structure , while the goals in the body of the recursive clause pass the tail of the
first incomplete structure to be the head of the second.
normalize ( Sum,N ormalized Sum) +-

N ormalized Sum is the result of normalizing the sum expression Sum.
normalize (Exp ,Norm ) +-- normalize _ds(Exp ,Norm + + O) .

normalize _ds(A + BiNorm + + Space) +-
normalize _ds(A ,Norm + + N ormB ) , normalize _ds(B ,Norm B + + Space) .
normalize _ds(A , (A + Space) + + Space) +-
constant (A ) .
Program 15 .7 : Normalizing plus expressions
+
/ \
+ +
/ \ / \
a bc d
Figure 15 .3 : Un normal ized and normalized sums
The program builds the normalized sum top -down . By analogy with the
programs using difference -lists , the program can be easily modified to build the
structure bottom -up , which is an exercise at the end of the section .
The declarative reading of these programs is straightforward . Operationally
the programs can be understood in terms of building a structure incrementally ,
where the "hole " for further results is referred to explicitly . This is entirely
analogous to difference -lists .
Define the predicate normalized _8um(Expression ) which is true if Expression

is a normalized sum .
Rewrite Program 15.7 so that

(a) the normalized sum is built bottom -up ,
(b ) the order of the elements is reversed .
15.3 Dictionaries 249
(iii ) Write a program to normalize products using difference -products , defined

analogously to difference -sums .
15 .3 Dictionaries
A different use of incomplete data structures enables the implementation of

dictionaries . Consider the task of creating , using , and maintaining a set of values
indexed under keys . There are two main operations we would like to perform :
looking up values stored under a certain key, and entering new keys and their
associated values . These operations must ensure consistency - for example the
same key should not appear twice with two different values . It is possible to
perform both operations , looking up values of keys , and entering new keys , with
a single simple procedure , by exploiting incomplete data structures .
Consider a linear sequence of key-value pairs . Let us see the advantages of
using an incomplete data structure for its representation . Program 15.8 defines
the relation lookup (Key ,Dict , Value) which is true if the entry under Key in the
dictionary Dict has value Value. The dictionary is represented as an incomplete
list of pairs of the form (Key , Value) .
Let us consider an example where the dictionary is used to remember
phone extensions keyed under the names of people . Suppose that Dict is initially
instantiated to [( arnold ,8881) ,( barry ,;, 519) ,( cathy ,5950) IXs ]. The query
lookup ( arnold ,Dict ,N) ? has as answer N = 8881, and is used for finding Arnold 's
phone number . The query lookup( barry ,Dict ,4519) ? checking Barry 's phone number
is answered affirmatively .
The entry of new keys and values is demonstrated by the query

lookup( david ,Dict ,1199) 'I. Syntactically this appears to check David 's phone
number . Its effect is different . The query succeeds, instantiating Dict to
[( arnold , 8881) ,( barry ,i,519) ,( cathy ,5950) ,( david,1199) IXsl ]. Thus lookup has entered
a new value .
What happens if we check Cathy 's number with the query lookup ( cathy,Dict ,
5951) ? where the number is incorrect ? Rather than entering a second entry for
Cathy , the query fails due to the test Key # Key1 .
The lookup procedure given in Program 15.8 completes Program 14.20, the
simplified ELIZA . Note when the program begins , the dictionary is empty , indicated
by being a variable . The dictionary is built up during the matching against
the stimulus half of a stimulus -response pair . The constructed dictionary is used
to produce the correct response . Note that entries are placed in the dictionary
lookup(Key,Dictionary , Value) +-
Dictionary contains Value indexed under Key .
Dictionary is represented aBa list of pairs (Key, Value) .
lookup (Key,[(Key,Value) IDictionary ],Value).
lookup (Key,[(Keyl ,Valuel ) IDictionary ],Value) +-
Key :f: Keyl , lookup (Key,Dictionary ,Value).
Program 15 .8 : Dictionary lookup from a list of tupies
lookup(Key,Dictionary , Value) +-
Dictionary contains Value indexed under Key .
Dictionary is represented as an ordered binary tree .
lookup (Key,dict (Key ,X ,Left ,Right ),Value) 4:-

I , X = Value .
lookup(Key,dict (Keyl ,X ,Left ,Right ),Value) 4:-
Key < Keyl , lookup (Key,Left ,Value) .
lookup (Key,dict (Key 1,X ,Left ,Right ) ,Value) 4:-
Key > Keyl , lookup (Key,Right ,Value).
Program 15 .9 : Dictionary lookup in a binary tree
without their values being known : a striking example of the power of logical variables
. Once an integer is detected , it is put in the dictionary , and its value is
determined later .
Searching linear lists is not very efficient for a large number of key-value pairs .
Ordered binary trees allow more efficient retrieval of information than linear lists .
The insight that an incomplete structure can be used to allow entry of new keys
as well as to look up values carries over to binary trees .
The binary trees of Section 3.4 are modified to be a four -place structure
dict(Key, Value,Left,Right), where Left and Right are, respectively, the left and
right sub diction aries , and Key and Value are as before . The functor dict is used
to suggest a dictionary .
Looking up in the dictionary tree has a very elegant definition , similar in

spirit to Program 15. Itperforms recursion on binary trees rather than on
lists , and relies on unification to instantiate variables to dictionary structures .
Program 15.9 gives the procedure lookup(Key,Dictionary , Value), which as before
both looks up the value corresponding to a given key and enters new values .
At each stage the key is compared with the key of the current node . If it
15.3 Dictionaries 251
freeze(A ,B) +-
Freeze term A into B.
freeze(A )B) +-
copy(A ,B), numbervars(B )O,N).
melt_new(A ,B) +-
Melt the frozen term A into B.
melt- new(A ,B) +-

melt (A ,BiDictionary ), 1.
melt ('$VA R'(N),X ,Dictionary ) +-
lookup(N ,Dictionary ,X ).
melt (X ,X ,Dictionary ) +-
constant(X ).
melt (X ,Y ,Dictionary ) +-
compound(X ) ,
functor (X ,F ,N),
functorY ,F ,N),
melt (N ,X ,Y ,Dictionary ) .
melt (N ,x ,Y ,Dictionary ) +-
N > 0,
arg(N ,X ,ArgX ),
melt (ArgX ,ArgY ,Dictionary ),
arg(N ,YArgY ) ,
Nl := N - l ,
melt (Nl ,X ,Y ,Dictionary ) .
melt (O,X ,Y ,Dictionary ) .
copy(A ,B) +- assert('$foo' (A )), retract ('$foo' (B)).
numbervars(Term,ni ,N2) +- SeeProgram 13.2
lookup (Key,Dictionary ,Value) +- SeeProgram 15.9
Program 15 . 10 : Melting a term
is less, the left branch is recursively checked; if it is greater , the right branch is
taken . H the key is non -numeric , the predicates < and > must be generalized .
The cut is necessary in Program 15.9, in contrast to Program 15.8, due to the
nonlogical nature of comparison operators which will give errors if keys are not
instantiated .
Given a number of pairs of keys and values , the dictionary they determine is
not unique . The shape of the dictionary depends on the order in which queries
are posed to the dictionary .
The dictionary can be used to melt a term that has been frozen using Program
13.2 for numbervars . The code is given as Program 15.10. Each melted variable is
entered into the dictionary , so that the correct shared variables will be assigned.
15 .4 Queues
An interesting application of difference - lists is to implement queues. A queue

is a first -in , first -out store of information . The head of the difference -list represents
the beginning of the queue, the tail represents the end of the queue , and the
members of the difference - list are the elements in the queue . A queue is empty if
the difference -list is empty , that is , its head and tail are identical .
Maintaining a queue is different from the maintenance of a dictionary given
above . We consider the relation queue(S) where a queue process es a stream of
commands , represented as a list S. There are two basic operations on a queue -
enqueueing an element and dequeueing an element - represented , respectively ,
by the structures enqueue(X) and dequeue(X) where X is the element concerned .
Program 15.11 implements the operations abstractly . The predicate queue(S)
calls queue( S, Q) where Q is initialized to an empty queue. queue/ 2 is an interpreter
for the stream of enqueue and dequeue commands , responding to each
command and updating the state of the queue accordingly . Enqueueing an element
exploits the incompleteness of the tail of the queue, instantiating it to a new
element and a new tail which is passed as the updated tail of the queue. Clearly ,
the calls to enqueue and dequeue can be unfolded , resulting in a more concise and
efficient , but perhaps less readable program .
The program terminates when the stream of commands is exhausted . It can
be extend to insist that the queue be empty at the end of the commands by
changing the base fact to
queue([ ],Q) +- empty(Q).
A queue is empty if both its head and tail can be instantiated to the empty list ,
expressed by the fact empty ( [ ]\ [ ]) . Logically , the clause empty (. X\ X) would also
be sufficient , however , due to the lack of occurs check in Prolog , discussed in
Chapter 4, it may succeed erroneously on a nonempty queue , creating a cyclic
data structure .
15.4 Queues 253
queue(S) f0-
B is a sequence of enqueue and dequeue operations ,
representedas a list of terms enqueue(X) and dequeue
(X) .
queue(S) +- queue(S,Q\ Q) .
queue([enqueue(X ) IXs],Q) ~
enqueue(X ,Q,Ql ), queue(Xs,Ql ).
queue([dequeue(X )IXs],Q) ~
dequeue(X ,Q,Ql ), queue(Xs,Ql ).
queue([ ],Q).
enqueue(X ,Qh\ [X IQt),Qh\ Qt ) 1
dequeue(X ,[X IQh)\ Qt ,Qh\ Qt )
Program 15 . 11 : A queue process
We demonstrate the use of queues in Program 15.12 for flattening a list .

Although the example is somewhat contrived , it shows how queuies can be used.
The program does not preserve the order of the elements in the original list .
The basic relation is flatten _q(Ls,Q,Xs) where Ls is the list of lists to be flattened
, Q is the queueof lists waiting to be flattened, and Xs is the list of elements
in Ls. The initial clause of flatten -q/ 9 by flatten / 2 initializes an empty queue.
The basic operation is enqueuing the tail of the list and recursively flattening the
head of the list :
flatten -q([X IXs],Q,Ys) +-

enqueue(Xs,Q,Ql ), flatten _q(X ,Ql ,Ys).
Unfolding the explicit call to enqueue gives
flatten -q([X IXs],Qh\ [XsIQt],Ans) +-

flatten _q(X ,Qh\ Qt ,Y s) .
If the element being flattened is a constant , it is added to the output structure

being built down, and an element is dequeued (by unifying with the head of the
difference list ) to be flattened in the recursive call:
flatten -q(X ,[QIQh]\ Qt ,[X IYs]) 400 -
constant(X ), X =f [ ], flatten _q(Q,Qh\ Qt ,Ys).
When the empty list is being flattened , either the top element is dequeued
Flatten_q([ ],[QIQh]\ Qt ,Ys) +- Flatten_q(Q,Qh\ Qt ,Ys).

flatten ( Xs , Ys ) +-
Y s is a flattened list containing the elements in Xs .
flatten ( Xs , Ys ) +- flatten - q ( Xs , Qs \ Qs , VB ) .
flatten _ q ( [X I Xs ] , Ps \ [XsIQs ] , Ys ) +-
flatten _q ( X , Ps \ Qs ,Y s ) .
flatten _ q ( X , [ QIPs ] \ Qs , [X I Ys ]) +-
constant ( X ) , X : / : [ ] , flatten _ q ( Q , Ps \ Qs , Ys ) .
flatten - q ( [ ] , [ QIPs ] \ Qs , Ys ) +-
flatten _ q ( Q , Ps \ Qs , Ys ) .
flatten _q ( [ ] , [ ] \ [ ] , [ ] ) .
Program 15 . 12 : Flattening a list using a queue
or the queue is empty , and the computation terminates :
flatten _q ( [ ] , [ ] \ [ ] , [ ] ) .
Program 15 . 12 is not totally correct as written . The query flatten
- q ( [ ] , As \ As , Ys ) ' I, flattening an empty list with respect to an empty queue , is
reduced to the goal flatten _ q ( X , Asl \ [X I Asl ] , Ys ) using the third clause . The goal
is further reduced to flatten _ q ( Xl , Asl \ AslYs ) by the first clause , which clearly
gives rise to a non - terminating computation . Flattening an empty list with respect
to an empty queue is covered correctly by the flatten _ q fact . The undesired
unification with the third clause of flatten _ q can be avoided by changing the order
of clauses and using a cut . The preferred , declarative solution is to add a test to
the third clause of flatten _q so that it only succeeds on non - empty queues .
flatten _ q ( [ ] , Queue ,Y s ) ~
Queue =J: As - As , Queue = [ QIPs ] \ Qs , flatten _ q ( Q , Ps \ Qs ,Ys ) .
Let us reconsider Program 15 . 11 operationally . Under the expected use of a
queue , enqueue (X) messages are sent with X determined , and dequeue (X) with X
undetermined . As long as more elements are enqueued than dequeued , the queue
behaves as expected , with the difference between the head of the queue and the
tail of the queue being the elements in the queue . However , if the number of
dequeue messages received exceeds that of enqueue messages , an interesting thing
happens - the content of the queue becomes " negative ." The head runs ahead
of the tail resulting in the queue containing a negative sequence of undetermined
elements , one for each excessive dequeue message .
It is interest - to observe
in ~ that this behavior is consistent with the associa -
tivity of appending of difference-lists. If a queue Qs\ [xi ,X2,X31Qs] that contains

15.5 Background 255
minus three undetermined elements is appended to the queue [a, b, c, d,eIXs]\ Xs

that contains five elements , then the result will be the queue [d, eIXs]\ Xs with two
elements , where the "negative " elements Xl ,X2 ,X3 are unified with a,b,c.
15 .5 Background
Difference-lists have been in the logic programming folklore since its inception
. The first description of them in the literature is given by Clark and Tarnlund
(1977).
The automatic transformation of simple programs without difference-lists to
programs with difference-lists, for example, reverseand flatten , can be found in
Bloch (1984).
The elegant lookupprocedure for ordered binary trees is describedby Warren
(1980), and is used as a central technique for writing compilers in Prolog, as will
be described in Chapter 23. .
Maintaining dictionaries and queues can be given a theoretical basis as a
perpetual process, as described by van Emden (1984) and Lloyd (1984).
Queuesare more important in concurrent logic programming languages, since
their input need not be a list of requests but a stream, which is generated incrementally
by the processes requesting the servicesof the queue.
Chapter 16
Parsing with
Definite Clause Gra Ill Illars
A very important application of Prolog and logic programming is parsing .
Prolog in fact originated from attempts to use logic to express grammar rules and
formalize the parsing process .
The most popular approach to parsing in Prolog is definite clause grammars
or DCGs . DCGs are a generalization of context - free grammars that are
executable , because they are a notational variant of a class of Prolog programs .
Parsing with DCGs is discussed here because of its relevance to the previous
two chapters . It is a perfect illustration of Prolog programming using nondeterministic
programming and difference - lists . ' ----- - --
We begin by discussing context - free grammars . Context - free grammars consist
of a set of rules of the form
( nonterminal ) - + ( body )
where nonterminal is a nonterminal symbol and body is a sequence of one or
more items separated by commas . Each item is either a nonterminal symbol or a
sequence of terminal symbols . The meaning of the rule is that body is a possible
form for a phrase of type nonterminal . Nonterminal symbols are written as Prolog
atoms , and sequences of terminal symbols as lists of atoms . This is to facilitate
the translation of the grammars to Prolog programs .
For each nonterminal symbolS , a grammar defines a language , which is
the set of sequences of terminal symbols , obtained by repeated nondeterministic
application of the grammar rules , starting from S .
Consider the simple context - free grammar for a small subset of English given
in Figure 16 . 1 . The grammar is self - explanatory , the reading of the first rule being :
Parsing with Definite Clause Grammars 257
Grammar Rules
sentence - + noun _phrase , verb _phrase .

noun -phrase - + determiner , noun _phrase2 .
noun _phrase - + no U D_phrase2 .
noun _phrase2 - + adjective , noun _phrase2 .
no Ull -phrase2 - + noun .
verb _phrase - + verb .
verb _phrase - + verb , noun _phrase .
Vocabulary
determiner - + [the]. adjective - + [decorated]
determiner - + [a].
noun - + [pieplate]. verb - + [contains].
noun - + [surprise].
Figure 16 . 1: A simple context -free grammar
a sentence consists of a noun phrase followed by a verb phrase . A sample sentence

recognized by the grammar is "The decorated pieplate contains a surprise ."
The grammar can be immediately written as a Prolog program . Each nonterminal
symbol becomes a unary predicate whose argument is the sentence or
phrase it identifies . The naive choice for representing the sentence is as a list of
words . The various subparts of a sentence will also be lists of words . The first
grammar rule becomes
sentence(8) +-
append(NP ,VP ,8), noun_phrase(NP), verb_phrase(VP ).
The vocabulary rules involving terminal symbols can be expressed as facts , for
example ,
determiner( [the]). noun([pieplate]).
Completing the grammar of Figure 16.1 as prescribed above leads to a correct

program for parsing , but an inefficient one. The calls to append suggest that a
difference -list might be a more appropriate structure for parsing , which is indeed
the case. Program 16.1 is a translation of the grammar of Figure 16.1 to a Prolog
program where difference -lists represent the phrases .
The basic relation scheme is sentenceS) where S is a difference-list of
258 Parsing with Definite Clause Grammars
sentenceS \ SO) +-
noun _phraseS \ Sl ) , verb _phrase (Sl \ SO) .
noun _phraseS \ SO) +-
determiner (S\ Sl ) , noun_phrase2(Sl \ SO).
noun _phraseS ) +-
noun _phrase2 (S) .
noun _phrase2 ( 8 \ 80 ) +-
ad .iective ( 8 \ 81 ) , noun _phrase2 ( 81 \ 80 ) .
noun - phrase2 (S ) +-
noun (S ) .
verb _phraseS ) +-
verb (S ) .
verb _phraseS \ SO ) +-
verb ( S \ Sl ) , noun _phrase ( Sl \ SO ) .
determiner ( [the I8 ] \ 8 ) . adjective ( [ decoratedl 8 ]\ 8 ) .
determiner ( [ a I8 ] \ 8 ) .
noun ( [pieplate IS ) \ S ) . verb ( [ contains IS ) \ S ) .
noun ( [ surprise IS ) \ S ) .
Program 16 .1 : A Prolog program for parsing the language defined
in Figure 16 . 1
words that forms a sentence according to the rules of the grammar . Similarly
noun _phraseS ) , noun _ phrase2 ( S) , determiner ( S) , verb _phraseS ) , noun ( S)
and verb ( S) all are true if their argument , a difference - list S of words , is the part
of speech their name suggests .
As a parsing program , Program 16 . 1 is a top - down , left - to - right recursive
parser that backtracks when it needs an alternative solution . Although easy to
construct , backtracking parsers are in general inefficient . However , the efficiency
of the underlying Prolog backtracking mechanism compensates for that , so that
DCGs are practical , effective parsers .
The translation of a context - free grammar to an equivalent Prolog program
is straightforward . Program 16 . 2 translates a single grammar rule to its Prolog
equivalent . Transforming the entire grammar just involves transforming each

individual rule . Grammar rules are assumed to be represented as a term A - + B ,
where A is a nonterminal symbol and B is a conjunction of nonterminal symbols
and lists of terminal symbols . Nonterminal symbols are Prolog atoms , and an
translate ( Grammar Rule , Prolog Clause ) +-

Prolog Clause is the Prolog equivalent of the context - free
grammar rule Grammar Rule .
translate ( ( Lhs - + Rhs ) , ( Head + - Body ) ) +-

translate ( Lhs ,Head ,Xs \ Ys ) , translate ( Rhs ,Body ,Xs \ Ys ) .
translate ( ( A ,B ) , ( Al , Bl ) ,Xs \ Ys ) t -
translate ( A ,Al ,Xs \ Xsl ) ) translate ( B ,Bl ,Xsl \ Ys ) .
translate ( A )AliS ) t -
non _terminal ( AfunctorAl ,Ail ) , arg ( l ,AliS ).
translate ( Xs , true ,S ) i -
terminals ( Xs ) ,
sequence ( Xs , S ) .
non _terminal (A ) ~ atom (A ) .
terminals ( [X IXs ] ) .
sequence ( [X IXs ] , [XIS ] \ SO ) ~ sequence ( Xs , S \ SO ) .
sequence ( [ ] ,Xs \ Xs ) .
Program 16 . 2 : Translating grammar rules to Prolog clauses
appropriate operator declaration for ~ is assumed .
The basic relation scheme of Program 16 .2 is translate ( Grammar Rule , Prolog -
Clause ). The procedure for translate / 2 translates the left - hand side and righthand
side of the grammar rule to the head and body of the equivalent Prolog
clause . The basic idea is to add a difference - list to each nonterminal symbol .
A new version of translate , translate ( Symbol J Goal JXs ) is necessary . The relation
is true if Symbol is translated to Goal by adding the difference - list Xs as an
argument . The three clauses for translate / 9 cover the possible terms in a grammar
rule . If the term is a conjunction , each conjunct is recursively translated with the
appropriate connections between the difference - lists made . Nonterminal symbols

are translated into a unary structure , whose functor is the symbol and whose
argument is the difference - list . Sequences of terminal symbols are unified into
the rule ' s difference - list using sequence ( Symbol JXs ) . A post - processor can remove
the excessive true goals , or one can use a difference - structure to prevent their
construction in the first place .
The next two programs to be presented augment Program 16 . 1 . The extensions

, although simple , typify how DCGs are used to build parsers . They exploit
the power of the logical variable .

The first extension is constructing a parse tree for the sentence as it is being
parsed . Arguments representing (subparts of ) the parse tree must be added to the
predicates in Program 16.1. The extension is similar to adding structured arguments
to logic programs as discussed in Section 2.2. We modify sentence/ l to be a
binary relation sentence( Tree, Words) where Tree is the parse tree of Words parsed
according to the grammar . The other unary predicates representing phrases and
parts of speech must similarly be changed to binary predicates . We assume that
the parse tree is the first argument .
The first clause of Program 16.1 is extended to be
sentence(sentence(NP ,VP ) ,8\ 81) +-

noun _phrase (NP ,8\ 80) , verb _phrase (VP ,80\ 81) .
The compound term sentence( NP , VP ) represents the parse tree , with NP and VP
representing the parsed noun phrase and verb phrase .
This extension can also be reflected in augmenting the grammar rules . An
extra argument can be added to the nonterminal symbols , so that they become
structures . The rule above is represented as
sentence(sentence(NP ,VP ) ) - + no Ull -phrase (NP ) , verb _phrase (VP ) .
Adding arguments to nonterminal symbols of context -free grammars increases

their utility . The new class of grammars are called definite clause grammars .
De~nite clause grammars are essentially context -free grammars augmented by
the language features of Prolog .
Program 16.2, translating context -free grammars into Prolog programs , can
be extended to translateD O Gs into Prolog . The extension is posed as Exercise
16(iii ) . We write DO Gs then in grammar rule notation , being aware they are
essentially Prolog programs .
The DCGs in Program 16.3 are an extension of Program 16.1 which computes
the parse tree at the same time as parsing a sentence. As a logic program , it is
similar to Program 2.3 which computed a structure in addition to identifying the
circuit components . The program builds the parse tree top -down , exploiting the
power of the logical variable .
The next extension concerns subject / object number agreement . Suppose

we wanted our grammar also to parse the sentence "The decorated
pieplates contain a surprise ." A simplistic way of handling plural forms of
nouns and verbs , sufficient for the purposes of this book , is to treat different
forms as separate words . We augment the vocabulary by adding the facts
sentence(sentence(N ,V ) ) - + noun _phrase (N ) , verb _phrase (V ) .

noun _phrase (np (D ,N ) ) - + determiner (D ) , noun _phrase2 (N ) .
noun _phrase (np (N ) ) - + noun -phrase2 (N ) .
noun _phrase2 (np2 (A ,N )) - + adjective (A ) , noun _phrase2 (N ) .
noun _phrase2 (np2 (N ) ) - + noun (N ) .
verb _phrase (vp (V ) ) --. verb (V ) .
verb _phrase (vp (V ,N )) --. .verb (V ) , noun _phrase (N ) .
Vocabulary
determiner (det (the ) ) - + [the ] .

determiner (det (a) ) - + [a].
noun (noun (pieplate ) ) --+ [pieplate ] .
noun (noun (surprise )) --+ [surprise ].
adjective(adj (decorated)) -+- [decorated}.
verb (verb (contains)) -+- [contains}.
Program 16.3: A DCG computing a parse tree
noun (noun (pieplates ) ) - + [pieplates ].

v ~rb (verb (contain ) ) - + [contain ].
The new program would parse "The decorated pieplates contain a surprise ," but
unfortunately would also parse "The decorated pieplates contains a surprise ."
There is no insistence that noun and verb must both be singular , or both be
plural .
Number agreement can be enforced by adding an argument to the parts of
speech that must be the same. The argument indicates whether the part of speech
is singular or plural . Consider the grammar rule
sentence (sentence (NP ,VP )) - 7

noun _phrase (NP ,Num ) , verb -phrase (VP ,Num ) .
The rule insists that both the noun phrase which is the subject of the sentence
and the verb phrase which is the object of the sentence have the same number ,
singular or plural . The agreement is indicated by the sharing of the variable Num .
Expressing subject / object number agreement is context -dependent information ,
which is clearly beyond the scope of context -free grammars .
Program 16.4 is an extension of Program 16.3 that handles number agreement
sentence ( sentence ( N ,V ) ) ~ no Ull .- phrase ( NN um ) , verb - phrase ( V ,Num ).
noun - phrase ( np ( DiN ) , Num ) - +-
determiner ( D ,Num ) , noun _phrase2 ( N ,Num ).

noun _phrase ( np ( N ) ,Num ) - +- noun _phrase2 ( N ,Num ) .
noun _phrase2 ( np2 ( A , N ) ,Num ) - + adjective ( A ) , noun _phrase2 ( N ,Num ).

noun _phrase2 ( np2 ( N ) ,Nl1m ) - + noun ( N ,Num ).
verb _phrase ( vp ( V ) ,Num ) - +- verb ( V ,Num ).
verb _phrase ( vp ( V ,N ) ,Num ) - +- verb ( V ,Num ) , noun _phrase ( N , Numl ).
Vocabulary
determiner ( det ( the ) ,Num ) - + [the ] .
determiner ( det ( a ) ,singular ) - + [a ] .
noun ( noun ( pieplate ) ,singular ) - + [pieplate ].

noun ( noun ( pieplates ) ,plural ) - + [pieplates ].
noun ( noun ( surprise ) ,singular ) - + [surprise ].
noun ( noun ( surprises ) ,plural ) - + [surprises ].
adjective ( adj ( decorated ) ) - + [decorated ].
verb ( verb ( contains ) ,singular ) - + [contains ].
verb ( verb ( contain ) ,plural ) - + [contain ].
Program 16 . 4 : A DCG with subject / object agreement
correctly . Noun phrases and verb phrases must have the same number , singular
or plural . Similarly the determiners and nouns in a noun phrase must agree in
number . The vocabulary is extended to indicate which words are singular and
which plural . Where number is unimportant , for example , with adjectives , it can
be ignored , and no extra argument is given . The determiner the can be either
singular or plural . This is handled by leaving the argument indicating number

uninstantiated .
The next example of a DOG uses another Prolog feature , the ability to refer
to arbitrary Prolog goals in the body of a rule . Program 16 . 5 is a grammar for
recognizing numbers written in English up to one thousand . In doing so , the value
of the number recognized is calculated using the arithmetic facilities of Prolog .
The basic relation is number ( N) where Nis the numerical value of the number
being recognized . According to the grammar specified by the program , a number
is zero or a number N of at most 3 digits , the relationship xxx ( N ) . Similarly xx ( N )

represents a number N of at most 2 digits , while the predicates rest _xxx and rest _xx
number (O) - + [zero].

number (N ) - + xxx (N ) .
xxx (N) - + digit (D), [hundred], rest..:xxx(Nl ), { N := D * lOO+ Nl } .
rest ..:xx:x.(O) - + [ ].
rest ..:xx:x. (N ) - + [and] , : xx(N ) .
xx (N) -jo digit (N) .
xx (N) -jo teen(N).
xx (N) -jo tens(T ), rest.:x:x(Nl ), {N := T + Nl } .
rest...:xx
.(O) - t [ ].
rest...:xx
.(N) - t digit (N).
digit (l ) - + [one]. teen(lO) - + [ten].
digit (2) - + [two]. teen(ll ) - + [eleven].
digit (3) - + [three]. teen(12) - + [twelve].
digit (4) - + [four]. teen(13) - + [thirteen ].
digit (5) - + [five]. teen(14) - + [fourteen].
digit (6) - + [six]. teen(15) - + [fifteen].
digit (7) - + [seven]. teen(16) - + [sixteen].
digit (8) - + [eight]. teen(17) - + [seventeen].
digit (9) - + [nine]. teen(18) - + [eighteen].
teen(19) - + [nineteen].
tens(20) - + [twenty].
tens(30) - + [thirty ].
tens(40) - + [forty ].
tens(50) - + [fifty ].
tens(60) - + [sixty].
tens(70) - + [seventy].
tens(80) - + [eighty].
tens(90) - + [ninety ].
Program 16 .5: A DOG for recognizing numbers
denote the rest of a number of 3 and 2 digits , respectively , after the leading digit
has been removed . The predicates digit , teen and tens recognize , respectively ,
single digits , the numbers ten to nineteen inclusive and the multiples of ten from
twenty to ninety inclusive .
A new syntactic construct is necessary in the grammar to allow arbitrary
Prolog goals. This is done by placing the Prolog goal in curly braces . We illustrate
with the rule for determining a three digit number :
xxx (N) - + digit (D), [hundred], rest- xxx(Nl ) , { N := D* lOO+ Nl } .
This says that a three digit number N must first be a digit with value D followed
by the word "hundred" followed by the rest of the number which will have value
Nl . The value for the whole number N is obtained by multiplying D by 100 and
adding Nl .
DCGs inherit another feature from logic programming , the ability to be used
backward . Program 16.5 can be used to generate the written representation of a
given number up to a thousand . In technical terms , the grammar generates as
well as accepts . The behavior in so doing is classic generate- and-test . All the
legal numbers of the grammar are generated one by one and tested if they have
the correct value , until the actual number posed is reached . This feature is a
curiosity rather than an efficient means of writing numbers .
The generative feature of DO Gs is not generally useful . Many grammars have

recursive rules . For example , the rule in Figure 16.1 defining a noun _phrase!! as
an adjective followed by a noun _phrase!! is recursive . Using recursively defined
grammars for generation results in a nonterminating computation . In the grammar
of Program 16.3 noun phrases with arbitrarily many adjectives are produced
before the verb phrase is considered .
Write a simple grammar for French that illustrates gender agreement .

Extend and modify Program 16.5 for parsing numbers so that it covers all
numbers less than one million . Don ' t forget to include things like " thirty five
hundred " and not to include " thirty hundred . "
( iii ) Extend Program 16 . 2 to translate a DOG grammar rule to a Prolog clause .
16 . 1 Background
Prolog was connected to parsing right from its very beginning . As mentioned
before , the Prolog language grew out of Colmerauer ' s interest in parsing , and his
experience with developing Q - systems ( Colmerauer , 1973 ) . Thelmplementors of
Prolog - 10 were also keen on natural language processing , and wrote one of the
more detailed accounts of definite - clause grammars ( Pereira and Warren , 1980 ) .
This paper gives a good discussion of the advantages of DCGs as a parsing formalism
in comparison with A T Ns .
Many Prologs , for example , Wisdom Prolog , provide a hook so that grammar
rules are transformed automatically as the file is consulted .
Even though the control structure of Prolog matches directly that of
recursive -descent , top -down parsers , other parsing algorithms can also be implemented
in it quite easily. For example , Matsumoto et al . ( 1986) describes a
bottom -up parser in Prolog .
The grammar in Program 16.1 is taken from Winograd's book on computa-
tionallinguistics (Winograd , 1983) .
Chapter 17
Second-Order Progralllllling
Chapters 14 and 15 demonstrate Prolog programming techniques based directly

on logic programming . This chapter in contrast shows programming techniques
that are missing from the basic logic programming model , but can nonetheless
be incorporated into Prolog by relying on language features outside of first -
order logic . These techniques are called second-order , since they talk about sets
and their properties , rather than about individuals .
The first section introduces set-predicates that produce sets as solutions .
Computing with set expressions is particularly powerful when combined with
programming techniques presented in earlier chapters . The second section gives
some applications of set-predicates . The third section looks at lambda expressions
and predicate variables , which allow functions and relations to be treated as "first
class" data objects .
17.1 Set expressions
Solving a Prolog query with a program entails finding an instance of the query
that is implied by the program . What is involved in finding all instances of a query
that are implied by a program ? Declaratively , such a query lies outside the logic
programming model presented in the first chapter . It is a second-order question
since it asks for the set of elements with a certain property . Operationally , it is also
outside the pure Prolog computation model . With pure Prolog all information
about a certain branch of the computation is lost on backtracking . This prevents
a simple way of using pure Prolog to find the set of all solutions to a query , or
even to find how many solutions there are to a given query .
This section discuss es nredicates
~ that enable the answerin --
!2: of second-order
.
querIes . We call such predicates set-predicates . They can be regarded as new
17.1 Set expressions 267
father (terach ,abraham ) . father (haran ,lot ) .

father (terach ,nachor ) . father (haran ,milcah ) .
father (terach ,haran ) . father (haran ,yiscah ) .
father ( abraham ,isaac) .
male (abraham ) . male (haran ) . female (yiscah ) .

male (isaac) . male (nachor ) . female ( milcah ) .
male (lot ) .
Figure 17.1: Sampledata
primitives . However , they are not true extensions to Prolog , since they can be defined
in Prolog , using some of its extra - logical features , notably assert and . retract .
We present them as a higher - order extension to the language , a quantification over
all solutions and show later how they can be implemented . As with the standard
implementation of negation , the implementation of set - predicates only approximates
their logical specification . But this approximation is very useful for many
applications as will be shown in the next section .
We demonstrate the use of set - predicates using part of the Biblical database
of Program 1 . 1 repeated here as Figure 17 . 1 .
Consider the task of finding all the children of a particular father . It is
natural to envisage a predicate children ( X , Kids ) where Kids is a list of children of
X to be extracted from the father facts in Figure 17 . 1 . A naive approach is based
on using an accumulator as follows :
children ( X , Cs ) + - - children ( X , [ ] , Cs ) .
children ( X , A , Cs ) + - -
father ( X , C ) , not member ( C , A ) , ! , children ( X , [ CIA ] , Cs ) .
children ( X , Cs , Cs ) .
The program success fully answers a query such as children ( terach , Xs ) ' ? with answer
Xs = [ haran , nachor , abraham ] . The approach of using accumulators has two
serious drawbacks , however , that prevent it from being the basis of more general
set - predicates . First , each time a solution is added to the accumulator , the whole
search tree is traversed afresh . In general the recomputing would be prohibitive .
Second , there are problems with generality . A query such as children ( X , Cs ) ' ?
gives the answer X = terachiCs = [ haran , nachor , abraham ] with no alternative on
backtracking due to the cut . Once " free " variables are instantiated , no alternative
solution is possible . Removing the cut causes incorrect behavior on the query
children ( terach , X ) .
268 Second-Order Programming 17.1
The preferred way of implementing set - predicates in Prolog relies on the
operational behavior of Prolog , in particular causing side - effects to the program .
How this is done is deferred till the end of the section .
The two primitive set - predicates are as follows . The relation bag _ of ( Term ,
Goal , Instances ) is true if Instances is the bag ( multiset ) of all instances of Term
for which Goal is true . Multiple identical solutions are retained . The relation
set _ of ( Term , Goal , Instances ) is a refinement of bag _ of where Instances is sorted
and duplicate elements are removed .
The children relation is now easily expressed as
children (X , Kids ) +- set _ of ( C , father ( X , C ) , Kids ) .
Termination of the set - predicates depends on the termination of the goal
whose instances are being collected . The complete search tree for the goal must
be traversed . Hence , an infinite branch appearing in the search tree causes non -
termination .
Set - predicates can have multiple solutions . Consider the query set _ oj ( Y ,
father ( X , Y) , Kids ) ? There are a number of alternative solutions corresponding
to different values of X . For example , { X = terach , Kids = [ abraham , nachor , haran ]}

and { X = abraham , Kids = [ isaac ]} are equally valid solutions which should be given
on backtracking .
There is however another interpretation that can be given to the query

set_oj( Y,Lather(X , Y) ,Kids) 'I. It can be viewed as a request for all the chi 1-
dren in the program, irrespective of the father . The logical interpretation
is that Kids is the set of all values of Y such that there exists some X
where father (X , Y) is true . For the above data there is a single solution
Kids = [abraham , nachor ,haran , isaac , lot , milcah , yiscah ] . Extra notation is used to
distinguish this " existential " query from the backtrackable query . The accepted
form for the second type is is set _oJ( Y ,Xi (father (X , Y) ) , Kids ) . In general a query
Yi Goal means there exists a Y such that Goal .
Set - predicates may be nested . For example , all father -children relations
can be computed with the query set _oJ( Father - Kids ,set _oJ( X ,parent (Father ,
X) ;Kids ) , Y s) ? The solution is [terach - [ abraham , nachor ,haran ] , abraham - [ isaac ]
, haran - [ lot , milcah , yiscah ]] .
There are two possible ways to define the behavior of set _of( X , Goal ,Instances )
when Goal fails , i .e., has no true instances . We define set _of and bag_of to always
succeed , returning the empty list as the value of Instances when there are no
solutions to Goal . This definition assumes that the knowledge in the program is
all that is true . It is analogous to the approximation of negation by negation as
17.1 Set expressions 269
Set predicates
set_oj1(X ,Goal, Instances) +- Instances is the set of

instances of X for which Goal is true , if there are such .
set_of! (X ,Goal,Instances) +-
set_of(X ,Goal,Instances), Instances = [Ills ].
bag_oil (X , Goal,Instances) +- Instances is the multiset of
instances of X for which Goal is true , if there are such .
The multiplicity of an element is the number of
different ways Goal can be proved with it as an instance of X .
bag_of! (X ,Goal,Instances) +-
bag_of(X ,Goal,Instances), Instances = [Ills ].
size- oj( X , Goal,N) +- N is number of distinct
instances of X such that Goal is true .
size_of(X ,Goal,N) +- set_of(X ,Goal,Instances), length (Instances,N) .

length (Xs,N) +- SeeProgram 8.11.
Program 17 . 1: Set predicates
failure .
Versions of set- of and bag_of can be defined to fail when there are no solutions .
We call the new relations set_ofl and bag_ofl and give their definitions in Program
17 . 1 .
Many of the recursive procedures shown before can be rewritten using set-
predicates . For example , Program 7.9 for removing duplicates from a list of
elements can be defined simply in terms of testing for membership :
no_doubles(Xs,Ys) +- set_of(X ,member(X ,Xs),Ys).
This definition is significantly less efficient , however , than writing the recursive
procedure directly . It is true in general that recursive programs are more
efficient than using set predicates on current Prolog implementations .
Other second-order utility predicates can be defined using these basic set-
predicates . Counting the number of distinct solutions is possible with a program
size_oJ(X , Goal,N) which determines the number Nofsolutions of Xto a goal Goal..
It is given in Program 17.1. If there are no solutions to Goal, N is instantiated
to O. If the desired behavior of size_of was failure on no solutions , set- ofl can be
270 Second
-Order Programming 17.1
for _all( Goal, Condition)

For all solutions of Goal, Condition is true .
for_all (Goal,Condition ) +-
set - of ( Condition , Goal , Cases ) , check ( Cases ) .
check ( [ Case I Cases ] ) + - Case , check ( Cases ) .
check ( [ ] ) .
Program 17 . 2 : Applying set predicates
lind _ all _ dl ( X , Goal , Instances ) + - Instances is the multiset of
instances of X for which Goal is true . The multiplicity
of an element is the number of different ways Goal can be
proved with it as an instance of X .
find _ all _ dl ( X , Goal , Xs ) + -
assert a ( $ instance ( $ mark ) ) , Goal , assert a ( $ instance ( X ) ) , fail .
find _ all _ dl ( X , Goal , Xs \ Ys ) + -
retract ( $ instance ( X ) ) , reap ( X , Xs \ Ys ) , ! .
reap ( X , Xs \ Ys ) + -
X # $ mark , retract ( $ instance ( Xl ) ) , ! , reap ( Xl , Xs \ [ X I Ys ] ) .
reap ( $ mark , Xs \ Xs ) .
Program 17 . 3 : Impie I Ilenting a set predicate using difference - lists ,
assert and retract
used instead of set_of. A version using bag_of instead of set_of would count the
number of solutions with duplicates .
Another set utility predicate checks whether all solutions to a query satisfy
a certain condition . Program 17.2 defines a predicate for ".all ( Goal, Condition )
succeeding when Condition is true for all values of Goal. It uses the metavariable
facility .
The query for _all (father (X , O) ,male ( O) ) ? checks which fathers have only male
children . It produces two answers X = terach and X = abraham.
A simpler , more efficient but less general version of for _all can be written
without using set-predicates . A combination of nondeterminism and negation by
failure produces a similar effect . The definition is
for _all (Goal ,Condition ) +- not (Goal , not Condition ) .
It successfully answers a query such as for _all (father ( terach,X) ,male (X) ) ? but fails
17.2 Applications of set expressions 271
to give a solution to the query for _all(father(X , C) ,male( C) ) ?

We conclude this section by showing how to implement a simple variant of
bag- of. The discussion serves a dual purpose . It illustrates the style of implementation
for set-predicates , and gives a utility which will be used in the next section .
The predicate find _all_dl(X , Goal,Instances) is true if Instances is the bag (multiset
) of instances of X , represented as a difference-list , where Goal is true . The
procedure differs from bag- of by not backtracking to find alternative solutions .
The definition of find _all - dl is given as Program 17.3. The program can only
be understood operationally . There are two stages to the procedure , as specified
by the two clauses for find - all _dl. The explicit failure in the first clause guarantees
that the second will be executed . The first stage finds all solutions to Goal using
a failure - driven loop , asserting the associated X as it proceeds . The second stage
retrieves the solutions .
Asserting " $ mark" is essential for nested set-expressions to work correctly ,

lest one set would "steal " solutions produced by the other set-expression .
(i) Define the predicate intersect(Xs, Ys,Zs) using a set expression to compute
the intersection Zs of two lists Xs and Y s. What should happen if the two
lists do not intersect ? Compare the code with the recursive definition of
intersect .
17 .2 Applications of set expressions
Set expressions are a significant addition to Prolog . Clean solutions are obtained
to many problems by using set expressions , especially when other programming
techniques , discussed in previous chapters , are incorporated . This section
presents three example programs : traversing a graph breadth first , using the Lee
algorithm for finding routes in VLSI circuits , and producing a keyword in context
(KWIC ) index.
Section 14.2 presents three programs , 14.8, 14.9, and 14.10, for traversing a
graph depth first . We discuss here the equivalent programs for traversing a graph
breadth first . .
The basic relation is connected(X, Y) which is true if X and Yare connected.

Program 17.4 defines the relation . Breadth -first search is implemented by keeping
a queue of nodes waiting to be expanded . The connected clause accordingly calls
(1) Finite trees and DAGs

Pure Prolog
(2) Finite graphs
Pure prolog + negation
(3) Infinite graphs
Pure Prolog + second order + negation
Figure 17 .2 : Power of Prolog for various searching tasks
connected_bfs( Queue, Y) which is true if Y is in the connected component of the

graph represented by the nodes in the Queue.
Each call to connected_bfs remqves the current node from the head of the
queue, finds the set of edges connected to it , and adds them to the tail of the
queue. The queue is represented as a difference -list , and the set predicate used
is findall _dl. The program fails when the queue is empty . Because difference -lists
are an incomplete data structure , the test that the queue is empty must be made
explicitly . Otherwise the program would not terminate .
Consider the edge clauses in Program 17.4, representing the left -hand graph
in Figure 14.3. Using them , the query connected( a,X) ? gives the solutions b, c, d,
e, f , g, j , k, h, i , which is a breadth -first traversal of the graph .
Like Program 14.8, Program 17.4 correctly traverses a finite tree or a' directed
acyclic graph (DAG ) . If there are cycles in the graph , the program will not
terminate . Program 17.5 is an improvement over Program 17.4 where a list of
the nodes visited in the graph is kept . Instead of adding all the successor nodes
at the end of the queue, each is checked to see if it has been visited before . This
is performed by the predicate filter in Program 17.5.
Program 17.5 in fact is more powerful than its depth -first equivalent , Program
14.10. Not only will it correctly traverse any finite graph , it will correctly
traverse infinite graphs as well . It is useful to summarize what extensions to
pure Prolog have been necessary to increase the performance in searching graphs .
Pure Prolog correctly search es finite trees , and DAGs , Adding negation allows
correct searching of finite graphs with cycles , while set expressions are necessary
for infinite graphs . This is shown in Figure 17.2.
Calculating the path between two nodes is a little more awkward than for
depth -first search. It is necessary to keep with each node in the queue a list of
the nodes linking it to the original node . The technique is demonstrated in the
next chapter in Program 18.6.
The next example combines the power of nondeterministic programming with

connected(X , Y) +-
N ode X is connected to node Yin the DAG defined by edge
/ 2.
connected (X ,Y ) +- connected _bfs ( [X IXs ]\ Xs ,Y ) .
connected _bfs ( [ ] \ [ ] ,Y ) +- !,fail .

connected _bfs ( [X IXs ] \ Ys ,X ) .
connected _bfs ( [X I Xs] \ Y sY ) + -
find _all _dl (N,edge
(X,N),Ys\ Zs), connected
_bfs(Xs\ Zs,Y).
Data
edge ( a ,b ) . edge ( a ,c ) . edge ( aid ) . edge ( aie ) . edge ( f ,i ) .
edge ( c ,f ) . edge ( c ,g ) . edge ( f ,h ) . edge ( e ,k ) . edge ( dJ ) .
edge ( x ,y ) . edge (y ,z ) . edge ( z ,x ) . edge ( y ,u ) . edge ( z ,v ) .
Program 17 .4 : Testing connectivity breadth - first in a DAG
connected ( X , Y ) + -
Node X is connected to node Y in the graph defined by edge / f ?; .
connected ( X , Y ) + - connected ( [X I Xs ] \ Xs ,Y , [X ] ) .
connected ( [ ] \ [ ] ,Y , Visited ) + - ! , fail .
connected ( [A I Xs ] \ Y s , A , Visited ) .
connected ( [A I Xs ] \ Y siB , Visited ) + -
set _ of ( N , edge ( A , N ) , N s ) ,
filter ( Ns , Visited , Visitedl , Xs \ Ys , Xsl ) ,
connected ( Xsl , B , Visitedl ) .
filter ( ( NINs ] , Visited , Visitedl , Xs , Xsl ) + -
member ( N , Visited ) , filter ( N s , Visited , Visitedl , Xs , Xsl ) .
filter ( ( NINs ] , Visited , Xs \ ( N I Ys ] , Xs \ Ys ) + -
not member ( N , Visited ) , filter ( Ns , (N I Visited ] , Visitedl , Xs \ Ys , Xsl ) .
filter ( ( ] ,V , V , Xs , Xs ) .
Program 17 . 5 : Testing connectivity breadth first in a graph
the use of second - order programming . It is a program for calculating a minimal
cost route between two points in a circuit using the Lee algorithm .
The problem is formulated as follows . Given a grid that may have obstacles ,
find a shortest path between two specified points . Figure 17 . 3 shows a grid with
obstacles . The heavy solid line represents a shortest path between the two points
A and B . The shaded rectangles represent the obstacles .

. . . . . . . .
. . . .
. . .
. .
. . .
. . .
. .
Figure 17.3: The problemof Leerouting for VLSI circuits
We first formulate the problem in a suitable form for programming . The

VLSI circuit is modeled by a grid of points , conveniently assumed to be the upper
quadrant of the Cartesian plane . A route is a path between two points in the grid ,
along horizontal and vertical lines only ~subject to the constraints of remaining in
the grid and not passing through any obstacles .
Points in the plane are represented by their Cartesian coordinates and denoted
X - Y. In Figure 17.3, A is 1- 1 and B is 5- 5. This representation is chosen for
readability , and utilizes the definition of "- " as an infix binary operator . Paths are
calculated by the program as a list of points from B to A , including both endpoints .
In Figure 17.3 the route calculated is [5- 5,5- ;,,5- 3,5- 2,;,- 2,3- 2,2- 2,1- 2,1- lJ, and
17.2 Applicationsof set expressions 275
lee _ route ( Source , Destination , Obstacles , Path ) + -
Path is a minimal length path from Source to
Destination which does not cross Obstacles .
lee Joute ( A , BiObstacles , Path ) + -
waves ( B , [ [ A ] , 0 ] , Obstacles , Waves ) ,
path ( A , B , Waves , Path ) .
waves ( Destination , W aves So Far , Obstacles , Waves ) + -
Waves is a list of waves including Waves So Far
( except , perhaps , its last wave ) that leads to Destination
without crossing Obstacles .
waves ( B , ( Wave I Waves ] , Obstacles , Waves ) + - member ( B , Wave ) , I .
waves ( B , ( Wave , Last Wave I Last Waves ] , Obstacles , Waves ) + -
next _ wave ( Wave , Last Wave , Obstacles , Next Wave ) ,
waves ( B , ( Next Wave , Wave , Last Wavel Last Waves

] , Obstacles , Waves ) .
next _ wave ( Wave , Last Wave , Obstacles , Next Wave ) i0 -
Next Wave is the set of admissible points from Wave ,
that is excluding points from Last Wave ,
Wave and points under Obstacles .
next _ wave ( Wave , Last Wave , Obstacles , Next Wave ) + -
set _ of ( X , admissible ( X , Wave , Last Wave , Obstacles ) , Next Wave ) .
admissible ( X , Wave , Last Wave , Obstacles ) + -
adjacent ( X , Wave , Obstacles ) ,
not member ( X , Last Wave ) ,
not member ( X , Wave ) .
adjacent ( X , Wave , Obstacles ) + -
member ( Xl , Wave ) ,
neighbor ( Xl , X ) ,
not obstructed ( X , Obstacles ) .
neighbor ( Xl - Y , X2 - Y ) + - next _ to ( Xl , X2 ) .
neighbor ( X - Yl , X - Y2 ) + - next _ to ( Yl , Y2 ) .
next - to ( X , XI ) + - Xl : = X + I .
next _ to ( X , XI ) + - X > 0 , Xl : = X - I .
obstructed ( Point , Obstacles ) + -
member ( Obstacle , Obstacles ) , obstructs ( Point , Obstacle ) .
Program 17 . 6 : Lee routing

obstructs(X- Y ,obstacle(X- Yl ,X2- Y2)) +- Yl ~ Y, Y ~ Y2 .

obstructs(X- Y ,obstacle(Xl - Yl ,X- Y2)) +- Yl ~ Y, Y ~ Y2 .
obstructs(X- Y ,obstacle(Xl - Y ,X2- Y2)) +- Xl ~ X, X ~ X2 .
obstructs(X- Y ,obstacle(Xl - Yl ,X2- Y )) +- Xl ~ X, X ~ X2 .
path(Source,Destination, Waves,Path) +-
Path is a path from Source to Destination going through Waves.
path (A ,A ,Waves, [A]) +- !.

path (A ,B,[WaveIWaves],[BIPath]) +-
member(Bl ,Wave),
neighbor(B,B 1),
!, path (A ,Bl ,Waves,Path) .
Testing and data
test Jee(Name,Path) +-
data(Name,A ,BiObstacles), lee..route(A ,BiObstacles,Path).
data(test,1- 1,5- 5,[obstacle(2- 3,4- 5) ,obstacle(6- 6,8- 8)]) .
Program 17.6 (Continued)
is marked by the solid line .
The top level relation computed by the program is lee_route(A,BiObstacles,

Path) where Path is a route (of minimal distance) from point A to point B in
the circuit . Obstacles are the obstacles in the grid . The program has two stages.
First , successive waves of neighboring grid points are generated , starting from the
initial point , until the final point is reached . Second, the path is extracted from
the accumulated waves. Let us examine the various components of Program 17.6,
the overall program for Lee routing .
Waves are defined inductively . The initial wave is the list [A]. Successive
waves are sets of points that neighbor a point in the previous wave , and do not
already appear in previous waves. They are illustrated by the lighter solid lines
in Figure 17.3.
The wave generation is performed by the predicate waves(B, WavesSoFar,

Waves) which determine the list of Wavesto reach a destination B where Waves-
SoFar is an accumulator of the waves generated so far in traveling from the source .
The predicate terminates when the destination point is in the current wave . The
general case calls next_wave which uses a set expression to find all the appropriate
grid points .
input : programming in prolog

logic for problem solving
logic programming
algorithmic program debugging
output : algorithmic program debugging I,
debugging I algorithmic program,
logic for problem solving I,
logic programming I,
problem solving I logic for ,
program debugging I algorithmic ,
programming in prolog I,
programming I logic,
prolog I programming in ,
solving I logic for problem
Figure 17.4 Input and output for keyword in context problem
Obstacles are assumed to be rectangular blocks . They are represented by the

term obstacle(L,R) where L is the coordinates of the lower left-hand corner and
R the coordinates of the upper right -hand corner . An exercise at the end of the
section requires modifying the program to handle other obstacles .
The predicate find _path(A,B, Waves,Path) finds the path Path back from B
to A through the Waves generated in the process . Path is built downward which
means the order of the points is from B to A . This order can be changed by using
an accumulatorin find_path.
Program 17.6 produces no output while computing the Lee route . In practice
the user may like to see the computation in progress . This can be easily done by
adding appropriate write statements to the procedures next_wave and find _path .
Our final example in this section concerns the keyword in context problem
(KWIC ). Again a simple Prolog program, combining nondeterministic and second-
order programming , suffices to solve a complex task .
Finding keywords in context involves searching text for all occurrences of a

set of keywords extracting the contexts in which they appear . We consider here
the following variant of the general problem . "Given a list of titles , produce a
sorted list of all occurrences of a set of keywords in the titles , together with their
context ."
Sample input to a program is given in Figure 17. 4 together with the expected
output . The context is described as a rotation of the title with the end of the title
indicated by a " I " . In the example the keywords are algorithmic , debugging , logic ,
problem , program , programming , prolog and solving , all the ' non trivial ' words .
The relation we want to compute is kwic ( Titles J Kwic Titles ) where Titles is
the list of titles whose keywords are to be extracted , and Kwic Titles is the sorted
list of keywords in their contexts . Both the input and output titles are assumed
to be given as lists of words . A more general program , as a preliminary step ,
would convert freer form input into lists of words , and produce prettier output .
The program is presented in stages . The basis is a nondeterministic specification
of a rotation of a list of words . It has an elegant definition in terms of
append :
rotate ( Xs , Y s ) ~ append ( As , Bs , Xs ) , append ( Bs , As , Y s ) .
Declaratively , Ys is a rotation of Xs if Xs is composed of As followed by Bs , and
Ys is Bs followed by As . .
The next stage of development involves identifying single words as potential
keywords . This is done by isolating the word in the first call to append . Note that
the new rule is an instance of the previous one :
rotate ( Xs , Ys ) + - append ( As , [ Key I Bs ] , Xs ) , append ( [ Key I Bs ] , As , Ys ) .
This definition also improves the previous attempt by removing the duplicate
solution when one of the split lists is empty , and the other is the entire list .
The next improvement involves examining a potential keyword more closely .
Suppose each keyword Word is identified by a fact of the form keyword ( Word ) .
The solutions to the rotate procedure can be filtered so that only words identified
as keywords are accepted . The appropriate version is
rotate _ and ~ ter ( Xs , Y s ) + -
append ( As , { Key I Bs ] , Xs ) , keyword ( Key ) , append ( [ Key I Bs ] , As , Ys ) .
Operationally rotate _ and - filter considers all keys , filtering out the unwanted alternatives
. The goal order is important here to maximize the program efficiency .
In Program 17 . 7 , the final version , a complementary view to recognizing
keywords is taken . Any word Word is a keyword unless otherwise specified by
a fact of the form insignificant ( Wora ) . Further the procedure is augmented to
insert the end of title mark " I " , providing the context information . This is done by
adding the extra symbol in the second append call . Incorporating this discussion
yields the clause for Totate _ and - filter in Program 17 . 7 .
Finally , a set - predicate is used to get all the solutions . Quantification is
necessary over all the possible titles . Advantage is derived from the behavior of
kwic( Titles,K WTitles) +-

K WTitlesis a KWIC index of the list of titles Titles.
kwic(Titles,K WTitles) +-
set_of(Y s,Xsj (member(Xs,Titles) ,rotate_and-filter(Xs,Ys)) ,K WTitles).
rotate-and-filter (Xs, Ys) +--
Y s is a rotation of the list Xs , such that
the first word of Ys is significant, and a ' I'
is inserted after the last word of Xs .
rot at e_and-.filter (Xs,Y s) +-

append(As,[Key IBs],Xs) ,
not insignificant (Key),
append( [Key,' I' IBs] ,As,Y s).
Vocabulary of insignificant words
insignificant (a) . insignificant (the) .

insignificant (in) . insignificant (for) .
Testing and data
test~ wic (Books,Kwic ) +-

titles (Books,Titles ), kwic (Titles ,K wic).
titles (lp ,[[logic,for ,problem,solving],
[logic,programming] ,
[algorithmic ,program,debugging] ,
[programming,in ,prolog]]) .
Program 17 .7 : Producing a KWIC index
set-of in sorting the answers. The complete program is given as Program 17.7,
and is an elegant example of the expressivepower of Prolog. The test predicate
is test_kwic/ 2.
(i) Modify Program 17.6 to handle obstacles specified differently than as rect-
angles.
(ii ) Adapt Program 17.7 for KWIC so that it extracts keywords from lines of
text .
(iii ) Write a program to find a minimal spanning tree for a graph.

(iv ) Write a program to find the maximum flow in a network design using the
Ford - Fulkerson algorithm .
17 .3 Other second - order predicates
First -order logic allows quantification over individuals . Second-order logic

further allows quantification over predicates . Incorporating this extension in logic
programming entails using rules with goals whose predicate names are variables .
Predicate names become "first -class" data objects to be manipulated and modi -
fied .
A simple example of a second-order relation is the determination of whether

all members of a list have a certain property. For simplicity the property is assumed
to be described as a unary predicate. Let us define has_property(Xs,P)
which is true if each element of Xs has some property P. Extending Prolog syntax
to allow variable predicate names enables us to define has_property as in Figure
17.5. Because has_property allows variable properties , it is a second-order predicate
. An example of its use is testing whether a list of people Xs is all male with
a query has_property(Xs,male) ?
Another second-order predicate is map_list (Xs,P, Ys). Ys is the map of the
list Xs under the predicate P. That is, for each element X of Xs there is a corresponding
element Yof Ys such that P(X, Y) is true . The order of the elements
in Xs is preserved in Ys. We can use map_list to rewrite some of the programs of
earlier chapters . For example , Program 7.8 mapping English to French words can
be expressedas map_list( Words,dict,Mots) . As for has_property, map_list is easily
defined using a variable predicate name . The definition is given in Figure 17.5.
Operationally , allowing variable predicate names implies dynamic construction
of goals while answering a query . The relation to be computed is not fixed
statically when the query is posed, but is determined dynamically during the
computation .
Some Prologs allow the programmer to use variables for predicate names ,
and allow the syntax of Figure 17.5. It is unnecessary to complicate the syntax
however . The tools already exist for implementing second-order predicates . One
basic relation is necessary, which we call apply; it constructs the goal with a
variable functor . The predicate apply is defined by a set of clauses, one for each
functor name and arity . For example , for functor foo of arity n, the clause is
apply(foo,Xl ,. . .,Xn ) +- foo(Xl ,. . .,Xn ).

17.3 Other second-order predicates 281
has_property ( Xs ,P) +-
Each element in the list Xs has property P.
has_property ([X I Xs],P) +-
apply(P,X ), has_property (Xs,P).
has_property ( [ ],P).
apply(male,X ) +- male(X ).
maplist(Xs,P, Ys) +-
Each element in the list Xs stands in relation
P to its corresponding element in the list Y s.
mapJist ([X IXs],P,[YIYs]) +-

apply(P,X ,Y ), maplist (Xs,P,Y s).
mapJist ([ ],P,[ ]).
apply(dict ,X ,Y ) +- dict (X ,Y ) .
Program 17 . 8 : Secondorder predicates in Prolog
has_property ([X IXs] ,P) +- P(X ), has_property (Xs,P).

has_property ([ ],P).
map.list ([X IXs],P,[YIYs]) +- P(X ,Y ), map.Jist(Xs,P,Ys).
mapJist ([ ],P,[ ]).
Figure 17 .5 : Second-order predicates
The two predicates in Figure 17.5 are transformed into standard Prolog in Program
17.8. Sample definitions of apply clauses are given for the examples mentioned
in the text .
The predicate apply performs structure inspection . The whole collection of

apply clauses can be generalized by using the structure inspection primitive , univ .
The general predicate apply(P,Xs) applies predicate P to a list of arguments Xs:
apply(F ,Xs) +- Goal = .. [FIXs], Goal.
We can generalize the function to be applied from a predicate name , i .e.,

an atom, to a term parameterized by variables. An example is substituting
for a value in a list . The relation substitute/ ;' from Program 9.3 can be
viewed as an instance of map_list if a parameterization is allowed . Namely
map_list(Xs,substitute(Old,New), Ys) has the same effect in substituting the element
New for the element Old in Xs to get Ys - exactly the relation computed
282 Second- Order Programming 17.3
by Program 9.3. In order to handle this correctly the definition of apply must be
extended a little as below :
apply(P,Xs) +-
P = .. Ll , append(Ll ,Xs,L2), Goal = .. L2, Goal.
Using apply as part of map_list leads to inefficient programs . Forexampleus -

ing substitute directly rather than through maplist results in far less intermediate
structures being created , and eases the task of compilation . Hence these second-
order predicates are better used in conjunction with a program transformation
system that can translate second-order calls to first -order calls at compile -time .
The predicate apply can also be used to implement lambda expressions . A
lambda expressionis one of the form lambda(xi ,. . .,Xn ).Expression. If the set of
lambda expressions to be used are known in advance , they can be named . For
example , the above expression would be replaced by some unique identifier , foo
say, and defined by an apply clause:
apply(foo,Xl ,. . .,Xn ) i - Expression.
Although possible both theoretically and pragmatically , the use of lambda

expressions and second-order constructs such as has-property and maplist is not
widespread as in functional programming languages such as Lisp . We conjecture
that this is a combination of cultural bias and the availability of a host of alternative
programming techniques . It is possible that the active ongoing work on
both extending the logic programming model with higher -order constructs , and
integrating it with functional programming , will change the picture .
In the meantime , set expressions seem to be the main and most useful higher -
order construct in Prolog .
17 .4 Background
An excellent , detailed account of set predicates in Prolog - tO is given by Warren

(l982a ) . He explains their basic logical properties . Our presentation differs
from Warren 's in the choice of set_of as the basic set predicate , rather than set_ofl
(called setofin Prolog - tO) .
Set predicates are a powerful extension to Prolog . They can be used (inefficiently
) to implement negation as failure , and metalogical type predicates
(Kahn , 1984) . If a goal G has no solutions , which is determined by a predicate
such as set_of, then not Gis true . The predicate var (X ) is implemented by testing
whether the goal X = 1;X = 2has two solutions . Further discussion of such behavior
17.4 Background 283
of set-predicates , aJ1d a survey of different implementations of set predicates can

be found in Naish (19S5b).
Further description of the Lee algorithm , and the general routing problem
for VLSI circuits can be found in textbooks on VLSI , for example , Breuer and
Carter (1983).
KWIC was posed as a benchmark for ~igh -level programming languages by
Perlis , and was used to compare several languages . We find the Prolog implementation
of it perhaps the most elegant of them all .
Our description of lambda expressions is modeled after Warren (19S2a).

Predicates such as apply and map_list were part of the utilities package at the
University of Edinburgh . They were fashionable for a while , but fell out of favor
because they were not compiled efficiently , and no source- to -source transformation
tools were available .
Chapter 18
Search Techniques
In this chapter we show programs encapsulating classic AI search techniques .

The first section discuss es state -transition frameworks for solving problems formulated
in terms of a state -space graph . The second discuss es the minimax algorithm
with alpha -beta pruning for searching game trees .
18 . 1 Searching state - space graphs
State -space graphs are used to represent problems . Nodes of the graph are
states of the problem . An edge exists between nodes if there is a transition rule ,
also called a move, transforming one state into the next . Solving the problem
means finding a. path from a given initial state to a desired solution state by
applying a sequence of transition rules .
Program 18.1 is a framework for solving problems by searching their state -
space graphs , using depth -first search as described in Section 14.2.
No commitment has been made to the representation of states . The moves are
specified by a binary predicate move(State ,Move ) where Move is a move applicable
to State . The predicate update(State ,Move ,Statel ) finds the state Statel reached
by applying the move Move to state State . It is often easier to combine the
move and update procedures . We keep them separate here to make knowledge
more explicit , and retain flexibility and modularity possibly at the expense of
performance .
The validity of possible moves is checked by the predicate legal(State) which
checks if the problem state State satisfies the constraints of the problem . The
program keeps a history of the states visited to prevent looping . Checking that
looping does not occur is done by seeing if the new state appears in the history
18.1 Searching state -space graphs 285
solve_dfs(State ,History ,Moves) +-

Moves is the sequence of moves to reach a
desired final state from the current State ,
where History contains the states visited previously .
solve-dfs(State,History ,( )) +-
final ..state(State).
solve_dfs(State,History ,(MoveIMoves)) +-
move(State,Move),
update(State,Move,State1),
legal(Statel ),
not member(Statel ,History ),
solve_dfs(Statel ,(Statel IHistory ),Moves).
Testing the framework
test_dfs(Pro blem,Moves) +-
initial -state(Problem,State), solve_dfs(State,[State] ,Moves).
Program 18.1: A depth-first state-transition framework for
problem solving
of states . The sequence of moves leading from the initial state to the final state
is built incrementally in the third argument of solve_dfs/ 9.
To solve a problem using the framework , the programmer must decide how
states are to be represented , and axiomatize the move, update and legal procedures .
A suitable representation has profound effect on the success of this framework .
Let us use the framework to solve the wolf , goat and cabbage problem . We
state the problem informally . A farmer has a wolf , goat , and cabbage on the left
side of a river . The farmer has a boat that can carry at most one of the three ,
and he must transport this trio to the right bank . The problem is that he dare
not leave the wolf with the goat (wolves love to eat goats ) or the goat with the
cabbage (goats love to eat cabbages) . He takes all his jobs very seriously and does
not want to disturb the ecological balance by losing a passenger .
States are represented by a triple wgc(B ,L ,R) where B is the position of the
boat (left or right ) , L is the list of occupants of the left bank , and R the occupants
of the right bank . The initial and final states are wgc(leJt,[wolJ,goat, cabbage],[ ])
and wgc(right ,[ ], [wolJ, goat, cabbage]) , respectively . In fact , it is not strictly necessary
to keep the occupants from both the left and right banks . The occupants
from the left bank can be deduced from the occupants of the right bank , and vice
versa . Having both makes specifying moves clearer .
286 SearchTechniques 18.1
States for the wolf , goat and cabbage problem are a structure
wgc ( Boat , Left , Right ) , where Boat is the bank where the boat
currently is , Left is the list of occupants on the left bank of
the river , and Right is the list of occupants of the right bank .
initial - atate ( wgc , wgc ( left , [ wolf , goat , cabbage ] , [ ] ) ) .
final - atate ( wgc ( right , [ ] , [ wolf , goat , cabbage ] ) ) .
move ( wgc ( left , L , R ) , Cargo ) + - member ( Cargo , L ) .
move ( wgc ( right , L , R ) , Cargo ) + - member ( Cargo , R ) .
move ( wgc ( B , L , R ) , alone ) .
update ( wgc ( B , L , R ) , Cargo , wgc ( Bl , Ll , Rl ) ) + -
update _ boat ( B , Bl ) , update _ banks ( Cargo , B , L , R , L 1 , Rl ) .
update_boat (left ,right ).

update_boat (right ,left ).
update_banks(alone,B ,L ,R,L ,R).
update_banks(Cargo,left ,L ,RiLl ,Rl ) +-
select(Cargo,LiLl ) , insert (Cargo,R,Rl ).
update_banks(Cargo,right ,L ,RiLl ,Rl ) +-
select(Cargo,R,Rl ), insert (Cargo,LiLl ).
insert ( X , [ YIY s ] , [X , YIY s]) +-
precedes ( X ,Y ) .
insert ( X , [YIYs ] , [YIZs ]) +-
precedes ( Y ,X ) , insert ( X , Y siZs ) .
insert ( X , [ ] , [X ] ) .
precedes(wolf ,X ) .
precedes (X ,cabbage) .
legal ( wgc ( left , L , R ) ) + - not illegal ( R ) .
legal ( wgc ( right , L , R ) ) + - not illegal ( L ) .
illegal ( L ) + - member ( wolf , L ) , member ( goat , L ) .
illegal ( L ) + - member ( goat , L ) , member ( cabbage , L ) .
Program 18 . 2 : Solving the wolf , goat , and cabbage problem
It is convenient for checking for loops to keep the lists of occupants sorted .
Thus wolf will always be listed before goat , both of whom will be before cabbage
if they are on the same bank .
Moves transport an occupant to the opposite bank , and can thus be specified
u .0
8litres
5litres
41it
Figure 18.1: The water jugs problem
by the particular occupant who is the Cargo. The case when nothing is taken is
specified by the cargo alone. The nondeterministic behavior of member allows a
concise description of all the possible moves in three clauses: for moving something
from the left bank , from the .right bank , or for the farmer rowing in either direction
by himself , as shown in Program 18.2.
For each of these moves, the updating procedure must be specified , namely
changing the position of the boat (by update_boat/ f ), and updating the banks
(by update_banks). Using the predicate select allows a compact description of
the updating process. The update_banks/ 3 procedure is necessary to keep the
occupant list sorted , facilitating the check if a state has been visited before . It
contains all the possible cases of adding an occupant to a bank .
Finally , the test for legality must be specified . The constraints are simple .
The wolf and goat cannot be on the same bank without the farmer , nor can the
goat and cabbage .
Program 18.2 collects together the facts and rules needed to solve the wolf ,
goat cabbage problem in addition to Program 18.1. The clarity of the program
speaks for itself .
We use the state -transition framework for solving another classic search problem
from recreational mathematics - the water jugs problem . There are two jugs
of capacity 8 and 5 liters with no markings , and the problem is to measure out
exactly 4 liters from a vat containing 20 liters (or some other large number). The
possible operations are filling up a jug from the vat , emptying a jug into the vat ,
and transferring the contents of one jug to another until either the pouring jug is
emptied completely , or the other jug is filled to capacity . The problem is depicted
in Figure 18.1.
The problem can be generalized to Njugs of capacity Cl ," ., CN . The problem
is to measure a volume V, different from all the ai 'S but less than the largest .
288 Search Techniques 18.1
initial . . . state ( jugsjugs ( O , O ) ) .
final . . . state ( jugs ( 4 , V2 ) ) .
final - Btate ( jugs ( Vl , 4 ) .
move ( jugs ( V 1 ,V 2 ) , illl ( 1 ) ) .
move ( jugs ( Vl , V2 ) , fill ( 2 ) ) .
move ( jugs ( VI , V2 ) , empty ( I ) ) + - VI > O .
move ( jugs ( Vl , V2 ) , empty ( 2 ) ) + - V2 > O .
move ( jugs ( Vl , V2 ) , transfer ( 2 , 1 ) ) .
move ( jugs ( VI , V2 ) , transfer ( I , 2 ) ) .
update ( jugs ( Vl , V2 ) , empty ( l ) jugs ( 0 , V2 ) ) .
update ( jugs ( Vl , V2 ) , empty ( 2 ) , jugs ( Vl , O ) ) .
update ( jugs ( Vl , V2 ) , illl ( l ) jugs ( 01 , V2 ) ) + - capacity ( I , OI ) .
update ( jugs ( Vl , V2 ) , fill ( 2 ) jugs ( Vl , C2 ) ) + - capacity ( 2 , C2 ) .
update ( jugs ( Vl , V2 ) , transfer ( 2 , 1 ) jugs ( Wl , W2 ) ) + -
capacity ( I , OI ) ,
Liquid : = VI + V2 ,
Excess : = Liquid - 01 ,
adjust ( Liquid , Excess , WI , W2 ) .
update ( jugs ( Vl , V2 ) , transfer ( I , 2 ) . jugs ( Wl , W2 ) ) + -
capacity ( 2 , 02 ) ,
Liquid : = VI + V2 ,
Excess : = Liquid - 02 ,
adjust ( Liquid , Excess , W2 , WI ) .
adjust ( Liquid , Excess , Liquid , O ) + - Excess ~ O .
adjust ( Liquid , Excess , V , Excess ) + - Excess > 0 , V := Liquid - Excess.

legal ( jugs ( VI , V2 ) ) .
capacity ( I , 8 ) .
capacity ( 2 , 5 ) .
Program 18 . 3 : Solving the water jugs problem
There is a solution if V is a multiple of the greatest common divisor of the Ci 'S.

Our particular example is solvable because 4 is a multiple of the greatest common
divisor of 8 and 5.
The particular problem we solve is for two jugs of arbitrary capacity , but
the approach is immediately generalizable to any number of jugs . The program
assumes two facts in the database , capacity ( I , OJ) , for I equals 1 and 2. The
natural representation of the state is a structure J.ugs( Vl , V2) where Vl and V2
represent the volumes of liquid currently in the two jugs , The initial state is
juys (O, O) and the desired fInal state either J'uys(O,X) or juys (X ,O) , where Xis the
desired volume , Assuming that the first jug has larger capacity , only one final
state juys (X ,O) need be specified , since it is easy to transfer the required amount
from the second jug to the first , by emptying the first jug , then transferring to it
the contents of the second jug ,
The data for solving the jugs problem in conjunction with Program 18.1 are
given as Program 18.3. There are six moves: filling each jug , emptying each jug ,
and transferring the contents of one jug to another . A sample fact for filling the
first jug is move(jugs ( Vl , V2) ,jill (1)) . The jugs ' state is given explicitly to allow
the data to co-exist with other problem solving data such as in Program 18.2.
The emptying moves are optimized to prevent emptying an already empty jug .
The updating procedure associated with the first four moves is simple , while the
transferring operation has two cases. If the total volume in the jugs is less than
the capacity of the jug being filled , the pouring jug will be emptied and the other
jug will have the entire volume . Otherwise the other jug will be filled to capacity
while the difference between the total liquid volume and the capacity of the filled
jug will be left in the pouring jug . This is achieved by the predicate adjust / 4.
Note that the test for legality is trivial since all reachable states are legal .
Most interesting problems have too large a search space to be searched ex-
haustively by a program such as 18.1. One possibility for improvement is to put
more knowledge into the moves allowed . Solutions to the jug problem can be
found by filling one of the jugs whenever possible , emptying the other whenever
possible , and otherwise transferring the contents of the jug being filled to the jug
being emptied . Thus instead of six moves only three need be specified , and the
search will be more direct , because only one move will be applicable to any given
state . This may not give an optimal solution if the wrong jug to be constantly
filled is chosen.
Developing this point further , the three moves can be coalesced into ahigher -
level move , fill _and_transfer . This tactic ffils one jug and transfers all its contents
to the other jug , emptying the other jug as necessary. The code for transferring
from the bigger to the smaller jug is
move(jugs(Vl ,V2 ),fill _and_transfer (1)).

update(jugs(Vl ,V2),fill -and_transfer(1),jugs(O,V )) +-
capacity(l ,Cl ),
capacity
(2,C2),
Cl > C2,
V := (Cl+V2) modC2.
Using this program only three fill and transfer operations from one jug to
the other are necessary to solve the problem in Figure 18.1.
Adding such domain knowledge means changing the problem descriptionen -

tirely , and constitutes programming , although at a different level .
Another possibility for improvement of the search performance , investigated

by early research in AI , is heuristic guidance . A general framework , based on a
more explicit choice of the next state to search in the state space graph , is used.
The choice depends on numeric scores assigned to positions . The score, computed
by an evaluation function , is a measure of the goodness of the position . Depth -first
search can be considered as a special case of searching using an evaluation function
whose value is the distance of the current state to the initial state , while breadth -
first search uses an evaluation function which is the inverse of that distance .
We show two search techniques that use an evaluation function explicitly : hill
climbing and best -first search. In the following , the predicate value(State , Value)
is an evaluation function . The techniques are described abstractly .
Hill climbing is a generalization of depth -first search where the successor position
with the highest score is chosen rather than the leftmost one chosen by
Prolog . No change is necessary to the top -level framework of Program 18.1. The
hill -climbing move generates all the states that can be reached from the current
one in a single move using set_of, and then orders them in c;iecreasing order with
respect to the values computed by the evaluation function . The predicate evaluate
_and_order (Moves ,State ,MVs ) determines the relation that MVs is an ordered
list of move-value tupies corresponding to the list of moves Moves from a state
State . The overall program is given as Program 18. 4.
To demonstrate the behavior of the program we use the example tree of

Program 14.8 augmented with a value for each move . This is given as Program
18.5. Program 18.4 combined with Program 18.5, together with the necessary
definitions of update and legal search es the tree in the order d, j . The program
is easily tested on the wolf , goat , and cabbage problem using as the evaluation
function the number of occupants on the right bank .
Program 18.4 contains a repeated computation . The state reached by Move

is calculated in order to reach a value for the move , and then recalculated by
update. This recalculation can be avoided by adding an extra argument to move
and keeping the state along with the move and the value as the moves are ordered .
Another possibility if there will be many calculations of the same move is using
a memo-function . What is the most efficient method depends on the particular
problem . For problems where the update procedure is simple , the program as
presented will be best .
solve_hill _climb(State,History ,Moves) f -

Moves is the sequence of moves to reach a
desired final state from the current State ,
where History are the states visited previously .
solve.l1ill_climb(State,History ,[ ]) +-
final-8tate(State).
solve.l1ill_climb(State,History ,[MoveI Moves)) +-
hill _climb (State,Move),
update(State,Move,State1),
legal(Statel ),
not member(Statel ,History ),
solve.l1ill_climb(Statel , [Statel IHistory ),Moves).
hill _climb(State,Move) +-
set_of(M ,move(State,M ),Moves),
evaluate_and_order(Moves,State,[ ] ,MV s),
member((Move,Value),MVs).
evaluate_and_order(Moves,State,SoFar, OrderedM Vs) fAll
the Moves from the current State
are evaluated and ordered as Ordered Moves .
SoFar is an accumulator for partial computations .
evaluate-arid_order ([MovelMoves] ,State,MV s,OrderedM V s) +-

update(State,Move,State1) ,
value(State1,Value),
insert ( (Move,Value) ,MV s,MV sl ),
evaluate_and-order(Moves,State,MV sl ,OrderedM V s).
evaluate_and_order([ ] ,State,MV s,MV s).
insert (MV ,[ ],[MV ]).
insert ( (M ,V ), [(MI ,VI ) IMV s],[(M ,V )',(MI ,VI ) IMV s]) i -
V 2:: VI .
insert ((M ,V ) ,[(MI ,VI ) IM Vs],[(MI ,VI ) IM Vs I]) i -
V < VI , insert ((M ,V ),MVs ,MVsI ).
Testing the framework
test-lill _climb (Pro blem,Moves) +-

initial ..state(Problem,State), solve(State, [State] ,Moves) .
Program 18 .4 : Hill -climbing problem solving framework
initial ..state (tree ,a) . value ( a,O) . final ..state (j ) .
move (a,b) . value (b ,l ) . move (c,g) . value (g,6) .

move ( a,c) . value (c,5) . move ( dj ) . value (j ,9) .
move (aid ) . value (d ,7) . move (e,k ) . value (k ,l ) .
move (aie) . value (e,2) . move (f ,h ) . value (h ,3) .
move (c,f ) . value (f ,4) . move (f ,i ) . value (i ,2) .
Program 18 .5: Test data
Hill climbing is a good technique when there is only one hill and the evaluation
function is a good indication of progress . Essentially , it takes a local look at the
state space graph , making the decision on where next to search on the basis of
the current state alone .
An alternate search method , called best-first search, takes a global look at

the complete state space. The best state from all those currently unsearched is
chosen.
Program 18 .6 for best -first search is a generalization of breadth -first search

given in Section 17 .2 . A frontier is kept as for breadth -first search , which is added
to as the search progress es. At each stage the next best available move is made .
We make. the code as similar as possible to Program 18 . 4 for hill - climbing to allow
comparIson .
At each stage of the search there is a set of moves to consider rather than
a single one . The plural predicate names , for example , updates and legals , indicate
this . Thus legals ( States , Statesl ) filters a set of successor states checking
which ones are allowed by the constraints of the problem . One disadvantage of
breadth - first search ( and hence best -first search ) is that the path to take is not
as conveniently calculated . Each state must store explicitly with it the path used
to reach it . This is reflected in the code .
Program 18 .6 tested on the data of Program 18 .5 search es the tree in the

same order as for hill climbing .
Program 18 .6 makes each step of the process explicit . In practice it may be

more efficient to combine some of the steps . When filtering the generated states ,
for example , it can be tested that a state is new and also legal at the same time .
This saves generating intermediate data structures . Program 18 .7 illustrates the
idea by combining all of the checks into one procedure , update -frontier .
18.1 Searchingstate-space graphs 293
solve_best(Frontier ,History,Moves) +-
Moves is the sequence of moves to reach a desired final state from
the initial state , where Frontier contains the current states under
consideration , and History contains the states visited previously .
solve_best([state(State,Path ,Value) IFrontier] ,History ,Moves) i -

final -Btate(State), reverse(Path ,Moves).
solve_best( [state(State,Path ,Value) IFrontier] ,History ,Fina IPath) i -
set_of(M ,move(State,M ) ,Moves),
updates(Moves,Path ,State,States),
legals(States,States1),
news(States1,History,States2),
evaluates(States2,Values),
inserts(Values,Frontier ,Frontier 1) ,
solve-best(Frontier 1,[StateIHistory ] ,Fina IPath).
updates(Maves, Path, State, States) +-
States is the list of possible states accessible from the
current State , according to the list of possible Maves ,
where Path is a path from the initial node to State .
updates([MIMs],Path ,S,[(Sl ,[MIPath ]) ISs]) +-

updateS ,M ,Sl ), updates(Ms,PathiS,Ss).
updates([ ],Path ,State,[ ]).
legals(States,States1) +-
States1 is the subset of the list of States that are legal .
legals([(S,P) IStatesS ,P)IStatesl ]) +-

legal(S), legals(States,Statesl ).
legals([(S,P) IStates],Statesl ) +-
not legal(S), legals(States,Statesl ).
legals([ ],[ ]).
news(States,History,Statesl) +-
Statesl is the list of states in States but not in History .
news([(S,P)IStates],History ,Statesl ) +-
memberS ,History ), news(States,History ,Statesl ).
news([(S,P)IStates],HistoryS ,P) IStatesl ]) +-
not memberS ,History ), news(States,History ,Statesl ).
news([ ] ,History ,[ ]).
Program 18 .6 : Best -first problem -solving framework
evaluates ( States , Values )
Values is the list of tupies of States augmented by their value .
evaluates ( [ ( S , P ) I States ] , [state ( SiP , V ) I Values ]) +-
value ( S , V ) , evaluates ( States , Values ) .
evaluates ( [ ],[ ]) .
inserts ( States , Frontier , Frontier 1 ) +-
Frontier1 is the result of inserting States into the current Frontier .
inserts ( [ Value I Values ] , Frontier , Frontierl ) +-
insert ( Value , Frontier , Frontier O) ,
inserts ( Values , Frontier O , Frontier 1) .
inserts ( [ ] , Frontier , Frontier ) .
insert ( State , [ ] , [ State ]) .
insert ( State , [ Statell States ] , [ State , Statel I States ]) +-
less _ than ( Statel , State ) .
insert ( State , [ Statel I States ] , [ State IStates ]) +-
equals ( State , Statel ) .
insert ( State , [ Statel I States ] , [ Statel I Statesl ]) +-
less _ than ( State , Statel ) , insert ( State , States , Statesl ) .
equals ( state ( SiP , V ) , state ( S , Pl ,V ) ) .
less _than ( state ( SI , Pl , Vl ) , state ( S2 , P2 , V2 ) ) +- 81 # S2 , VI < V2 .
Program 18 .6 ( Continued )
(i) Redo the water jugs program based on the two fill - aIld _transfer operations .
( ii ) Write a program to solve the missionaries and cannibals problem :
Three missionaries and three cannibals are standing at the left bank of a
river . There is a small boat to ferry them across with enough room for only
one or two people . They wish to cross the river . If ever there are more
missionaries than cannibals on a particular side of the river , the missionaries
will convert the cannibals . Find a series of ferryings to transport safely all
the missionaries and cannibals across the river without exposing any of the
cannibals to conversion .
(iii) Five jealous husbands ( Dudeney , 1917 ) :
During a certain flood five married couples found themselves surrounded by

solve _ best ( Frontier , History , Moves ) + -
Moves is the sequence of moves to reach a desired final state
from the initial state . Frontier contains the current states
under consideration . History contains the states visited previously .
solve _ best ( [ state ( State , Path , Value ) I Frontier ] , History , Moves ) + -
final - Btate ( State ) , reverse ( Path , [ ] , Moves ) .
solve - best ( [ state ( State , Path , Value ) I Frontier ] , History , Final Path ) + -
set _ of ( M , move ( State , M ) , Moves ) ,
update Jrontier ( Moves , State , Path , History , Frontier , Frontier 1 ) ,
solve _ best ( Frontier 1 , [ State I History ] , Final Path ) .
update Jrontier ( [ MIMs ] , State , Path , History , F , Fl ) + -
update ( State , M , Statel ) ,
legal ( Statel ) ,
value ( Statel , Value ) ,
not member ( State 1 , History ) ,
insert ( ( Statel , [ MIPath ] , Value ) , F , FO ) ,
update Jrontier ( Ms , State , Path , History , FO , F 1 ) .
update Jrontier ( [ ] , SiP , H , F , F ) .
insert ( State , Frontier , Frontierl ) + - See Program 18 . 6 .
Program 18 . 7 : Concise best - first problem solving framework
water , and had to escape from their unpleasant position in a boat that would
only hold three persons at a time . Every husband was so jealous that he
would not allow his wife to be in the boat or on either bank with another
man ( or with other men ) unless he was himself present . Find a way of getting
these five men and their wives across into safety .
( iv ) Compose a general problem solving framework built around breadth - first
search analogous to Program 18 . 1 , based on programs in Section 17 . 2 .
( v ) Express the eight queens puzzle within the framework . Find an evaluation
function .
18 . 2 Searching game trees
What happens when we playa game ? Starting the game means setting up
the chess pieces , dealing out the cards , or setting out the matches , for example .
Once it is decided who plays first , the players take it in turns to make a move .
Mter each move the game position is updated accordingly .
We develop the vague specification in the previous paragraph into a simple
framework for playing games . The top level statement is
play ( Game , Result ) + -
initialize ( Game , Position , Player ) ,
display ( Position , Player ) ,
play ( Position , Player , Result ) .
The predicate initialize ( Game , Position , Player ) determines the initial game position
Position for Game , and Player , the player to start .
A game is a sequence of turns , where each turn consists of a player choosing
a move , the move being executed , and the next player being determined . The
neatest way of specifying this is as a tail recursive procedure , play , with three
arguments : a game position , a player to move and the final result . It is convenient
to separate the choice of the move by choose - move / Sfrom its execution by move / So
The remaining predicates in the clause below display the state of the game , and
determine the next player :
play ( Position , Player , Result ) ~
choose - nlove ( Position , Player , Move ) ,
move ( Move , Position , Positionl ) , .
display _ game ( Positionl , Player ) ,
next _ player ( Player , Player 1 ) ,
! , play ( Position 1 , Player 1 , Result ) .
Program 18.8 provides a logical framework for game- playing programs . Using
it for writing a program for a particular game focuses attention on the important
issues for game-playing : what data structures should be used to represent the
game position , and how strategies for the game should be expressed . We demonstrate
the process in Chapter 20 by writing programs to play Nim and Kalab .
The problem -solving frameworks of the previous section are readily adapted
to playing games. Given a particular game state , the problem is to find a path of
moves to a winning position .
A game tree is similar to a state -space graph . It is the tree obtained by
identifying states with nodes and edges with player 's moves. We do not , however ,
identify nodes on the tree , obtained by different sequence of moves, even if they
repeat the same state . In a game tree , each layer is called a ply .
Most game trees are far too large to be searched exhaustively . This section
discuss es the techniques that have been developed to cope with the large search
play( Game) +-
Play game with name Game.
play(Game) ~
initialize (Game,Position,Player),
display_game(Position,Player),
play (Position,Player,Result).
play (Position ,Player ,Result ) +-
game_over (Position ,Player ,Result ) , !, announce (Result ) .
play (Position ,Player ,Result ) +-
chooseJD. ove(Position ,Player ,Move ) ,
move (Move ,Position ,Positionl ) ,
display _game (Positionl ,Player ) ,
next _player (Player ,Playerl ) ,
!, play (Positionl ,Playerl ,Result ) .
Program 18 .8 : Framework for playing games
evaluate _and_choose( Moves,Position ,Record, B estMove ) +-

Chooses the Best Move from the set of Moves from the
current Position , Record records the current best move .
evaluate - and_choose( (Move IMoves ] ,Position ,Record ,Best Move ) +-

value (Positionl ,Value ) ,
update (Move ,Value ,Record ,Recordl ) ,
evaluated _choose(Moves ,Position ,Recordl ,Best Move ) .
evaluate _and _choose(( ] ,Position , (Move ,Value ) ,Move ) .
update (Move ,Value , (Movel ,Valuel ) ,(Movel ,Valuel ) ) +-
Value ::; Valuel .
update (Move ,Value ,(Movel ,Valuel ) ,(Move ,Value ) ) +-
Value > Valuel .
Program 18 .9 : Choosing the best move
space for two -person games. In particular we concentrate on the minimax algorithm
augmented by alpha -beta pruning . This strategy is used as the basis of a
program we present for playing Kalah in Chapter 20.
We describe the basic approach of searching game trees using evaluation functions
. Again in this section value(Position , Value) denotes an evaluation function
computing the Value of Position , the current state of the game. Here is a simple
algorithm for choosing the next move :

Find all possible game states which can be reached in one move .
Compute the values of the states using the evaluation function .
Choose the move that leads to the position with the highest score.
This algorithm is encoded as Program 18.9. It assumes a predicate

move(Move ,Position ,Positionl ) that applies a Move to the current Position to
reach Positionl . The interface to the game framework of Program 18.8 is provided
by the clause
choose-Inove(Position ,computer ,Move ) +-

set_of (M ,move (Position ,M ) ,Moves ) ,
evaluate _and _choose(Moves ,Position , (nil ,- lO OO) ,Move ) .
The predicate move(Position ,Move ) is true if Move is a possible move from the
current position .
The basic relation is evaluate_and_choose(Moves ,Position ,Record,Move )
which chooses the best move Move in the possible Moves from a given Position
. For each of the possible moves, the corresponding position is determined ,
its value calculated and the move with the highest value chosen. Record is a
record of the current best move so far . In Program 18.9 it is represented as a
. tuple (Move , Value) . The structure of Record has been partially abstracted in the
procedure update/ 4. How much data abstraction to use is a matter of style and
tradeoff between readability , conciseness, and performance .
Looking ahead one move , the approach of Program 18.9, would be sufficient
if the evaluation function were perfect , that is if the score would reflect which
positions led to a win and which to a loss. Games become interesting when
a perfect evaluation function is not known . Choosing a move on the basis of
looking al1ead one move is generally not a good strategy . It is better to look
several moves ahead, and infer from what is found the best move to make .
The minimax algorithm is the standard method for determining the value of
a position based on searching the game tree several ply ahead . The idea is as
follows .
The algorithm assumes that , when confronted with several choices, the opponent
would make the best choice for him , i .e., the worst choice for me. My goal
then is to make the move that maximizes for me the value of the position after
the opponent will make his best move , i .e., minimizes the value for him . Hence
the name minimax . This reasoning proceeds several ply ahead , depending on
the resources that can be allocated to the search. At the last ply the evaluation
function is used.
Player
0 pponent
Player
Figure 18.2: A simple game tree
Assuming a reasonable evaluation function , the algorithm will produce better

results the more ply are searched. It will produce the best move if the entire tree
is searched.
The minimax algorithm is justified by a zero-sum assumption , which says,

informally , that what is good for me must be bad for my opponent , and vice versa .
Figure 18.2 depicts a simple game tree of depth 2 ply . The player has two
moves in the current position , and the opponent has two replies . The values of
the leaf nodes are the values for the player . The opponent wants to minimize the
score, so will choose the minimum values , making the positions be worth + 1 and
- 1 at one level higher in the tree . The player wants to maximize the value and
will choose the node with value + 1.
Program 18.10 encodes the minimax algorithm . The basic relation is minimaxD
,Position ,Max MiniMove , Value) which is true if Move is the move with
the highest Value from Position obtained by searching D ply in the game tree .
Max Min is a flag which indicates if we are maximizing or minimizing . It is 1
for maximizing and - 1 for minimizing . A generalization of Program 18.9 is used
to choose from the set of moves. Two extra arguments must be added to evaluate
_and_chooseD the number of ply and Max Min the flag . The last argument
is generalized to return a record including both a move and a value rather than
just a move . The minimax procedure does the bookkeeping , changing the number
of moves being looked ahead , and also the minimax flag . The initial record is
( nil , - 1000) , where nil represents an arbitrary move and - 1000 is a score less than
any possible score of the evaluation function .
evaluate_and_choose(Moves,Position, Depth, Flag, Record,BestMove) +-

Choosethe BestMove from the set of Moves from the current
Position using the minimax algorithm searching Depth ply ahead.
Flag indicates if we are currently minimizing or maximizing.
Recordrecords the current best move.
evaluate_and_choose([MoveIMoves] ,PositionD ,Max MiniRecord,Best) +-
move(Move,Position,Positionl ) ,
minimaxD ,Positionl ,Max Min,MoveX ,Value),
update(Move,Value,Record,Recordl ),
evaluate_and_choose(Moves,PositionD ,Max Min,Recordl ,Best).
evaluate-and_choose( [ ] ,PositionD ,Max Min,Record,Record).
minimax (O,Position,Max MiniMove,Value) +-
value(Position.V),
Value := V *Max Min.
minimaxD ,Position,Max MiniMove,Value) +-
D > 0,
set-of(M,move(Position,M) ,Moves),
D1 := D - 1,
MinMax := - MaxMin,
evaluate-aJld_choose(Moves,PositionD 1,MinMax , (nil ,- lOOO
),
(Move,Value)) .
update(Move,Value,Record,Record1) +- SeeProgram 18.9
Program 18.10: Choosing the best move with the minimax algorithm
The observation about efficiency that was made about combining the move
generation and update procedures in the context of searching state -space graphs
has an analogue when searching game trees . Whether it is better to compute the
set of positions rather than the set of moves (with the corresponding change in
algorithm ) will depend on the particular application .
The minimax algorithm can be improved by keeping track of the results of
the search so far , using a technique 'known as alpha -beta pruning . The idea is to
keep for each node the estimated minimum value found so far , the alpha value ,
along with the estimated maximum value , beta . If , on evaluating a node , beta is
exceeded, no more search on that branch is necessary. In good cases more than
half of the positions in the game tree need not be evaluated .
Program 18.11 is a modified version of Program 18.10 which incorporates

alpha -beta pruning . The new relation scheme is alpha_beta(Depth ,Position ,Alpha ,
+ -
Chooses the Best Move from the set of Moves from the current
Position using the minimax algorithm with alpha -beta cutoff searching
Depth ply ahead . Alpha and Beta are the parameters of the algorithm .
Movel records the current best move .
evaluate_and_choose( [MoveIMoves] ,PositionD ,Alpha ,Beta,Movel ,BestMove) +-

move(Move,Position,Positionl ) ,
alpha_beta(D ,Positionl ,Alpha ,Beta,MoveX ,Value),
Valuel := - Value ,
cutoff(Move,Valuel ,D ,Alpha ,Beta,Moves,Position,Movel ,BestMove).
evaluate_and_choose( [ ] ,PositionD ,Alpha ,Beta,Move,(Move,Alpha ) ).
alpha_beta(O,Position,Alpha ,Beta,Move,Value) +-
value(Position,Value).
alpha_beta(D ,Position,Alpha ,Beta,Move,Value) +-
set-of(M ,move(Position,M ) ,Moves),
Alpha ! := - Beta ,
Betal := - Alpha ,
Dl := D - l ,
evaluate_and_choose(Moves,PositionD 1,Alphal ,Betal ,nil ,(Move,Value)) .
cutoff(Move,Value,D ,Alpha ,Beta,Moves,Position,Movel ,(Move,Value)) +-
Value ~ Beta .
cutoff(Move,Value,D,Alpha ,Beta,Moves,Position,Movel ,BestMove) +-
Alpha < Value , Value < Beta ,
evaluate_and_choose(Moves,PositionD ,Value,Beta,Move,BestMove).
cutoff(Move,Value,D ,Alpha ,Beta,Moves,Position,Move1,BestMove) +-
Value ~ Alpha ,
evaluate- and_choose(Moves,PositionD ,Alpha ,Beta,Movel ,BestMove).
Program 18 . 11 : Choosing a move using minimax with alpha -beta prlllling
Beta,Move, Value) which extends minimax by replacing the minim axing flag with
alpha and beta . The same relationship holds with respect to evaluate_and_choose.
Unlike Program 18.10, the version of evaluate _and_choose in Program 18.11

does not need to search all possibilities . This is achieved by introducing a predicate
cutoff which either stops searching the current branch or continues the search,
updating the value of alpha and the current best move as appropriate .
For example , the last node in the game tree in Figure 18.2 does not need to
be searched . Once a move with value - 1 is -found , which is less than the value of
+ 1 the player is guaranteed , no other nodes can contribute to the final score .
The program can be generalized by replacing the base case of alpha _ beta by
a test whether the position is terminal . This is necessary in chess programs , for
example , for handling incomplete piece exchanges .
18 . 3 Background
Search techniques for both planning and game playing are discussed in AI
textbooks . For further details of search strategies or the minimax algorithm and
its extension to alpha - beta pruning , see , for example , Nilsson ( 1971 ) or Winston
( 1977 ) .
Walter Wilson originally showed us the alpha -beta algorithm in Prolog .

Chapter 19
Meta - Interpreters
Meta - programs treat other programs as data . They analyze , transform , and
simulate other programs . The writing of metaprograms , or metaprogrammingis
particularly easy in Prolog due to the equivalence of programs and data : both being
Prolog terms . In fact metaprogrammingis nothing special in Prolog . Several
of the example programs in previous chapters are metaprograms , for example ,
the editor of Program 12 . 5 , the shell process of Program 12 . 6 , the simulators of
automata of Section 14 . 3 , and the translation of grammar rules to Prolog clauses
in Program 16 . 2 .
This chapter concentrates on a particular class of metaprograms , metainterpreters
. The first section explains the basics of metainterpreters . The remaining
sections show how metainterpreters can be enhanced for a wide range of
applications . Applications of metainterpreters to the building of expert system
shells are developed in the second section . The third section discuss es program
debugging algorithms and their implementation .
19 . 1 Simple metainterpreters
A meta - interpreter for a language is an interpreter for the language written
in the language itself . The ability to write a metainterpreter easily is a very
powerful feature a programming language can have . It enables the building of
an integrated programming environment and gives access to the computational
process of the language . Since a metainterpreter is a Prolog program , we give a
relation scheme . The relation solve ( GoaO is true if Goal is true with respect to
the program being interpreted . We use solve / l throughout this section to denote
a meta - interpreter .
304 Meta-Interpreters 19.1
solve( Goal) ~
Goal is deducible from the pure Prolog program
defined by clause/ 2.
solve(true ) .
solve((A ,B)) +- solve(A ), solve(B) .
solve(A ) +- clause(A ,B) , solve(B).
Program 19.1: A meta-interpreter for pure Prolog
The simplest metainterpreter that can be written in Prolog uses the metavariable
facility , namely
solve(A ) +- A .
Its usefulness can be seen in Programs 12.6 and 12.7 where it forms the ba.gis
for a shell process and logging facility written in Prolog .
A more interesting metainterpreter simulates the computational model of
logic programs . Goal reduction for pure Prolog programs can be described by the
three clauses comprising Program 19.1. This meta -interpreter and its extensions
form the basis for this chapter .
Declaratively , the interpreter reads as follows . The constant true is true . The
conjunction (A ,B) is true if A is true and B is true . A goal A is true if there is a
clause A ~ B in the interpreted program such that B is true .
We give also a procedural reading of the three clauses in Program 19.1. The
solve fact states that the empty goal , represented in Prolog by the atom true ,
is solved . The next clause concerns conjunctive goals . It reads : "To solve a
conjunction (A ,B) , solve A and solve B ." The general case of goal reduction is
covered by the final clause. To solve a goal , choose a clause from the program
whose head unifies with the goal , and recursively solve the body of the clause.
The procedural reading of Prolog clauses is necessary to demonstrate that the
metainterpreter of Program 19.1 indeed reflects Prolog 's choices of implementing
the abstract computation model of logic programming . The two choices are the
selection of the leftmost goal as the goal to reduce , and sequential search and
backtracking for the nondeterministic choice of the clause to use to reduce the goal .
The goal order of the body of the solve clause handling conjunctions guarantees
that the leftmost goal in the conjunction is solved first . Sequential search and
backtracking comes from Prolog 's behavior in satisfying the clause goal .
The hard work of the interpreter is borne by the third clause of Program
19.1. The call to clause performs the unification with the heads of the clauses
19.1 Simple meta-interpreters 305
solve ( member ( X , [ a , b , c ) ) )
clause ( member ( X , [ a , b , c ) ) , B ) {X= a,B= true}

solve ( true )
true Output : X = a
solve ( true )
clause ( true , T ) f
clause ( member ( X , [ a , b , c ) , B ) {B= member(X,[b,c])}

solve ( member ( X , [ b , c ) ) )
clause ( member ( X , [ b , c ) ) , Bl ) {X= b,Bl =true}

solve ( true )
true Output :
X=b
,
solve ( true )
clause ( true , T ) f
clause ( member ( X , [ b , c ) ) , Bl ) {Bl =member(X,[c])}

solve ( member ( X , [ c ) ) )
clause ( member ( X , [ c ) , B2 ) {X= c,B2=true}

solve ( true )
true Output :
x =c
,
solve(true )
clause(true ,T ) f
clause(member(X ,[c] ,B2)) {B2= member(X,[ ])}
solve(member(X ,[ ]))
clause(member(X ,[ ]),B3)
No (more) solutions
Figure 19.1: Tracing the metainterpreter
appearing in the program . It is also responsible for giving different solutions on

backtracking . Backtracking also occurs in the conjunctive rule reverting from B
to A .
Tracing the metainterpreter of Program 19.1 solving a goal is instructive .

The trace of answering the query 8olve(member (X ,[a,b, c])) with respect to Program
3.12 for member is given in Figure 19.1.
Differences in metainterpreters can be characterized in terms of their granularity

, that is the chunks of the computation that are made accessible to the
programmer . The granularity of the trivial one clause metainterpreter is too
solve( Goal, Tree) ~

Treeis a proof tree for Goalgiventhe programdefinedby clause
/ 2.
solve(true ,true ).
solve( (A ,B),(Proof A ,Prooffi )) i -
solve(A ,Proof A ), solve(B,Prooffi ).
solve(A ,(Ai - Proof )) i -
clause(A ,B) , solve(B ,Proof ).
Program 19 .2 : Building a proof tree
coarse . Consequently there is little scope for applying the metainterpreter . It

is possible , though not as easy , to write a metainterpreter which models unification
and backtracking . The granularity of such a metainterpreter is very fine .
Working at this fine level is usually not worthwhile . The efficiency loss is too
much to warrant the extra applications . The meta -interpreter in Program 19 .1,
at the clause reduction level , has the granularity most suited for the widest range
of applications .
A simple application constructs a proof tree as it solves the goal . The technique
is similar to constructing a parse tree for a grammar in Program 16 .3 , and
adding structured arguments to logic programs discussed in Section 2 .2 . The
proof tree is useful for expla Ilation facilities for expert systems as is discussed in
the next section .
The basic relation is solve( Goal, Tree) where Tree is a proof tree for solving the
goal Goal. Proof trees are represented by the structure Goalt - Proof where Proof is
a conjunction of the branch es proving Goal. Program 19.2 implementing solve/ 2
is a straightforward extension of Program 19.1. The three clauses correspond
exactly to the three clauses of the metainterpreter for pure Prolog .
The solve fact states that the empty goal is true with a trivial proof tree ,
represented by the atom true . The second clause states that the proof tree of a
conjunctive goal (A ,B) is a conjunction of the proof trees for A and B . The final
solve clause builds a proof tree A +- Prooffor the goal A , where Proof is recursively
built by solving the body of the clause used to reduce A .
We give an example of using Program 19.2 with the pure logic program ,
Program 1.2. The query solve(son(lot ,haran ) ,ProoJ) ? has the solution
Proof = (son(lot ,haran ) +-

( (father ( haran ,lot ) +- true ) ,
( male ( lot ) +- true ))) .
19.1 Simple meta -interpreters 307
-
system A := B). system(A < B).
system read(X)). system(write (X )) .
system integer(X)) . system(functor (T ,F ,N)).
system clause(A,B)). system(system(X )).
Figure 19 .2: Fragment of a table of system predicates
The query solve ( son ( X , haran ) , Prooj ) ? has the solution X = lot and the same value
for Proof .
The interpreter of Program 19 . 1 must be extended to handle language features
outside pure Prolog . The various system predicates are not defined by
clauses in the program and thus need different treatment . The easiest way to incorporate
these system predicates is to call them directly using the metavariable .
A table stating which predicates are system ones is necessary . We assume the table
consists of facts of the form system ( Predicate ) for each system predicate . Figure
19 . 2 gives part of that table . The clause in the metainterpreter handling system
predicates is
solve (A ) +- system (A ) , A .
The extra solve clause makes the behavior of the system predicates invisible
to the metainterpreter . This can be extended to non - system predicates whose
behavior one wants to be invisible . Conversely , there are some system provided
predicates which should be made visible . Examples are predicates for negation
and second - order programming . These are best handled by having a special clause
for each in the metainterpreter . Example clauses are
solve ( not A ) +- not solve (A ) .
solve ( set _ of ( X , Goal , Xs ) ) +- set _ of ( X , solve ( Goal ) , Xs ) .
Simulating the behavior of the cut correctly is a problem with this metainterpreter
. The naive solution is to consider cut as a system predicate . Effectively
this means adding the clause
solve(!) +- !.
This clause does not have the required effect . The cut in the clause guarantees
commitment to the current solve clause rather than affecting the search tree of
which the cut is a part . In other words , the scope of the cut is too local .
A neater solution uses a system predicate known as ancestor cut . Ancestor
cut is provided in Wisdom Prolog and Waterloo Prolog , but not in Edinburgh
Prolog . The general form is !(Ancestor ) , where Ancestor refers to an ancestor of
308 Meta -Interpreters 19.1
solve( Goa~ +-
Goalis deduciblefrom the Prologprogram
definedby clause
/ i!.
solve(true ) .
solve( (A ,B )) +- solve (A ) , solve (B ) .
solve(l) +- !(reduce (A ) ) .
solve(not A ) +- not solve (A ) .
solve(.set_of(X,
. Goal ,Xs))
. . i - set _of(X,solve
(Goal
),Xs).
solve(A ) +- system (A ) , A .
solve(A ) +- reduce (A ) .
reduce (A ) +- clause(A ,B ) , solve (B ) .
Program 19 .3 : A meta -interpreter for full Prolog
the current goal . If Ancestor is a positive integer , n say, the nth ancestor of the
current goal is considered . Counting is done upward from the current goal , so
the first ancestor is the parent goal , the second ancestor is the grandparent goal ,
etc . If Ancestor is a noninteger term , the first ancestor unifying with Ancestor is
considered . In either case all siblings of the specified ancestor are pruned from
the search tree in the same manner as if a cut had been applied directly to the
ancestor goal .
To handle cut correctly using ancestor cut , a separate predicate from solve
is necessary ; reduce( GoaQ is used here . The correct scope for cut is obtained by
allowing the metainterpreter to cut the previous reduce goal with the ancestor
cut .
All the observations and improvements of the above discussion are incorporated
into a metainterpreter for Prolog in Program 19.3.
The meta -interpreter in Program 19.3 can be made more efficient by adding
cuts . The choice of the appropriate clause in the collection of solve clauses is
deterministic . Once the correct cIa.use has been identified it can be committed to .
Clauses can be added for the extensions to pure Prolog in Program 19.2, the
meta -interpreter building proof trees . System goals are handled with the clause
solve(A ,(A +- true ) )+- system (A ) , A .
The proof tree for a system goal A is At - true .

We give an example of an enhanced metainterpreter that traces a computation
in the style presented in Section 6.1. We present two versions . The first
19.1 Simple meta -interpreters 309
version , Program 19.4, handles only success branch es of the computations in pure
Prolog , and does not display failure nodes in the search tree . It is capable of
generating the trace in Figure 6.2 of the query append(Xs, Ys,[a,b,c]). The second
version , Program 19.5, handles system predicates , and more importantly failure
nodesin the searchtree. It is capableof generatingthe tracesof Figures6.1 and
6.3 of the queries son(X ,haran) and quicksort([2,1,3],Xs), respectively.
The basic predicate is trace(Goal,Depth) where Goal is solved at some Depth.
The starting depth is assumed to be O. The three clauses in Program 19.4 correspond
to the three clauses of Program 19.1. The first two clauses state that
the empty goal is 'solved at any depth , and the depth of solving each conjunct in
a conjunction is the same. The final clause matches the goal with the head of a
program clause, displays the goal , increments the depth and solves the body of
the program clause at the new depth .
The predicate displafj( Goal,Depth) , which displays a Goal at a given Depth, is
an interface for printing the traced goal . The depth in the proof tree is indicated
by depth of indentation . The definition of display uses an indentation which is
some multiple of the depth in the tree .
There is some subtlety in the goal order of the clause
trace(Goal,Depth) ~
clause(A ,B),
display(A ,Depth),
Depthl := Depth + l ,
trace(B,Depthl ) .
The display goal is between the clause goal and the trace goal . This ensures
that the goal is displayed each time Prolog backtracks to clause. If the order of
the clause and display goals are swapped , only the initial call of the goal A is
displayed ~
Using Program 19.4 for the query trace( append(Xs, Ys,[a,b,c])) with Program
3.15 for append generates a trace as presented in Section 6.1. The output messages
and semicolons for alternative solutions are provided by the underlying Prolog .
There is only one difference from the trace in Figure 6.2. The unifications are
already performed .
Program 19. 4 can be extended in order to trace the failure of goals. In
order to print failed goals, we must rely on the operational behavior of Prolog , in
particular the use of clause order . Cuts are added to the first two clauses, and an
extra clause is added at the end of the program :
trace ( GoaQ
Goal is deducible from the pure Prolog program defined by
clause / 2 . The program traces the proof by side - effects .
trace ( Goal ) + -
trace ( Goal , O ) .
trace ( true , Depth ) .
trace ( ( A , B ) , Depth ) + -
trace { A , Depth ) , trace ( B , Depth ) .
trace ( A , Depth ) + -
clause ( A , B ) ,
display ( A , Depth ) ,
Depth1 : = Depth + 1 ,
trace ( B , Depth1 ) .
display ( A , Depth ) + -
tab ( Depth ) , write ( A ) , nl .
Program 19 . 4 : A tracer for pure Prolog
trace( Goa~ +-
Goal is deducible from the Prolog program defined by
clause / 2 . The program traces the proof by side effects .
trace ( Goal ) +- trace ( Goal ,O) .

trace ( true ,Depth ) +- I.
trace ( ( A ,B ) ,Depth ) +-
I , trace ( A , Depth ) , trace ( B ,Depth ).

trace ( A ,Depth ) +-
system ( A ) , A , ! , display ( A ,Depth ) , nI .

clause ( A ,B ) ,
display ( A , Depth ) , nI ,
Depth ! := Depth + 1,
trace ( B ,Depthl ).
not clause(A ,B), display(A ,Depth), tab (8), write (f ), ill , fail .
display(A ,Depth)
Spacing := 3* Depth , tab (Spacing ) , write (A ) .
Program 19 .5 : A tracer for Prolog
19.2 Enhancedmeta-interpretersfor expert systems 311
trace(A,Depth
)
notclause
(A,B), display
(A,Depth
), tab(lO), write(f), nl, fail.
Note that display is modified not to start on a new line , so that the failure message
is consistent with the traces in Chapter 6. An extra new line command is necessary
to the clauses that call display .
System goals are handled by the clause
trace (A ,Depth ) +- system (A ) , A , !, display (A ,Depth ) .
The call to display is after the goal has succeeded, to correctly use the last rule if
the goal should fail . The cut is necessary to distinguish from the last clause . The
new program is given as Program 19.5. It can give the trace of Figure 6.3, and
also that of Figure 19.1.
( i ) Write a metainterpreter to count the number of procedure calls made by a
program .
( ii ) Extend Program 19 . 5 to handle full Prolog analogously to Program 19 . 3 .
( iii ) Write an interactive tracer which prompts the user for a response before each
goal reduction .
( iv ) Extend Program 19 . 3 to interpret ancestor cut .
19 . 2 Enhanced metainterpreters for expert systems
The typical decomposition of expert systems into a knowledge base and an
inference engine is not entirely appropriate for expert systems written in Prolog .
. Much of an inference engine is provided by Prolog itself . Knowledge bases are
executable . However Prolog does not provide important features expected of expert
systems usually embedded in the inference engine . Examples are generating
explanations and uncertainty reasoning .
In this section we show a series of enhanced metainterpreters demonstrating
three features of expert systems : interaction between the user and the program ,
an explanation facility , and an uncertainty reasoning mechanism .
We demonstrate the explanation facility and interactive shell using the toy
expert system in Program 19 . 6 . The program can decide where to place a dish in
place- in _oven(Dish ,Rack) . -

Dishshould
beplaced
in theovenat levelRackforbaking
.
place Jn - oven ( Dish , top ) of -
pastry ( Dish ) , size ( Dish , small ) .
place Jn _ oven ( Dish , middle ) of -
pastry ( Dish ) , size ( Dish , big ) .
place Jn _ oven ( Dish , middle ) of -
main - Ineal ( Dish ) .
place Jn _ oven ( Dish , low ) of -
slow _ cooker ( Dish ) .
pastry ( Dish ) + - type ( Dish , cake ) .
pastry ( Dish ) + - type ( Dish , bread ) .
main . . . meal ( Dish ) + - type ( Dish , meat ) .
slow _ cooker ( Dish ) + - type ( Dish , milk _ pudding ) .
Program 19 . 6 : Oven placement expert system
solve ( Goa ~
Goal is deducible from the pure Prolog program defined by
clause / 2 . The user is prompted for missin ~ information .
solve ( true ) .
solve ( ( A ,B ) ) + -
solve ( A ) , solve ( B ) .
solve ( A ) + -
clause ( A ,B ) , solve ( B ) .
solve ( A ) + -
askable (A ) , not known (A ) , ask ( A , Answer ) , respond ( Answer ,A ) .
ask(A ,Answer ) +-
display -query (A ) , read (Answer ) .
respond (yes,A ) -+-
assert (A ) .
respond (no ,A ) -+-
assert (untrue (A ) ) , fajI .
known (A ) +- A .
known (A ) +- untrue (A ) .
display _query (A ) ~ write (A ) , write ('? ').
Program 19 .7 : An interactive shell
19.2 Enhanced meta -interpreters for expert systems 313
the oven for baking . Comments on the suitability of Prolog for building expert
systems are made at the background section of this chapter .
Program 19 . 7 is an interactive shell which can query the user for missing
information . It assumes that a procedure askable / l is defined , which specifies
when goals that the interpreter fails to prove by itself can be delegated to the
user . To implement this facility , the following clause is added to the end of the
metainterpreter of Program 19 . 1 :
solve ( A ) + -
askable ( A ) , not known ( A ) , ask ( A , Answer ) , respond ( Answer , A ) .
The predicate askable ( Goa ~ is used to screen which information is suitable
for asking from the user . For example , the fact askable ( type ( Dish , Type ) ) indicates
we can ask the type of a dish .
To avoid asking the same question repeatedly , the program records the answer
to the query . This is handled by the predicate respond / ! : ! . If the answer to the
query A is yes , a fact A is asserted into the program . If the answer is no , the
fact untrue ( A } is asserted . This information is used by known / l to avoid asking
questions whose answers should be known to the program .
An improved version of the shell allows the interaction to go the other way
as well . When asked a question , the user can respond with a question of her own .
We consider how the shell should respond to the user ' s question " why . "
The obvious reply of the shell is the rule whose conclusion the program is
trying to establish .
This can be easily incorporated into the shell by extending all the relationships
with an extra argument , the current rule being used . The rule must be
explicitly represented in an extra argument as there is no access to the global
state of the computation in Prolog programs . The solve goal must be extended
appropriately as discussed below . The interface to the explanation of " why "
queries is then
respond ( why , Goal , Rule ) + -
display . . xule ( Rule ) , ask ( Goal , Answer ) , respond ( Answer , Goal , Rule ) .
This version of respond writes out the current parent rule , then prompts the
user to answer the query once more . The format in which the rule will appear is
determined by display _rule , a modular extension of the shell to allow the user to
represent rules in her favorite way. .
Repeated responses of why using the above clause for respond result in repeated
restatement of the parent rule . A better solution is to give the "grandpar -
solve(place-in _oven(dishi ,X ))?

type (dishi ,cake)? yes.
size(dishi ,small)? no.
type (dishi ,bread)? no.
size(dishi ,big)? why.
IF pastry (dishi ) AND size(dishi ,big)
THEN place-in _oven(dishi ,middle)
size(dishi ,big)? yes.
X = middle
Figure 19.3: A session with the interactive shell
place-in -oven(dishi ,top) is proved using the rule

IF pastry (dishi ) and size(dishi ,small)
THEN place-in _oven(dishi ,top)
pastry (dishi ) is proved using the rule
IF type (dishi ,bread)
THEN pastry (dishi )
type (dishi ,bread) is a fact in the database.
size(dishi ,small) is a fact in the database.
Figure 19.4: Generating an explanation
ent " rule in response to the second why, the "great grandparent " rule in response
to the next why, and so on all the way up the search tree . To achieve this behavior
, the code is modified so that the argument containing the rule contains
instead the list of ancestor rules . The new version of respond is
respond (why ,Goal ,[Rule IRules ]) f -

write -Iule (Rule ) , ask( Goal ,Answer ) , respond (Answer ,Goal ,Rules ) .
Repeated requests of why then give the ancestor rules in turn . An extra clause is
needed to cover the case when there are no more rules to explain .
The complete interactive shell incorporating why explanations is given as
Program 19.8. A trace using the program is given in Figure 19.3. User responses
are in italics . We explain the remaining predicates in that program .
The second argument of solve( Goal,Rules) , used in Program 19.8, is a list
of the rules used to reduce the ancestor nodes of Goal in the current proof tree .
The list of rules is updated by the solve clause performing goal reduction . The
19.2 Enhanced meta -interpreters for expert systems 315
solve( Goa~ +-
Goal is deducible from the pure Prolog program
defined by clause/ 2.
The user is prompted for missing information ,
and can ask for a "why " explanation .
solve(Goal) t - solve(Goal,[ ]).
solve(true ,Rules).
solve((A ,B),Rules) -+-
solve(A ,Rules), solve(B ,Rules).
solve(A ,Rules) +- .
clause(A ,B), solve(B ,[rule (A ,B) IRules]).
solve(A ,Rules) +-
askable(A ), not known(A ), ask(A ,Answer), respond(Answer,A ,Rules).
ask(A ,Answer) +-
display_query(A ), read(Answer).
respond (yes,A ,Rules ) i --
assert (A ) .
respond ( no ,A ,Rules ) i --
assert (untrue (A ) ) , fail .
respond (why ,A , [Rule IRules ]) i --
display ..rule(Rule ) ,
ask ( A ,Answer ) ,
respond (Answer ,A ,Rules ) .
respond (why ,A , [ ]) i --
writeln ( ('No more explanation possible ']) ,
ask ( A , Answer ) ,
respond ( Answer , A , Rules ) .
known ( A ) + - A .
known ( A ) + - untrue ( A ) .
display _ query ( A ) + -
write ( A ) , write ( ' ? ' ) .
display . . I Ule ( rule ( A , B ) ) + -
write ( ' IF ' ) , write - conjunction ( B ) , writeln ( ( ' THEN ' , A ] ) .
write _ conjunction ( ( A , B ) ) + -
I , write ( A ) , write ( ' AND ' ) , write _ conjunction ( B ) .
write _ conjunction ( A ) + -
write ( A ) , ill .
Program 19 . 8 : An interactive shell with " why " explanations

how( Goa~ +-
Explains how the goal Goal was proved .
how(Goal) +-
solve ( Goal , Proof ) , interpret ( Proof ) .
solve ( Goal , Proof ) + - See Program 19 . 2 .
interpret ( ( Proofl , Proof2 ) ) + -
interpret ( Proofl ) , interpret ( Proof2 ) .
interpret ( Proof ) + -
fact ( Proof , Fact ) , .
nl , writeln ( [ Fact , ' is a fact in the database . ' ] ) .
interpret ( Proof ) + - ~
rule ( Proof , Head , Body , Proofl ) ,
nl , writeln ( [ Head , ' is proved using the rule ' ] ) ,
display - 1 ' Ule ( rule ( Head , Body ) ) ,
interpret ( Proofl ) ~
fact ( ( Fact + - true ) , Fact ) .
rule ( ( Goal + - Proof ) , Goal , Body , Proof ) + -
Pro Df # true , extract - body ( Proof , Body ) .
extract _ body ( ( Proofl , Proof2 ) , ( Bodyl , Body2 ) ) + -
!, extract _body(Proofl ,Body 1), extract_body (Proof2,Body2).

extract _body ( (Goal +- Proof ) ,Goal ) .
displaY Jule (Rule ) +- See Program 19.8.
Program 19 .9 : Explaining a proof
representation chosen for rules is a structure rule (A ,B) . The only other predicate
which is affected by this choice of representation is display _rule .
Answering a "why " query is a simple explanation facility where a single , local
chain of reasoning is reported . Our next example is a more interesting explanation
facility that explains the complete proof of a solved query .
The basic idea is interpreting a proof of a goal , where a proof has been collected
in a metainterpreter as shown in Program 19.2. A query how( GoaQ'I,
asking how a goal is proved , is handled by executing the metainterpreter on the
goal and interpreting the resulting proof , A simple program for "how " explanations
is given as Program 19,9.
Figure 19,4 gives a trace of using Program 19,9 to explain the goal
19.2 Enhanced meta - interpreters for expert systems 317
place -in _oven ( dishi ,middle ) is proved using the rule

IF pastry ( dishi ) and size ( dishi ,big )
THEN place -in _oven ( dishi ,middle )
pastry ( dishi ) can be further explained .
size ( dishi ,big ) is a fact in the database .
Figure 19 . 5 : Explaining one rule at a time
how ( place _in _oven ( dishi , top ) ) ?, using the facts type ( dishi , bread ) and size ( dishi ,
smal ~ .
The explanation in Figure 19 .4 is very clear , but there are hidden shortcomings
. One is the exhaustive nature of the explanation . For any but the smallest
knowledge base , too much output is produced . The screenfuls of text produced
for an expert system with hundreds of rules are not intelligible . A practical mod -
ification to Program 19 .9 is to restrict the explanation to one level at a time and
allow the user to ask for more if necessary . A modified explanation appears as
Figure 19 .5 .
The explanation given in Figure 19 .4 exactly mirrors the Prolog computation

. This may not be what is wanted . Using a metainterpreter allows greater
flexibility . Explanations can be given that are different from the logic of the program
itself , yet constitute the justification for which the rule was derived . We
give a very simple example to illustrate the principle .
Suppose the explanation is geared toward an expert baker who knows the
classification of dishes : that is , what is a pastry , etc . Although the program must
still do the reasoning establishing that a dish is a pastry by being a cake , etc . , it
is of no interest or relevance to the baker . This can be handled by a . special clause
for interpret , which assumes a predicate classification ( Goa ~ for goals which have
to do with classification :
interpret ( ( Goal +- Proof ) ) +-

classification ( Goal ) ,
writeln ( (Goal ,' is a classification example ']) .
A classification fact is an example of domain - specific metaknowledge . Using

such metaknowledge allows the expert to build a theory of explanation that
complements rather than repeats the proof of the expert system . A disparity
between what is said and what is done is often true of human experts .
Filtered explanations are useful in describing system predicates performing

arithmetic or 1/ 0 , for example . Such Prolog goals 4ave a different status from the
solve ( Goal , Certainty ) + -
Certainty is our confidence that Goal is true .
solve ( true , l ) .
solve ( ( A , B ) , C ) + -
solve ( A , Cl ) , solve ( B , C2 ) , minimum ( Cl , C2 , C ) .
solve ( A , C ) + -
clause _ cf ( A , B , Cl ) , solve ( B , C2 ) , C : = Cl * C2 .
minimum ( ni , N2 , M ) + - See Program 11 . 3 .
Program 19 . 10 : A meta - interpreter for reasoning with uncertainty
solve ( Goal , Certainty , Threshold ) + -
Certainty is our confidence that Goal is true .
The certainty is greater than Threshold .
solve ( true , 1 , T ) .
solve ( ( A , B ) , O , T ) + -
solve ( A , 01 , T ) , solve ( B , 02 , T ) , minimum ( 01 , 02 , 0 ) .
solve ( A , O , T ) + -
claus ~ _ cf ( A , B , 01 ) ,
01 > T ,
T1 : = T / 01 ,
solve ( B , 02 , T1 ) ,
0 : = 01 * 02 .
minimum ( ni , N2 , M ) + - See Program 11 . 3 .
Program 19 . 11 ; Reasoning with uncertainty with threshold cutoff
viewpiont of the user of the expert system . More generally whole Prolog routines
that implement algorithms need not be explained , and a more concise report of
what the algorithm does can be offered instead .
The final example of using a metainterpreter for an expert system is the incorporation
of an uncertainty reasoning mechanism . The reason for introducing
such a mechanism is the availability of uncertain information - rules and facts .
A deduction mechanism operating on uncertain assumptions should produce uncertain
conclusions . There are several ways for representing uncertainly in rules
and for computing the uncertainty of conclusions . The main requirement is that
in the limiting case , when all rules are certain , the behavior of the system will
mimic the standard deduction mechanism .

19.2 Enhancedmeta-interpretersfor expert systems 319
We choose the following . We associate with each rule or fact a certainty

factor , c, a < c ~ 1. A logic program with uncertainties is a set of pairs
(Clause,Factor) where Clause is a clause and Factor is a certainty factor. We
use the following rule for computing uncertainties :
certainty ((A ,B)) = min { (certainty (A) ,certainty (B)}

certainty (A ) = max{ certainty (B).FI (A+- B,Fj is a pair in the program} .
The simple interpreter in Program 19.10 is a straightforward enhancement

of the basic metainterpreter , given as Program 19.1. The top- level relation is
solve( Goal, Certainty) which is true when Goalis satisfied with certainty Certainty.
The meta -interpreter computes the combination of certainty factors in a
conjunction as the minimum of the certainty factors of the conjuncts . Other
combining strategies could be accommodated just as easily. Program 19.10 assumes
that clauses with certainty factors are represented using the predicate
clause_cf(A ,B, CF) .
The meta -interpreter in Program 19.10 can be augmented to prune computation
paths that do not meet a desired certainty threshold . An extra argument
, the size of the cutoff threshold , needs to be added . The new relation is
solve( Goal, Certainty, Threshold) , and is given in Program 19.11.
The threshold is used in the third clause of Program 19 .11 . The certainty of
any goal must exceed the current threshold . If it does, the computation continues
with the new threshold being the quotient of the previous threshold by the
certainty of the clause .
Improve display _rule in Program 19.7 to generate English text , rather than
Prolog terms .
Extend the known predicate in Programs 19.7 and 19.8 to handle functional
concepts .
(iii ) Extend Program 19.8 to handle responsesother than yes, no, and why.
(iv ) Modify Program 19.9 so that it produces the trace in Figure 19.5.
(v) Combine the interactive and uncertainty reasoning shells to prompt the user
for the uncertainty of facts and rules . Record the values so they can be used
.
agaIn .
19 . 3 Enhanced metainterpreters for debugging
Debugging is an essential aspect of programming , even in Prolog . The

promise of high -level programming languages is not so much in their prospects
for writing bug -free programs , but rather in the power of the computerized tools
for supporting the process of program development . For reasons of bootstrap ping
and elegance, these tools are best implemented in the language itself . Such tools
are programs for manipulating , analyzing , and simulating other programs , or , in
other words , metaprograms .
This section shows metaprograms for supporting the debugging process of
pure Prolog programs . The reason for restricting ourselves to the pure part is
obvious : the difficulties in handling the impure parts of the language .
To debug a program , we must assume that the programmer has some intended
behavior of the program in mind , and an intended domain of application on which
the program should exhibit this behavior . Given those , debugging consists of finding
discrepancies between the program 's actual behavior and the programmer 's
intended behavior . Recall the definitions of an intended meaning and a domain
from Section 5.2. An intended meaning M of a pure Prolog program is the set of
ground goals on which the program should succeed. The intended domainD of
a program is a domain on which the program should terminate . We require the
intended meaning of a program to be a subset of the intended domain .
We say that Al is a solution to a goal A if the program returns on a goal A
its instance AI . We say that a solution A is true in an intended meaning M if
every instance of A is in M . Otherwise it is false in M .
A pure Prolog program can exhibit only three types of bugs , given an intended
meaning and an intended domain . When invoked on a goal A in the intended
domain , the program may do one of three things :
a. Fail to terminate .
b . Return some false solution A ().
c. Fail to return some true solution A ().
We describe algorithms for supporting the detection and identification of each

of these three types of bugs .
In general , it is not possible to detect if a Prolog program is nonterminating
: the question is undecidable . Second best is to assign some a priori bound
on the running time or depth of recursion of the program , and abort the computation
if the bound is exceeded. It is desirable to save part of the computation
to support the analysis of the reasons for nontermination . The enhanced
19.3 Enhanced meta -interpreters for debugging 321
solve ( AiD , Overflow ) + -
A has a proof tree of depth less than D and
Overflow equals no _ overflow , or A has a
branch in the computation tree longer than D , and
Overflow contains a list of its first Delements .
solve ( true , D , no _ overflow ) .
solve ( A , O , overflow ( [ ] ) ) .
solve ( ( A , B ) , D , Overflow ) + -
D > 0 ,
solve ( A , D , Overflow A ) ,
solve - conjunction ( Overflow A , BiD , Overflow ) .
solve ( AiD , Overflow ) + -
D > 0 ,
clause ( A , B ) ,
Dl : = D - l ,
solve ( B , D 1 , Overflow B ) ,
return - overflow ( Overflow B , A , Overflow ) .
solve(AiD ,no_overflow) +-
D > 0,
system (A ) , A .
solve_conjunction ( overflow (S) ,BiD ,overflow (S) ) .
solve_conjunction (no _overflow ,BiD ,Overflow ) +-
solve (BiD ,Overflow ) .
return _overflow (no _overflow ,A ,no _overflow ) .
return _overflow ( overflow (S) ,A ,overflow ([AIS ]) ) .
Program 19 .12 : A meta -interpreter detecting a stack overflow
meta -interpreter shown in Program 19.12 achieves this . It is invoked with a call
solve( Goal,D , Overflow ) , where Goal is an initial goal , and D an upper bound on
the depth of recursion . The call succeeds if a solution is found without exceeding
the predefined depth of recursion , with Overflow instantiated to no- overflow .
The call also succeeds if the depth of recursion is exceeded, but in this case Overflow
contains the stack of goals , i .e., the branch of the computation tree , which
exceeded the depth -bound D .
Note that as soon as a stack overflow is detected , the computation returns ,

without completing the proof . This is achieved by solve_conjunction and return
- overflow .
isort(Xs, Ys) +-
Ys is an ordered permutation of Xs . Nontermination program .
isort ([X IXs],Ys) +- isort (Xs,Zs) , insert (X ,Zs,Ys).

isort ([ ],[ ]).
insert(X,[YIYs],[X,YIYs]) +-
X < Y.
insert(X,[YIYs],[YIZs]) +-
X ~ Y, insertY,[XIYs],Zs).
insert(X,[ ],[X]).
Program 19.13: A nonterminatinginsertionsort
For example , consider Program 19 . 13 for insertion sort .
When called with the goal solve ( isort ( [ . 2, . 2] , Xs ) , 6 , Overjlow ) , the solution returned
is
) Cs == [2 , 2 ,2 ,2 , 2 , 2 ] ,
Overflow = = overflow ( [
isort ( [2 , 2 ] , [2 , 2 ,2 , 2 , 2 , 2 ] ) ,
insert ( 2 , [2 ] , [2 ,2 ,2 , 2 , 2 ,2 ] ) ,
insert ( 2 , [2 ] , [2 ,2 , 2 , 2 , 2 ] ) ,
insert ( 2 , [2 ] , [2 ,2 , 2 , 2 ] ) ,
insert ( 2 , [2 ] , [2 , 2 , 2 ] ) ,
insert ( 2 , [2 ] , [2 ,2 ] ) ] )
The overflown stack can be further analyzed , upon return , to diagnose the
reason for nontermination . This can be caused , for example , by a loop , i . e . , by a
sequence of goals G1 , G2 , . . . , Gn , on the stack , where G1 and Gn are called with
the same input , or by a sequence of goals that calls each goal with increasingly
large inputs . The first situation occurs in the example above . It is clearly a bug ,
that should be fixed in the program . The second situation is not necessarily a bug ,
and knowing whether the program should be fixed , or a larger machine should be
bought in order to execute it , requires further program - dependent information .
The second type of bug is returning a false solution . A program can return
a false solution only if it has a false clause . A clause G is false with respect to an
intended meaning M if it has an instance whose body is true in M and head is
false in M . Such an instance is called a counterexample to G .
Consider , for example , Program 19 . 14 for insertion sort .
On the goal isort ( [ 9 , 2 , 1 ) , Xs ) it returns the solution isort ( [3 , 2 , 1 ), [3 , 2 , 1 )) which

isort (Xs, Ys) +-

Buggy insertion sort .
isort ([X IXs],Ys) -t- isort (Xs,Zs), insert (X ,Zs,Ys) .

isort ([ ],[ ]).
insert(X,[YIYs],[X,YIYs]) f--
X ~ Y.
insert(X,[YIYs],[YIZs]) f--
X > Y, insert(X,YsiZs).
insert(X,[ ],[X]).
Program 19.14: Incorrectandincomplete
insertionsort
:; solution , one can find a

false instance of a clause as follows : traverse the proof tree in post order . Check
whether each node in the proof tree is true . If a false node is found , the clause
whose head is the false node and whose body is the conjunction of its sons is a
counterexample to a clause in the program . That clause is false , and should be
removed or modified .
The correctness of this algorithm follows from a simple inductive proof . The
algorithm is embedded in an enhanced metainterpreter , shown .as Program 19.15.
The algorithm , and its implementation , assume an oracle that can answer
queries concerning the intended meaning of the program . The oracle is some entity
external to the diagnosis algorithm . It can be the programmer , who can respond
to queries concerning the intended meaning of his program , or another program ,
which has been shown to have the same meaning as the intended meaning of
the program under debugging . The second situation may occur in developing a
new version of a program , and using the older version as an oracle . It can also
occur when developing an efficient program (e.g., quicksort ) ; given an inefficient
executable specification of it (i .e., permutation sort ) , and using the specification
as an oracle .
false -solution ( A , Clause) +-

If A is a provable false instance , then Clause is
a false clause in the program . Bottom up algorithm .
false-Bolution (A ,Clause ) +-
solve (A ,Proof ) ,
false_clause (Proof ,Clause ) .
false_clause (true ,ok) .
false_clause ( (A ,B ) ,Clause) +-
false-clause (A ,Clause A ) ,
check-conjunction (Clause A ,B ,Clause ) .
false_clause ((A +- B ) ,Clause) +-
false_clause(B ,Clause B ) ,
check_clause ( Clause B ,A ,B ,Clause ) .
check_conjunction ( ok ,B ,Clause ) +-
false_clause (BiClause ) .
check_conjunction ( (A +- Bl ) ,B ,(A +- Bl ) ) .
check_clause(ok ,A ,BiClause ) +-
query -goal (A ,Answer ) ,
check- answer (Answer ,A ,B ,Clause ) .
check_clause ( (AI +- BI ) ,A ,B ,(A ~+- BI ) ) .
check-answer (true ,A ,B ,ok ) .
check- answer(false ,A ,B , (A +- Bl )) +-
extract _body (B ,Bl ) .
extract -body (true ,true ) .
extract _body ( (A i - B ) ,A ) .
extract _body (( (Ai - B ) ,Bs) ,(A ,As ) ) i -
extract _body (Bs ,As ) .
query -goal (A ,true ) +-
system (A ) .
query -goal ( Goal ,Answer ) +-
not system ( Goal ) ,
writeln (['Is the goal ' ,Goal ,' true ?']) ,
read (Answer ) .
Program 19 .15 : Bottom -up diagnosis of a false solution
When invoked with the goal false_solution(isort([9,f ,1],X) , C) ? the algorithm

exhibits the following interactive behavior:
false-solution(isort ([3,2,1],X ) ,C)?
Is the goal isort ([ ],[ ]) true?
true .
Is the goal insert (1,[ ],[1]) true ?

true .
Is the goal isort ([1],[1]) true?

true .
Is the goal insert (2,[1],[2,1]) true?

false .
x = [3,2,1],
C = insert (2,[1],[2,1]) +- 2 ~ 1.
Which returns a counterexample to the false clause.

The proof tree returned by solve/ 2is not guaranteed to be ground , in contrast
to the assumption of the algorithm . However , every instance of a proof tree is a
proof tree . Hence this problem can ~e remedled by either instantiating variables
left in the proof tree to arbitrary constants , before activating the algorithm , or
requesting the oracle to instantiate the querled goal when it contains variables .
Different instances might imply different answers. Since the goal of this algorithm
is to find a counterexample as soon as possible , the oracle should instantiate the
goal to a false instance if it can .
One of the main concerns with diagnosis algorithms is improving their query
complexity , i .e. reducing the number of queries they require to diagnose the bug .
Given that the human programmer may have to answer the queries , this desire is
clearly understandable . The query complexity of the above diagnosis algorithm
is linear in the size of the proof tree . There is a better strategy , whose query
complexity is linear in the depth of the proof tree , not its size. In contrast to
the previous algorithm which is bottom -up , the second algorithm traverses the
proof tree top -down . At each node it tries to find a false son . If it fails , then the
current node constitutes a counterexample , as the goal at the node is true , and
all its sons are false . If it finds such a node , it recurses with it .
The implementation of the algorithm is shown in Program 19.16.

Note the use of cut to implement implicit negation in the first clause of
false _goal/ 2, and the use of query- goal/ 2 as a test predicate .
Compare the behavior of the bottom -up algorithm with the following trace
of the interactive behavior of Program 19.16:
jalse _solution ( A , Clause ) +-

If A is a provable false instance , then Clause
is a false clause in the program . Top - down algorithm .
false - aolution ( A ,Clause ) +-

solve (A ,Proof ),
false _go ~l ( Proof , Clause ).
false _goal ( ( A +- B ) ,Clause ) +-

false _conjunction ( BiClause ) , t.
false _goal ( ( A +- B ) , (A +- Bl ) ) +-
extract _body ( B ,Bl ) .
false _conjunction ( ( ( A +- B ) ,Bs ) , Clause ) +-

query - goal (A ,false ) , ! ,
false _goal ( (A +- B ) ,Clause ).
false _conjunction ( ( A +- B ) , Clause ) +-
query _goal ( A ,false ) , I ,
false _goal ( (A +- B ) ,Clause ).
false _conjunction ( (A ,As ) ,Clause ) +-
false _conjunction (As ,Clause ).
extract _body ( Tree ,Body ) ~ See Program 19 . 15
query - goal (A ,Answer ) ~ See Program 19 . 15
Program 19 . 16 : Top - down diagnosis of a false solution
false - solution (isort ( [3 ,2 , 1] ,X ) ,C ) ?

Is the goal isort ( [2 , 1] , [2 , 1 ] ) true ?
false .
Is the goal isort ( [l ] , [ l ] ) true ?
true .'
Is the goal insert ( 2 , [ 1] , [2 , 1] ) true ?

false .
x = [3 ,2 , 1] ,
C = insert ( 2 , [ 1] , [2 , 1] ) +- 2 ~ 1
There is a diagnosis algorithm for false solutions with an even better query
complexity , called divide - and- query. The algorithm progress es by splitting the
proof tree into two approximately equal parts , and querying the node at the
splitting point . If the node is false , the algorithm is applied recursively to the
subtree rooted by this node . If the node is true , its subtree is removed from the
missing _ solution ( A , Goa ~ + -
If A is a non - provable true ground goal , then Goal is a
true ground goal which is uncovered by the program .
missing - solution ( ( A , B ) , Goal ) + - 1 ,
( not A , missing - solution ( A , Goal ) ;
A , missing - solution ( BiGoal ) ) .
missing - solution ( A , Goal ) + -
clause ( A , B ) ,
query - clause ( ( A + - B ) ) , ! ,
missing - solution ( B , Goal ) .
missing - solution ( A , A ) + -
not system ( A ) .
query _ clause ( Clause ) + -
writeln ( [ ' Enter a true ground instance of ' , Clause ,
' if there is such , or " no " otherwise ' ] ) ,
read ( Answer ) ,
! , check _ answer ( Answer , Clause ) .
check - answer ( no , Clause ) + - ! , fail .
check _ answer ( Clause , Clause ) + - ! .
check - answer ( Answer , Clause ) + -
write ( ' Illegal answer ' ) ,
I , query _ clause ( Clause ) .
Program 19 . 17 : Diagnosing missing solution
tree and replaced by true , and a new middle point is computed . The algorithm can
be shown to require a number of queries logarithmic in the size of the proof tree .
In case of close - to - linear proof trees , this constitutes an exponential improvement
over both the top - down and the bottom - up diagnosis algorithms .
The third possible type of bug is a missing solution . Diagnosing a missing
solution is more difficult then the previous bugs . We say that a clause covers a
goal A with respect to an intended interpretation M if it has an instance whose
head is an instance of A and whose body is in M .
For example , consider the goal insert ( 2 , [ 1 , 3 ] , Xs ) . It is covered by the clause
insert ( X , [ YIYs ] , [X , YIYs ] ) ~ X ~ Y .
of Program 19.14 with respect to the intended interpretation M of the program ,

since in the following instance of the clause
insert (2,[1,3],[1,2,3]) +- 2 :;::: 1.
the head is an instance of A and the body is in M .

It can be shown that if a program P has a missing solution with respect to
an intended meaning M , then there is a goal A in M , which is not covered by
any clause in P. The proof of this claim is beyond the scope of the book . It is
embedded in the diagnosis algorithm below .
Diagnosing a missing solution imposes a heavier burden on the oracle . Not
only does it have to know whether a goal has a solution , but it must also provide
it , if it exists . Using such an oracle , an uncovered goal can be found as follows .
The algorithm is given a missing solution , i .e., a goal in the intended interpretation
M of the program P, for which P fails . The algorithm starts with the
initial missing solution . For every clause that unifies with it , it checks, using the
oracle , if the body of the clause has an instance in M . If there is no such clause, the
goal is uncovered , and the algorithm terminates . Otherwise , the algorithm finds
a goal in the body that fails . At least one of them should fail , else the program
would have solved the body , and hence the goal , in contrast to our assumption .
The algorithm is applied recursively to this goal .
An implementation of this algorithm is shown in Program 19.17. The program
attempts to trace the failing path of the computation , and find a true goal
which is uncovered . A session with the program is shown below :
missing-solution(isort ([2,1,3],[1,2,3]),C)?
Enter a true ground instance of
(isort ([2,1,3] ,[1,2,3]) +- isort ([1,3] ,Xs) ,insert(2,Xs,[1,2,3]))
if there is such , or ' no ' otherwise
(isort([2,1,9], [1,2,9]) +- isort([1,9], [1,9]), insert( 2, [1,9], [1,2,9])).

(isort ([l ,3] ,[1,3]) +- isort ([3],Y s) ,insert (1,Y s,[1,3]))
(isort([l , 3], [1,3]) +- isort([3], [3]), insert(1, [3],[1,3])).

(insert(1,[3],[1,3]) ~ 1 :? 3)
no .
G = insert (1,[3],[1,3])
The reader can verify that the goal insert(1,[3],[1,3]) is not covered by Program
19.4 Background 329
19.14.
The three algorithms shown can form the basis of a high -quality interactive
program development environment for Prolog .
19 .4 Background
The concept of a metainterpreter (or , rather , of metacircular interpreter ) is

due to Sussman and Steele (1978) , who were the first to propose using the ability
of the language to specify itself as a fundamental criteria for language design .
Prolog is a natural language for building expert systems . Although Program
19.6 is very simple , it is suggestive of early backward chaining expert systems .
We compare the program with a rule from MYCIN (Shortliffe , 1976) , an expert
system for diagnosing and treating bacterial infections .
IF the gram stain of the organism is gram negative ,
the morphology of the organism is rod ,
the aerobicity of the organism is anaerobic
THEN there is suggestive evidence (0.5) that the identity
of the organism is Bacteroides .
There are two agpects to the above rule . First , the heuristic identification of a
bacteria based on its gram stain , morphology , and aerobicity . Second, there is
a certainty factor attached to the rule . We argue that these should be separate .
The uncertainty is best handled by an enhanced metainterpreter such ag Program
19.10. The heuristic knowledge is expressed in the Prolog rule :
identity ( Organism ,bacteroides ) i -

gram -Btain ( Organism ,gram Jlegative ) ,
morphology ( Organism ,rod ) ,
aerobicity ( Organism ,anaerobic ) .
Note that the rule above , and those in Program 19.6, are essentially ground . The
only variable appearing in the "context " of object under study . For MYCIN , the
context in the above rule is the organism , for the oven management system it is
the dish .
Rules using more of the power of Prolog are just as easy to write . Here is a
clause from a toy medical expert system , which gives a flavor of what is possible .
The credit evaluation expert system in Chapter 21 provides further examples .
prescribe (Patient ,Drug ) +-

complaint (Patient ,Symptom ) ,
suppress es(Symptom ,Drug ) ,
suitable (Drug ,Patient ) .
The relationships complaint , suppress es and suitable are themselves described by
facts and rules .
The first to argue explicitly for the use of Prolog to build expert systems
were Clark and McCabe ( 1982 ) . That paper discuss es how explanation facilities
and uncertainty reasoning can be added to simple expert systems such as Program
19 . 6 . The technique proposed is adding extra arguments to the program ' s
predicates . An explanation facility and a query the user facility were incorporated
in the APES expert system shell by Hammond and Sergot ( Hammond ,
1984 ) . Using meta - interpreters as a basis for explanation facilities in expert systems
was proposed by Sterling ( 1984 ) . An explanation shell built using enhanced
metainterpreters is described by Sterling and Lalee ( 1985 ) . Using enhanced metainterpreters
for handling uncertainties comes from Shapiro ( 1983c ) .
Suggesting that enhanced metainterpreters should be the basis of a programming
environment was done by Shapiro ( 19S3a ) . That book also contains
and discuss es the debugging algorithms used in Section 19 . 3 .
Takeuchi and Furukawa ( 1985 ) have shown that partial evaluation can eliminate
the runtime overhead of metainterpreters . The effect of partial evaluation
is to compile an object program and an enhanced metainterpreter into a new
object program that inherits the functionality of the metainterpreter but not its
overhead . Sterling and Beer ( 1986 ) particularizes the work for expert systems .
Both papers report speedups by a factor of 40 .
Meta - interpreters , and more generally metaprograms , have also been composed
to affect the control How of Prolog programs . References are Dincbas and
LePape ( 1984 ) , Gallaire and Lasserre ( 1980 ) , and Pereira ( 1982 ) .

P art IV
Applications
Prolog has been used for a wide range of applications : expert systems , natural
language understanding , symbolic algebra , compiler writing , building embedded
languages , and architectural design to name a few . In this chapter we give a flavor
of writing application programs in Prolog .
The first chapter looks at programs for playing three games: mastermind ,
Nim , and Kalab . The next chapter presents an expert system for evaluating
requests for credit . The third chapter presents a program for solving symbolic
equations , while the final chapter looks at a compiler for a Pascal-like language .
The empha.sis in presentation in these chapters is on writing clear programs .
Knowledge embedded in the programs is made explicit . Minor efficiency gains are
ignored if they obscure the declarative reading of the program .
Chapter 20
Game - Playing Programs
Learning how to playa game is fun . As well as understanding the rules of

the game, we must constantly learn new strategies and tactics until the game is
mastered . Writing a program to play games is also fun , and a good vehicle for
showing how to use Prolog for writing nontrivial programs .
20.1 Mastermind
Our first program guesses the secret code in the game of mastermind . It is
a good example of what can be programmed in Prolog easily with just a little
thought .
The version of mastermind we describe is what we played as kids . It is

a variant on the commercial version and needs less hardware ( only pencil and
paper ) . Player A chooses a secret code , a list of N distinct decimal digits ( usually
N equals 4 for beginners , 5 for advanced players ) . Player B makes guesses , and
queries player A for the number of bulls ( number of digits that appear in identical
positions in the guess and in the code ) and cows ( number of digits that appear in
both the guess and the code , but in different positions ) . The code is determined
when a guess has N bulls .
There is a very simple algorithm for playing the game : impose some order
on the set of legal guesses ; then iterate , making the next guess that is consistent
with all the information you have so far until you find the secret code .
Rather than defining the notion of consistency formally , we appeal to the

reader ' s intuition : a guess is consistent with a set of answers to queries if the
answers to the queries would have remained the same if the guess was the secret
code .
20.1 Mastermind 335
The algorithm performs quite well compared with experienced players : an

average of 4 to 6 guesses for a code with 4 digits with an observed maximum of 8.
However , it is not an easy strategy for humans to apply , because of the amount
of bookkeeping needed . On the other hand , the control structure of Prolog -
nondeterministic choice , simulated by backtracking - is ideal for implementing
the algorithm .
We describe the program top -down . The entire program is given as Program
20.1. The top level procedure for playing the game is
ma.stermind
(Code
) +-
cleanup
, guess
(Code
), check
(Code), announce
.
The heart of the top level is a generate - and - test loop . The guessing procedure
guess ( Code ) , which acts as a generator , uses the procedure selects ( Xs , Ys ) ( Program
7 . 7 ) to select nondeterministic ally a list Xs of elements from a list Y sAc -
cording to the rules of the game , Xs is constrained to be of four distinct elements ,
while Y s is the list of the ten decimal digits :
guess ( Code ) + -
Code = [ Xl , X2 , X3 , X4 ] , selects ( Code , [ 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , O ] ) .
The procedure check ( Guess ) tests the proposed code Guess . It first verifies
that Guess is consistent with all ( i . e . , not inconsistent with any ) of the answers
to queries already made ; then it asks the user for the number of bulls and cows
in Guess . The ask ( Guess ) procedure also controls the generate - and - test loop ,
succeeding only when the number of bulls is four , indicating the correct code is
found :
check ( Guess) +-
not inconsistent (Guess) , ask(Guess) .
Ask stores previous answers to queries in the relation query (X ,B , C) , where X

is the guess, B is the number of bulls in it , and C the number of cows. A guess is
inconsistent with a previous query if the number of bulls and cows do not match :
inconsistent ( Guess) +-
query (Old ,Bulls ,Cows) ,
not bulls - and_cows- match ( Old ,Guess,Bulls ,Cows) .
The bulls match between a previous guess Old Guess and a conjectured guess
Guess if the number of digits in the same position in the two guesses equals
the number of Bulls in Old Guess. It is computed by the predicate exact
_matches ( Old Guess, Guess,Bulls ) . The cows match if the number of common
336 Game-Playing Programs 20.1
mastermind ( Code ) +-
cleanup , guess ( Code ) , check ( Code ) , announce .
guess ( Code ) ~
Code = [Xl ,X2 ,X3 ,X4 ] , selects ( Code , [ 1 )2 , 3 , 4 , 5 ,6 , 7 , 8 ,9 ,0 ] ) .
V' erify the proposed guess
check ( Guess ) +-
not inconsistent ( Guess ) , ask ( Guess ).
inconsistent ( Guess ) +-
query ( Old Guess ,Bulls , Cows ),
not bulls _and _cows - I Datch ( Old Guess , Guess , Bulls , Cows ).
bulls _and _cows . . I Ilatch ( Old Guess , Guess ,Bulls , Cows ) +-

exact . . I Ilatches ( Old Guess , Guess ,Nl ),
Bulls = := Nl , % Correct number of bulls
common . . I Ilembers ( Old Guess , Guess ,N2 ) ,

Cows = := N2 - Bulls . % Correct number of cows
exact - matches ( X ,Y ,N ) + -
size _of ( A ,same _place ( A ,X ,Y ) ,N ) .
commoll J Ilembers ( X , Y ,N ) + -
size _of ( A , ( member ( A ,X ) ,member ( A , Y ) ) ,N ) .
same _place ( X , [X IXs ] , [XIY s]) .
same _place ( A , [X IXs ] , [YIY a] ) + - same _place ( A ,Xs , Y s ) .
Asking a guess
ask ( Guess ) +-
repeat ,
writeln ( [ ' How many bulls and cows in ' , Guess ,' ? '] ) ,
read ( ( Bulls , Cows )) ,
sensible ( Bulls , Cows ) , I,
assert ( query ( Guess ,Bulls , Cows )) ,

Bulls = 4.
sensible ( Bulls , Cows ) +-

integer ( Bulls ) , integer ( Cows ) , Bulls + Cows ~ 4.
Bookkeeping
cleanup +- abolish ( query ,3 ) .
announce +-
size _of ( X ,A 1 ( B 1 ( query ( X ,A ,B ) ) ) ,N ) ,

writeln ( [ ' Found the answer after ' ,N , ' queries ']) .
Program 20 . 1 : Playing Mastermind

20.1 Mastermind 337
size_of(X ,GiN) +- SeeProgram 17.1

selects(X ,Xs,Y s) +- SeeProgram 7.7
abolish(F ,N) +- SeeExercise 12.4(i).
digits without respect to order corresponds to the sum of Bulls and Cows, and is
computed by the procedure bulls_and_cows_match . It is easy to count the number
of matching digits and common digits in two queries , using the set-predicate
size_of/ So
The ask( Guess) procedure is a memo-function which records the answer to
the query . It performs some limited consistency checks on the input with the
procedure sensible(Response ) and succeedsonly if the answer is 4 bulls. The
expected syntax for the user's reply is a tuple (Bulls, Cows).
The remaining (top-level) predicates are for bookkeeping. The first , cleanup,
removes unwanted information from previous games. The predicate announce
tells how many guesses were needed using the set-predicate utility size_of.
A more efficient implementation of the exact_matches and common _members
procedures can be obtained by writing iterative versions :
exact-Inatches(Xs,Y siN) +- exact-Inatches(Xs,Y s,O,N).

exact-Inatches([X IXs], [XIY s] ,KiN ) +-
Kl := K + l , exact-Inatches(Xs,Ys,Kl ,N).
exact-Inatches([X IXs],[YIYs],K ,N) +-
X # Y , exact-Inatches(Xs,Ys,KiN ).
exact-Inatches([ ],[ ],N,N).
commollJllembers(Xs,Y siN) +- COmmollJllembers(Xs,Y s,O,N).
common. . members
([X IXs],Ys,KiN ) +-
member(X ,Ys), Kl := K + l , common. .members
(Xs,Ys,Kl ,N).
common. . members
([X IXs],Ys,KiN ) +-
common. . members (Xs,Y siK ,N).
common.. members( [ ],Y s,NN ).
Using the more efficient versions of exact_matches and common _members

saves about 10- 30% of the execution time .
I I I
IIIII
IIIIIII
Figure 20 .1: A starting position for Nim
20.2 Nim
We turn our attention now from mastermind to Nim , also a game for two
players . There are N piles of matches , and the players take turns to remove some
of the matches (up to all) in a pile. The winner is the player who takes the last
match . Figure 20.1 gives a common starting position , with four piles of 1, 9, 5
and 7 matches respectively . .
To implement the Nim playing program , we use the game-playing framework
given as Program 18.8.
The first decision is the representation of the game position and the moves.
A natural choice for positions is a list of integers where elements of the list correspond
to piles of matches. A move is a tuple (NiM) for taking M matches
from pile N. Writing the procedure move(Move,Position,Position1),- where Position
is updated to Positionl by Move, is straightforward . The recursive rule
counts down match piles until the desired pile is reached . The remaining piles of
matches representing the new game position is computed routinely :
move((K ,M ),[NINs],[N I Nsl]) +-
K > 1, Kl := K- l , move((Kl ,M ),Ns,Nsl ).
There are two possibilities for updating the specified pile of matches , the base
case of the procedure . H all the matches are taken , the pile is removed from the
list . Otherwise the new number of matches in the pile is computed , and checked
to be legal :
move((I ,N),[NINs],Ns).
move((I ,M ),[NINs],[N I INs]) +- N > M , Nl := N- M .
The mechanics of turns for two person games is specified by two facts .
The initial piles of matches and who moves first must be decided by the
two players . Assuming the computer moves second, the game of Figure 20.1 is
specified as
initialize (nim ,[1,3,5,7],opponent).

20.2 Nim 339
1
11
101
111
000
Figure 20.2: Computingrum-sums
The game is over when the last match is taken . This corresponds to the game
position being the empty list . The person having to move next is the loser , and
the output messages of announce are formulated accordingly . The details are in
Program 20.2.
It remains to specify how to choose the moves. The opponent 's moves are
accepted from the keyboard ; how much flexibility is allowed in input is the responsibility
of the programmer . Here , because we concentrate on the logic of the
game, we assume the player will enter legal moves:
choose...move(Position ,opponent ,Move ) +-
writeln ( ['please make move ']) , read (Move ) .
Choosing a move for the computer requires a strategy . A simple strategy to

implement is taking all of the first pile of matches . It is recommended only for
use against extremely poor players :
choose-Inove( [NINs J,computer , (1,N )) .
A winning strategy is known for Nim . It involves dividing game states ,

or positions , into two classes, safe and unsafe . To determine the category of
a position , the binary representation of the number of matches in each pile is
computed . The nim -sum of these binary numbers is then calculated as follows .
Each column is summed independently modulo 2. If the total in each column is
zero , the position is safe. Otherwise the position is unsafe .
Figure 20.2 illustrates the process of the classification for the four piles of
matches in Figure 20.1. The binary representations of 1, 3, 5 and 7 are 1, 11,
101 and 111. Calculating the nim -sum : there are four l 's in the units column ,
two l 's in the 2's column and two l 's in the 4's column ; an even number of l 's in
each. The nim -sum is zero making the position [1,3, 5, 7] safe. On the other hand
the position [2,6] is unsafe . The binary representations are 10 and 110. Summing
them gives one 1 in the 4's column and two l 's in the 2's column . The single 1 in
the 4's column makes the position unsafe .
The winning strategy is to always leave the position safe. Any unsafe position
can be converted to a safe position (though not all moves do) , while any move from
play (Game) +- SeeProgram 18.8

Choosing 'moves
choose. . move
(Position,opponent,Move) +-
writeln (['please make G move']), read(Move).
choose. . move
(Ns,computer,Move) +-
unsafe(N s,Sum), safe. . move(Ns,Sum,Move) .
choose. . move
(Ns,computer,(I ,I )) +- % The computer 's ' arbitrary move '
safe(Ns).
move(Move,Position,Position1) +-
Position1 is the result of executing the move
Move from the current Position .
move((K ,M),[NINs],[N INsl ]) +-

K > 1, Kl := K- l , move((Kl ,M ),Ns,Nsl ).
move((I ,N),[NINs],Ns) .
move((I ,M ),[NINs],[N I INs]) +-
N > M , Nl := N - M .
display_game(Position,X ) +- write (Position), ill .

next_player(computer ,opponent). next-player (opponent,computer).
game-over( [ ] ,Player,Player).
announce(computer) +- write ('You won! Congratulations.'), ill .
announce(opponent) +- write ('I won.'), ill .
initialize (nim ,[1,3,5,7],opponent).
unsale(Position,Sum) +-
Position with nim - sum Sum is unsafe .
unsafe(Ns,Sum) +- nim -sum(Ns,[],Sum), not zero(Sum) .

safe(Ns) +- not unsafe(Ns,Sum).
nim_sum(Position,SoFar,Sum) +-
Sum is the nim - sum of the current Position ,
and Sa Far is an accumulated value .
nim -sum([NINs],Bs,Sum) +-
binary (N ,Ds), nim _add(Ds,Bs,Bsl ) , nim-sum(Ns,Bs1,Sum).
nim -sum([ ],Sum,Sum).
nim _add(Bs,[ ],Bs).
nim _add([ ],Bs,Bs).
nim _add([B IBs],[CICs],[DIDs]) +-
D := (B+ C) mod 2, nim _add(Bs,Cs,Ds).
Program 20 .2 : A program for playing a winning game of Nim
20.2 Nim 341
binary ( 1,[1]).
binary (N ,[DIDs]) iN
> 1, D := N mod 2, ni := N/ 2, binary (ni ,Ds).
decimal(Ds,N) +- decimal(Ds,Oil ,N).
decimal([ ],N ,T ,N).
decimalD IDs],A ,T ,N) +- Al := A + D*T , Tl := T *2, decimal(Ds,Al ,Tl ,N).
zero([ ]).
zero([OIZs]) -to- zero(Zs).
safe_move(Position,Nim Sum,Move) ~
Move is a move from the current Position with
the value Nim Sum which leavesa safe position .
safe. . move (Piles,Nim Sum,Move) +--
safe. . move(Piles,Nim Sum,l ,Move) .
safeJI1ove([Pile IPiles] ,Nim Sum,K ,(KiM )) f -
binary (Pile,Bs), can-zero(Bs,Nim Sum,Ds,O), decimal(Ds,M).
safeJI1ove([Pile IPiles] ,Nim Sum,K ,Move) f -
Kl := K + l , safeJI1ove(Piles,Nim Sum,Kl ,Move) .
can-zero([],Nim Sum,[ ],0) +-
zero(Nim Sum) .
can-zero([B I Bs],[O INim Sum],[CIDs],C) +-
can-zero(Bs,Nim Sum,Ds,C) .
can-zero([B IBs],[1INim Sum],[DIDs],C) +-
D := 1- B*C, C1 := 1- B, can-zero(Bs,Nim Sum,Ds,C1).
a safe position creates an unsafe one. The best strategy is to make an arbitrary
move when confronted with a safe position hoping the opponent will blunder, and
convert unsafe positions to safe ones.
To implement this strategy, we need two algorithms . One to compute the
nim-sum of a given position , and the other to determine a move to convert an
unsafe position to a safe one. The move to make is determined by the safety of
the position . If the position is unsafe, use the algorithm to find a move to make
the position safe and win the game. If the position is safe, make an arbitrary
move (one match from the first pile) and hope:
choose J D . ove ( N s , computer , Move ) + -
unsafe ( N s , Sum ) , safe J D. ove ( N s , Sum , Move ) .
choose J D . ove ( Ns , computer , ( l , l ) ) + - % The computer ' s ' arbitrary move '
safe ( Ns ) .
The predicate uns afe ( N s , Sum ) succeeds if the position represented by N s is
unsafe . It is defined by calculating the rum - sum Sum of the piles of matches ( by
a procedure nim _ sum / 9 and testing whether it is zero :
unsafe ( Ns , Sum ) + - nim _ sum ( Ns , [ ] , Sum ) , not zero ( Sum ) .
In a prior version of the program unsafe did not return Sum . When writing
safe _ move it transpired that the Dim - sum was helpful , and it was sensible to pass
the already computed value , rather than recomputing it . The predicate safe is
easily defined in terms of unsafe .
The Dim - sum is computed by nim _ sum ( Ns , So Far , Sum ) . The relation computed
is that Sum is the Dim - sum of the numbers Ns added to what has been
accumulated in So Far . To perform the additions , the numbers must first be converted
to binary , done by binary / 2 :
nim . . sum ( [ NINs } , Bs , Sum ) ~
binary ( N , Ds ) , nim _ add ( Ds , Bs , Bsl ) , nim . . sum ( Ns , Bsl , Sum ) .
The binary form of a number is represented here as a list of digits . To
overcome the difficulty of adding lists of unequal length , the least significant digits
are earliest in the list . Thus . 2 ( in binary 10 ) is represented as [ 0 , 1 ] , while 6 is
represented as [ 0 , 1 , 1 ] . The two numbers can then be added from least significant
digit to most significant digit , as is usual for addition . This is done by nim _ add / 9
and is slightly simpler than regular addition since no carry needs to be propagated .
The code for both binary and nim _ add appears in Program 20 . 2 .
The mm - sum Sum is used by the predicate safe _ move ( Ns , Sum , Move ) to find
a winning move Move from the position described by Ns . The piles of matches
are checked in turn by safe _ move / 4 to see if there is a number of matches which
can be taken from the pile to leave a safe position . The interesting clause is
safe - move ( [ Pile I Piles ] , Nim Sum , K , ( KiM ) ) + -
binary ( Pile , Bs ) , can - zero ( Bs , Nim Sum , Ds , O ) , decima J ( Ds , M ) .
The heart of the program is can _ zero ( Bs , Nim Sum , Ds , Carry ) . This relation is true
if replacing the binary number Bs by the binary number Ds would make Nim Sum
zero . The number Ds is computed digit by digit . Each digit is determined by the
corresponding digit of Bs , Nim Sum and a carry digit Carry initially set to O . The
20.3 Kalah 343
number is converted to its decimal equivalent by decimal/ 2 in order to get the

correct move .
Program 20.2 is a complete program for playing Nim interactively incorporating

the winning strategy . As well as being a program for playing the game, it
is also an axiomatization of what constitutes a winning strategy .
20.3 Kalah
We now present a program for playing the game of Kalah that uses alpha -
beta pruning . Kalah is a game which fits well into the paradigm of game trees for
two reasons. First , the game has a simple , reason ably reliable evaluation function ,
and , second, its game tree is tractable , which is not true for games such as chess
and go. It has been claimed that Kalah programs that have been written are
unbeatable by human players . Certainly , the one presented here beats us.
Kalah is played on a board with two rows of six holes facing each other . Each
player owns a row of six holes , plus a kalah to the right of the holes . In the initial
state there are six stones in each hole and the two kalahs are empty . This is
pictured in the top half of Figure 20.3.
A player begins his move by picking up the stones of one of his holes . Proceeding
counterclockwise around the board , he puts one of the picked -up stones
in each hole and in his own kalah skipping the opponent 's kalab , until no stones
remain to be distributed . There are three possible outcomes . If the last stone
lands on the kalah , the player has another move . If the last stone lands on an
empty hole owned by the player , and the opponent 's hole directly across the board
contains at least one stone , the player takes all the stones in the hole plus his last
landed stone and puts them all in his kalah . Otherwise the player 's turn ends,
and his opponent moves.
The bottom kalah board in Figure 20.3 represents the following move from
the top board by the owner of the top holes . He took the six stones in the
rightmost hole and distributed them , the last one ending in the kalah , allowing
another move . The stones in the fourth hole from the right were then distributed .
If all of the holes of a player become empty (even if it is not his turn to play ) ,
the stones remaining in the holes of the opponent are put in the opponent 's kalah
and the game ends. The winner of the game is the first player to get more than
half of the stones in his kalah .
The difficulty for programming the game in Prolog is in finding an efficient

data structure to represent the board , to facilitate the calculation of moves. We
( 0. 0. Om
(
(
6 6 6 6 6 6
... .. . . .. . .. . .. .. .
0.ON
0 .. 0 .. 0 .. 0 ,. 0 .. 0 ..
70
oO
0-
00 0
:
Om
0.
60
6
() 0
Figure 20.3: Board positions for Kalah
use a 4-argument structure board(Holes,Kalah , OppHoles, OppKalah ) where Holes

is a list of the numbers of stones in your six holes , K alah is the number of stones in
your kalah , while OppHoles and OppKalah are, respectively , the list of the numbers
of stones in the opponent 's holes and the number of stones in his kalah . Lists
were chosen rather than six -place structures to facilitate the writing of recursive
programs for distributing the stones in the holes .
A move consists of choosing a hole and distributing the stones therein . A

move is specified as a list of integers with values between 1 and 6 inclusive , where
the numbers refer to the holes . Hole 1 is farthest from the player 's kalab , while
hole 6 is closest . A list is necessary rather than a single integer because a move
may continue . The move depicted in Figure 20.3 is [1, 6].
20.3 Kalah 345
Play framework
play (Game ) +- See Program 18.8.
Choosing a move by minimax with alpha-beta cut -off
choose- move(Position ,computer ,Move ) +-
lookahead (Depth ) ,
alpha -beta (Depth ,Position ,- 40,40,Move ,Value ) ,
nl , write (Move ) , nl .
choose- move(Position ,opponent ,Move ) +-
nl , writeln (['please make move']) , read (Move ) , legal (Move ) .
alpha _beta (O,Position ,Alpha ,Beta ,Move ,Value ) +-
value (Position ,Value ) .
alpha _beta (DiPosition ,Alpha ,Beta ,Move ,Value ) +-
D > 0,
set_of (M ,move (Position ,M ) ,Moves) ,
Alphal := - Beta ,
Betal := - Alpha ,
Dl := D - l ,
evaluate _and _choose(Moves ,PositionD 1,Alphal ,Betal ,nil , (Move ,Value )) .
evaluate _and _choose( [Move IMoves] ,PositionD ,Alpha ,Beta ,Record ,Best Move ) +-
alpha _beta (D ,Positionl ,Alpha ,Beta ,Move X ,Value ) ,
Valuel := - Value ,
cutoff (Move ,V aluel ~D ,Alpha ,Beta ,Moves ,Position ,Record ,Best Move ) , !.
evaluate _and _choose( [ ] ,PositionD ,Alpha ,Beta ,Move , (Move ,Alpha ) ) .
cutoff (Move ,Value ,D ,Alpha ,Beta ,Moves ,Position ,Movel , (Move ,Value ) ) +-
Value ~ Beta , !.
cutoff (Move ,Value ,D ,Alpha ,Beta ,Moves ,Position ,Movel ,Best Move ) +-
Alpha < Value , Value < Beta , I,
evaluate _and _choose(Moves ,PositionD ,Value ,Beta ,Move ,Best Move ) .
cutoff (Move ,Value ,D ,Alpha ,Beta ,Moves ,Position ,Movel ,Best Move ) - -
Value ~ Alpha , !,
evaluate _and -choose(Moves ,PositionD ,Alpha ,Beta ,Move 1,Best Move ) .
move(Board,[MIMs]) +-
member(M ,[1,2,3,4,5,6]),
stonesin -l1ole(M ,Board,N) ,
extend-Inove(N ,M ,Board,Ms).
move(board([O,O,O,O,O,O],K ,Ys,L),[ ]).
Program 20 .3 : A complete program for playing Kalah .
stonesinl1ole (M ,board (Hs ,K ,Y s,1 ) ,Stones) +-

nth Jllember (M ,Hs ,Stones) , Stones > o.
extend Jnove (Stones ,M ,Board ,( ]) -t--
Stones = \ = (7- M ) mod 13, t.
extend Jnove (Stones,M ,Board ,Ms ) +-
Stones = := (7- M ) mod 13, t,
distribute -stones (Stones,M ,Board ,Board1 ) ,
move (Board1 ,Ms ) .
Executing a move
move ( [NINs ],Board ,Final Board ) * -

stonesin -11ole(N ,Board ,Stones) ,
distribute -Btones(Stones ,N ,Board ,Boardl ) ,
move (Ns ,Boardl ,Final Board ) .
move ( [ ],Boardl ,Board2 ) * -
swap (Boardl ,Board2 ) .
distribute _stones( Stones,Hole ,Board ,Boardl ) +-

Boardl is the result of distributing the number of stones ,
Stones, from Hole from the current Board .
It consists of two stages: distributing the stones in the player 's
holes , distribute - my_holes, and distributing the stones
in the opponent 's holes , distribute _your _holes.
distribute -stones (Stones ,Hole ,Board ,Fina I Board ) +-

distribute -nlY~ oles(Stones,Hole ,Board ,Boardl ,Stonesl ) ,
distribute _your ~ oles (Stones 1,Boardl ,Final Board ) .
distribute -:rny-11oles(Stones ,N ,board (Hs ,K ,Y s,L ) ,board (Hs1,K1 ,Y s,L ) ,Stones1) +-
Stones > 7- N , !,
pick _up _and _distribute (N ,Stones,Hs ,Hs1) ,
Kl := K + l , Stonesl := Stones+ N- 7.
distribute -:rny-11oles(Stones ,N ,board (Hs ,K ,Y s,L ) ,Board ,O) +-
pick _up _and _distribute (N ,Stones,Hs ,Hs1) ,
check_capture (N ,Stones,Hs 1,Hs2,Y sY sl ,Pieces) ,
update -1r..a1ah(Pieces,N ,Stones,K ,Kl ) ,
check Jf -finished (board (Hs2 ,K1 ,Y sl ,L ) ,Board ) .
Program 20 .3 (Continued )
20.3 Kalah 347
check_capture(N ,Stones,Hs,Hs1,Y sY sl ,Pieces) f -

Finishing Hole := N + Stones ,
Opposite Hole := 7- Finishing Hole ,
nth Jnember(OppositeHole,Y sY ),
Y > 0 , !,
n..substitute(OppositeHole,Hs,0,Hsl ) ,
n..substitute(Finishing Hole,Y s,O,Y sl ),
Pieces := Y + 1 .
check_capture(N ,Stones,Hs,Hs,Y sY s,O) f - I.
check-if -finished(board(Hs,K ,Y s,L) ,board(Hs,K ,Hs,Ll )) +-
zero(Hs), !, sumlist(Ys,YsSum), Ll := L + YsSum.
check-if -finished(board(Hs,K ,Y s,L) ,board(Y s,Kl ,Y s,L )) +-
zero(Ys), !, sumlist(Hs,HsSum), Kl := K + HsSum.
check-if -finished(Board,Board) +- !.
update~ ah(O,Stones,N ,K ,K ) +- Stones < 7- N, !.
update..kalah(O,Stones,N ,K ,Kl ) +- Stones = := 7- N, !, Kl := K + l .
update..kalah(Pieces,Stones,N,K ,Kl ) +- Pieces> 0, !, Kl := K + Pieces.
distribute _your-11oles(O,Board,Board) +- !.
distribute _your -11oles
(Stones,board(Hs,K ,Y s,L) ,board(Hs,K ,Y si ,L)) +-
1 ::; Stones , Stones ::; 6 ,
non-zero(Hs), !,
distribute (Stones,Y sY si ).
distribute _your-11oles(Stones,board(Hs,K ,Y s,L),board(Hs,K ,Y si ,L)) +-
Stones > 6 , !,
distribute (6,Ys,Ys1),
Stones1 := Stones - 6 ,
distribute ...stones(Stonesl,1,board(Hs,K ,Y si ,L) ,Board).
distribute -your -11oles (Stones,board(Hs,K ,Y s,L) ,board(Hs,K ,Hs,L1)) +-
zero(Hs), !, sumlist(Ys,YsSum), L1 := Stones+ YsSum+ L .
Lower level stone distribution
pick-up-and_distribute (1,N ,[H IHs],[OIHs1]) ~

I, distribute (N ,Hs,Hs1).
pick_up_and_distribute (KiN ,[H IHs],[H IHs1]) ~
K > 1, I, K1 := K - 1, pick_up_and-distribute (K1 ,N ,Hs,Hs1).
distribute (O,Hs,Hs) 1- I.
distribute (N ,[H IHs],[H I IHs I]) 1-
N > 0, I, NI := N- I , HI := H+ I , distribute (NI ,Hs,HsI ).
distribute (N,[ ],[ ]) 1- I.
348 Game-PlayingPrograms 20.3
Evaluation function
value ( board ( H , K ,Y , L ) , Value ) + - Value : = K - L .
Testing for the end of the game
game _ over ( board ( O , NO , N ) , Player , draw ) + -
pieces ( K ) , N = : = 6 * K , ! .
game - over ( board ( H , K , Y , L ) , Player , Player ) + -
pieces ( N ) , K > 6 * N , ! .
game _ over ( board ( H , K ,Y , L ) , Player , Opponent ) + -
pieces ( N ) , L > 6 * N , next _ player ( Player , Opponent ) .
announce ( opponent ) + - writeln ( [ ' You won ! Congratulations . ' ] ) .
announce ( computer ) + - writeln ( [ ' I won . ' ] ) .
announce ( draw ) + - writeln ( [ ' The game is a draw ' ] ) .
Miscellaneous game utilities
nth . . . member ( N , [ H I Hs ] , K ) + -
N > 1 , ! , ni : = N - 1 , nth . . . member ( ni , Hs , K ) .
nth . . . member ( 1 , [H I Hs ] , H ) .
ll - aubstitute ( l , [X I Xs ] , Y , [ YIXs ] ) + - I .
ll - aubstitute ( N , [X I Xs ] ,Y , [X I Xsl ] ) + -
N > 1 , ! , ni : = N - 1 , ll - aubstitute ( Nl , Xs , Y , Xsl ) .
next _ player ( computer , opponent ) .
next _ player ( opponent , computer ) .
legal ( [ NINs J ) ~ 0 < N , N < 7 , legal ( Ns ) .
legal ( [ ] ) .
swap ( board ( Hs , K ,Y s , L ) , board ( Y s ,L , Hs , K ) ) .
display _ game ( Position , computer ) + -
show ( Position ) .
display _ game ( Position , opponent ) + -
swap ( Position , Positionl ) , show ( Positionl ) .
show ( board ( H , K , Y , L ) ) + -
reverse ( H , HR ) , write - stones ( HR ) , write - ka ! ahs ( K , L ) , write - stones ( Y ) .
write -stones(H) +- ,-
nl , tab (5), display-holes(H) .
display holes([H IHs]) +-
write _pile (H), display-1Ioles(Hs).
display-1Ioles([ ]) +- nl .
20.3 Kalah 349
write _pile (N) ~ N < 10, write (N), tab (4).

write _pile (N) ~ N ? 10, write (N), tab (3).
write .Jtalahs(K ,L) +-
write (K ), tab (34), write (L) , nl .
zero([O,O,O,O,O,O]) .
non-zero(Hs) +- Hs :/: [0,0,0,0,0,0].
Initializing
lookahead(2).
initialize (kalah,board([N,N,N,N ,NN ],O,[N,N ,N,N,NN ] ,O),opponent) +-
pieces(N).
pieces(6).
The code gives all moves on backtracking . The predicate stones( M ,Board ,N)
returns the number of stones N in hole M of the Board if N is greater than 0, failing
if there are no stones in the hole . The predicate extend_move(M ,Board ,NiMs )
returns the continuation of the move Ms . The second clause for move handles the
special case when all the player 's holes become empty during a move .
Testing whether the move continues is nontrivial , since it may involve all the
procedures for making a move . If the last stone is not placed in the kalah , which
can be determined by simple arithmetic , the move will end , and there is no need
to distribute all the stones . Otherwise the stones are distributed , and the move
continues recursively .
The basic predicate for making a move is distribute _stones( Stones,N ,Board ,
Boardl ) which computes the relation that Boardl is obtained from Board by
distributing the number of stones in Stones starting from hole number N .
There are two stages to the distribution , putting the stones in the player 's
holes , distribute _my _holes, and putting the stones in the opponent 's holes , distribute
_your _holes.
The simpler case is distributing the stones in the opponent 's holes . The holes
are updated by distribute , and the distribution of stones continues recursively if
there is an excess of stones . A check is made to see if the player 's board has
become empty during the course of the move , and , if so, the opponent 's stones
are added to his kalah .
Distributing the player 's stones must take into account two possibilities , distributing
from any particular hole , and continuing the distribution for a large
number of stones . The pick _up_and_distribute is the generalization of distribute to

handle these cases. The predicate check_capture checks if a capture has occurred ,
and updates the holes accordingly , while update_kalah updates the number of
stones in the player 's kalah . Some other necessary utilities such as n_substitute
are also included in the program .
The evaluation function is the difference between the number of stones in the
two kalahs :
value(board(H ,K ,Y ,L),Value) +- Value := K- L .
The central predicates have been described . A running program is now obtained
by filling in the details for I / O , for initializing and terminating the game,
etc . Simple suggestions can be found in the complete program for the game, given
as Program 20.3.
In order to optimize the performance of the program , cuts can be added .
Another tip is to rewrite the main loop of the program as a failure - driven loop
rather than a tail recursive program . This is sometimes necessary in implementations
which do not incorporate tail recursion optimization and a good garbage
collector .
20 .4 Background
The mastermind program , slightly modified , originally appeared in SIGART

(Shapiro , 1983d) in response to a program for playing mastermind in Pascal . The
SIGART article provoked several reactions , both of theoretical improvements to
algorithms for playing mastermind , and practical improvements to the program .
Most interesting was an analysis and discussion by Powers (1984) of how a Prolog
program could be rewritten to good benefit using the mastermind code as a case
study . Eventually speedup by a factor of 50 was achieved .
A proof of the correctness of the algorithm for playing Nim can be found in
any textbook discussing games on graphs , for example , Berge (1962) .
Kalah was an early AI target for game-playing programs (Slagle & Dixon ,
1969) .
Chapter 21
A Credit Evaluation
Expert SysteIll
At the time of writing this book , there has been a surge of activity in the
application of artificial intelligence to industry . Of particular interest are expert
systems - programs designed to perform tasks previously allocated to highly
paid human experts . One important feature of expert systems is the explicit
representation of knowledge .
This entire book is relevant for programming expert systems . The example
programs typify code that might be written . For instance , the equation -solving
program of the next chapter can be , and has been , viewed as an expert system .
The knowledge of expert systems is usually expressed in a rulelike form . Prolog
whose basic statements are rules is thus a natural language for implementing
expert systems . We briefly discuss the relationship of Prolog rules to classical
expert systems such as MYCIN in the background to Chapter 19.
The chapter presents an account of developing a prototype expert system .
The example comes from the world of banking : to evaluate requests for credit
from small business ventures .
We give a fictionalized account of the development of a simple expert system

for evaluating client requests for credit from a bank . The account is from the
point of view of Prolog programmers , or knowledge engineers , commissioned by
the bank to write the system . It begins after the most difficult stage of building
an expert system , extracting the expert knowledge , has been underway for some
time . In accordance with received wisdom , the programmers have been consulting
with a single bank expert , ChasE . Manhattan . Chas has told us that three factors
are of the utmost importance in considering a request for credit from a "client ."
Clients refer to small business ventures .
352 A Credit Evaluation Expert System
The most important factor is the collateral that can be offered by the client in
case the venture folds . The various types of collateral are divided into categories .
Currency deposits , whether local or foreign , are first - class collateral . Stocks are
examples of second-class collateral , while the collateral provided by mortgages
and the like is regarded as illiquid .
Also very important is the client 's financial record . Experience in the bank
has shown that the two most important factors are the client 's net worth per assets
, and the current gross profits on sales. The client 's short -term debt per annual
sales should be considered in evaluating the record , and slightly less significant
is last year 's sales growth . For knowledge engineers with some understanding of
banking no further explanation of such concepts is necessary. In general a knowledge
engineer must understand the domain sufficiently to be able to communicate
with the domain expert .
The remaining factor to be considered is the expected yield to the bank .

This is a problem that the bank has been working on for a while . Programs exist
to give the yield of a particular client proille . The knowledge engineer can thus
assume that the information will be available in the desired form .
ChaoSuses qualitative terms in speaking about these three factors : "The client
had an excellent financial rating , or a good form of collateral . His venture would
provide a reasonable yield , etc ." Even concepts that could be determined quantitatively
are discussed in qualitative terms . The financial world is too complicated
to be expressed only with the numbers and ratios constantly being calculated . In
order to make judgments , experts in the financial domain tend to think in qualitative
terms with which they are more comfortable . To echo expert reasoning and
to be able to interact with ChaoSfurther , qualitative reasoning must be modeled .
On talking to Chas , it became clear that a significant amount of the expert
knowledge he described could be naturally expressed as a mixture of procedures
and rules . On being pressed a little on the second and third interviews Chas gave
rules for determining ratings for collateral , and financial rating . These involved
considerable calculations , and in fact Chas admitted that to save himself work in
the long term , he did a quick initial screen to see if the client was at all suitable .
This information is sufficient to build a prototype . We show how these comments
and observations are translated into a system . The top level basic relation is
credit(Client,Answer) where Answer is the reply given to the request by Client for
credit . The code has three modules - collateral , financial _rating and bank_yield
- corresponding to the three factors the expert said were important . The initial
screen that the client is worth considering in the first place is performed by
the predicate ok_profile(Client). The answer Answer is then determined with the
A Credit Evaluation Expert System 353
predicate evaluate(Profile ,Answer ) which evaluates the Profile built by the three
modules .
Being proud knowledge engineers , we stress the features of the top level
formulation in credit/ 2. The modularity is apparent . Each of the modules can be
developed independently without affecting the rest of the system . Further there is
no commitment to any particular data structure , i .e., data abstraction is used . For
this example a structure profile ( C,FY ) represents the profile of collateral rating
C, the financial rating F and the yield Y of a client . However , nothing central
depends on this decision and it would be easy to change it . Let us consider some
of the modular pieces.
Let us look at the essential features of the collateral evaluation module . The
relation collateral _rating / 2 determines a rating for a particular client 's collateral
. The first step is to determine an appropriate profile . This is done with
the predicate collateral _profile which classifies the client 's collateral as first _class,
second_class or illiquid , and gives the percentage each covers of the amount of
credit the client requested . The relation uses facts in the database concerning
both the bank and the client . In practice there may be separate databases for the
bank and the client . Sample facts shown in Program 21.1 indicate , for example ,
that local currency deposits are a first class collateral .
The profile is evaluated to give a rating by collateral _evaluation . It uses
"rules of thumb " to give a qualitative rating of the collateral : as excellent , good ,
etc . The first collateral _evaluation rule , for example , reads that : "The rating is
excellent if the coverage of the requested credit amount by first class collateral is
greater than or equal to 100 percent ."
Two features of the code bear comment . First , the terminology used in
the program is the terminology of ChaB. This makes the program (almost ) selfdocumenting
to the experts , and means they can modify it with little help from
the knowledge engineer . Allowing people to think in domain concepts also facilitates
debugging , and aBsists in using a domain independent explanation facility
aB discussed in Section 19.2. Second, the apparent naivete of the evaluation rules
is deceptive . There is a lot of knowledge and experience hidden behind these simple
numbers . Choosing poor values for these numbers may mean suffering severe
losses.
The financial evaluation module evaluates the financial stability of the client .
It uses items taken mainlY from the balance and profit / loss sheets. The financial
rating is also qualitative . A weighted sum of financial factors is calculated (by
score) and used by calibrate to determine the qualitative class.
354 A Credit Eval1
lation Expert System
Credit Evauation
crcdit ( Clicnt , A nswcr ) + -
Answer is the reply to a request by Client for credit .
credit ( Client , Answer ) + -
ok _ profile ( Client ) ,
collateral . . rating ( Client , Collateral Rating ) ,
financial . . rating ( Client , Financial Rating ) ,
bank _ yield ( Client , Yield ) ,
evaluate ( profile ( Collateral Rating , Financial Rating , Yield ) , Answer ) .
The collateral rating module
collateral _ rating ( Client , Rating ) + -
Rating is a qualitative description as ~ essing the collateral
offered by Client to cover the request for credit .
collateral Jating ( Client , Rating ) + - -
collateral _ profile ( Client , First Class , Second Class , Illiquid ) ,
collateral _ evaluation ( First Class , Second Class , Illiquid , Rating ) .
collateral _ profile ( Client , FirstClass , Second Class , illiquid ) + -
requested _ credit ( Client , Credit ) ,
collateral _ percent ( first _ class , Client , Credit , FirstClass ) ,
collateral _ percent ( second _ class , Client , Credit , SecondClass ) ,
collateral _ percent ( illiquid , Client , Credit , Illiquid ) .
collateral _ percent ( Type , Client , Total , Value ) + " -
set - of ( X , Collateral ! ( collateral ( Collateral , Type ) ,
amount ( Collateral , Client , X ) ) , Xs ) ,
sumlist ( Xs , Sum ) ,
Value : = Sum * 100 / Total .
Evaluation rules
f -
FirstClass ~ 100 .
collateral _ evaluation ( FirstClass , Second Class , Illiquid , excellent ) f -
FirstClass > 70 , FirstClass + Second Class ~ 100 .
collateral _ evaluation ( FirstClass , Second Class , Illiquid , good ) f -
FirstClass + Second Class > 60 ,
FirstClass + SecondClass < 70 ,
FirstClass + Second Class + Illiquid ~ 100 .
Program 21 . 1 : A credit evaluation system

Bank data - classification of collateral

collateral (local_currency_deposits,first _class) .
collateral(foreign_currency_deposits,first -class).
collateral (negotiateJnstruments ,second_class).
collateral (mortgage,illiquid ).
Financial rating
financial _rating( Client,Rating) +-
Rating is a qualitative description assessingthe financial
record offered by Client to support the request for credit .
financial..xating(Client,Rating ) +-
financial Jactors (Factors) ,
score(Factors,Client,O,Score) ,
calibrate(Score,Rating) .
Financial evaluation rules
calibrate(Score,bad) +- Score:$: - 500.
calibrate(Score,medium) +- - 500 < Score, Score < 150.
calibrate(Score,good) +- 150 :$: Score, Score < 1000.
calibrate(Score,excellent) +- Score :;?: 1000.
Bank data - weighting factors
financiaI Jactors([(net_worth _per_assets,5),
(last_year..sales_growth,l ),
(gross_profits _on..sales,5),
(short_term-debt_per -aIlnual ..sales,2) ]) .
score([(Factor,Weight) IFactors] ,Client ,Acc,Score) +-
value(Factor ,Client,Value),
Accl is Acc + Weight*Value,
score(Factors,Client ,Acc 1,Score).
score([ ],Client ,Score,Score).
Final evaluation
evaluate(Profile, Outcome) +-
Outcomeis the reply to the client'8 Profile.
evaluate(Profile,Answer) ~
rule (Conditions,Answer), verify (Conditions,Profile).
verify ([condition (Type,Test,Rating) IConditions] ,Profile) +-

scale(Type ,Scale) ,
select-value(Type,Profile,Fact),
compare(Test,Scale,Fact,Rating ),
verify (Conditions,Profile).
verify ([ ],Profile) .
compare('= ' ,Scale,Rating ,Rating ).
compare('> ',Scale,Ratingl ,Rating2) +-
precedes(Scale,Ratingl ,Rating2).
compare(' ~ ',Scale,Ratingl ,Rating2) +-
precedes(Scale,Ratingl ,Rating2) ; Ratingl = Rating2.
compare('< ',Scale,Ratingl ,Rating2) +-
precedes(Scale,Rating2,Ratingl ) .
compare('~ ',Sc;:ale,Ratingl ,Rating2) +-
precedes(Scale,Rating2,Ratingl ) ; Ratingl = Rating2.
precedes([Rli Rs] ,Rl ,R2) .
precedes([RIRs],Rl ,R2) +- R =f R2, precedes(Rs,Rl ,R2).
select_value(collateral,profile(C,FY)
, C).
select_value(finances,profile(C,FY ),F).
select_value(yield ,profile(C,FY ),Y ).
Utilities
sumlist(Xs,Sum) +- SeeProgram 8.6b.

Bank data and rules
rule ( (condition (collateral,' ~ ',excellent) ,condition (finances,, ~ ',good),

condition (yield ,'~ ',reasonable)] ,give_credit) .
rule ((condition (collateral,'= ' ,good) ,condition (finances,'= ',good) ,
condition (yield ,' ~ ' ,reasonable)] ,consult..superior).
rule( (condition (collateral,' ~ ' ,moderate) ,condition (finances,' ~ ' ,medium)],
refuse_credit).
scale(collateral,[excellent,good,moderate]) .
scale(finances,[excellent,good,medium,bad]) .
scale(yield , [excellent,reasonable,poor]).
Client Data
bank _yield ( clientl ,excellent ).

requested _credit ( clientl ,50000 ) .
amount (local _currency _deposits ,client 1 ,30000 ) .

amount (foreign _currency _deposits ,clientl ,20000 ) .
amount (bank _guarantees ,client 1 ,3000 ) .
amount (negotiate - instruments ,client 1 ,5000 ) .

amount ( stocks ,clientl ,9000 ) .
amount ( mortgage ,clientl , 12000 ) .

amount ( documents ,clientl , 14000 ) .
value ( net - worth _per _assets , client 1 ,40 ) .

value (last _year ...sales _growth ,client 1 ,20 ) .
value ( gross _profits _on ...sales ,client 1 ,45 ) .
value ( short -term _debt _per - alinual ...sales ,client 1 ,9 ) .
ok _profile ( client 1) .
Program 21 . 2 : Test data for the credit evaluation system
It should be noted that both the modules giving the collateral rating and
the finarlcial rating reflect the point of view and style of a particular expert ,
Chas Manhattan , rather than the universal truth . Within the bank there is no
consensus about the subject . Some people tend to be conservative and some are
prepared to take considered risks .
Programming the code for determining the collateral and financial ratings
proceeded easily . The knowledge provided by the expert was more - or - less directly
translated into the program . The module for the overall evaluation of the client ,
however , was more challenging .
The major difficulty was formulating the relevant expert knowledge . Our
expert was less forthcoming with general rules for overall evaluation than for
rating the financial record , for example . He happily discussed the profiles of
particular clients , and the outcome of their credit requests and loans , but was
reluctant to generalize . He preferred to react to suggestions rather than volunteer
rules .
This forced a close re-evaluation of the exact problem we were solving . There
were three possible answers the system could give : approve the request for credit ,
refuse the request , or ask for advice . There were three factors to be considered .
Each factor had a qualitative value that was one of a small set of possibilities . For
358 A Credit EvaluationExpert System
example , the financial rating could be bad , medium , good or excellent . Further
the possible values were ranked on an ordinal scale .
Our system clearly faced an instance of a general problem : find an outcome

from some ordinal scale based on the qualitative results of several ordinal scales .
Rules to solve the / problem were thus to give a conclusion based on the outcome
of the factors .- We pressed Chas with this formulation and he rewarded us with
several rules . Here is a typical one : " If the client ' s collateral rating is excellent ( or
better ) , her financial rating good ( or better ) , and her yield at least reasonable ,
then grant the credit request ."
An immediate translation of the rule is
evaluate ( profile ( excellent , good ,reasonable ) ,give _credit ).
But this misses many cases covered by the rule , for example , when the client 's
profile is ( excellent , good , excellent ). All the cases for a given rule can be listed .
It seemed more sensible , however , to build a more general tool to evaluate rules
expressed in terms of qualitative values from ordinal scales .
There is potentially a problem with using ordinal scales due to the large
number of individual cases that may need to be specified . If each of the N
modules have M possible outcomes , there are NM cases to be considered . In
general , it is infeasible to have a separate rule for each possibility . Not only is
space a problem for so many rules , but the search involved in finding the correct
rule may be prohibitive . So instead we defined a small ad hoc set of rules . We
hoped the rules defined , which covered many possibilities at once , would be sufficient
to cover the clients the bank usually deal with . We chose the structure
rule ( Conditions , Conclusion ) for our rules , where Conditions is a list of conditions
under which the rule applies and Conclusion is the rule ' s conclusion . A condition
has the form condition ( Factor , Relation , Rating ) , insisting that the rating from the
factor named by Factor bears the relation named by Relation to the rating given
by Rating .
The relation is represented by the standard relational operators : < , = ,> ,

etc . The previously mentioned rule is represented M
rule ( [condition ( collateral , ' ~ ' , excellent ) , condition ( finances , ' ~ ' , good ),
condition ( yield , ' ~ ' ,reasonable ) ) , give _credit ).
Anot 'her rule given by Ohas reads : " If both the collateral rating and financial
rating are good , and the yield is at least reasonable , then consult your superior ."
This is translated to
rule ((condition (collateral,'= ',good) ,condition (finances,'= ' ,good),

condition (yield ,' ~ ' ,reasonable)] ,consult-superior).
Factors can be mentioned twice to indicate they lie in a certain range , or might
not be mentioned at all . For example , the rule
rule ( [condition (collateral ,' $ ' ,moderate ) ,condition (finances ,' $ ' ,medium )],
refuse_credit).
states that a client should be refused credit if the collateral rating is no better than
moderate and the financial rating is at best medium . The yield is not relevant ,
and so is not mentioned .
The interpreter for the rules is written nondeterministic ally . The procedure
is : "Find a rule and verify that its conditions apply ," as defined by evaluate . The
predicate verify ( Conditions ,Profile ) checks that the relation between the corresponding
symbols in the rule and the ones that are associated with the Profile
of the client is as specified by Conditions . For each Type that can appear , a
scale is necessary to give the order of values the scale can take . Examples of
scale facts in the bank database are scale( collateral , [excellent , good, moderate])
and scale(finances , [excellent , good, medium , bad] ) . The predicate select_value returns
the appropriate symbol of the factor under the ordinality test which is performed
by compare. It is an access predicate , and consequently the only predicate
dependent on the choice of data structure for the profile .
At this stage the prototype program is tested . Some data from real clients is
necessal' Y, and the answer the system gives on these individuals is tested against
what the corresponding bank official would say. The data for clientl is given in
Program 21.2. The reply to the query credit ( clientl ,X) is give_credit .
Our prototype expert system is a composite of styles and methods - not
just a backward chaining system . Heuristic rules of thumb are used to determine
the collateral rating ; an algorithm , albeit a simple one, is used to determine the
financial rating ; and there is a rule language , with an interpreter , for expressing
outcomes in terms of values from discrete ordinal scales. The rule interpreter proceeds
forwards from conditions to conclusion , rather than backward as in Prolog .
Expert systems must become such composites in order to exploit the different
forms of knowledge already extant .
The development of the prototype was not the only activity of the knowledge
engineers . Various other features of the expert system were developed in parallel .
An explanation facility was built as an extension of Program 19.9. A simulator for
rules based on ordinal scales was built to settle the argument among the knowledge
engineers as to whether a reasonable collection of rules would be sufficient to cover
the range of outcomes in the general case.

Finally a consistencycheckerfor the rules was built . The following metarule
is an obvious consistencyprinciple : "If all of client A 's factors are better than or
equal to client B 's, then the outcome of client A must be better than or equal to
that of client B ."
21.1 Background
More details on the credit evaluation system can be found in Ben-David and
Sterling (1985).
Chapter 22
An Equation Solver
A very natural area for Prolog applications is symbolic manipulation . For

example , a Prolog program for symbolic differentiation , a typical symbol manipulation
task , is just the rules of differentiation in different syntax , as shown in
Program 3.29.
In this chapter we present a program for solving symbolic equations . It is
a simplification of PRESS (PRolog Equation Solving System ) developed in the
mathematical reasoning group of the department of Artificial Intelligence at the
University of Edinburgh . PRESS performs at the level of a mathematics student
in her final year of high school .
The structure of the chapter is as follows . The first section gives an overview
of equation solving with some example solutions . The remaining four sections
cover the four major equation solving methods implemented in equation solver .
22 .1 An overview of equation solving
The task of equation solving can be described syntactically . Given an equation

Lhs = Rhs in an unknown X , transform the equation into an equivalent equation
X = Rhsl , where Rhsl does not contain X . This final equation is the solution .
Two equations are equivalent if one is transformed into the other by a finite
number of applications of the axioms and rules of algebra .
Successful mathematics students do not solve equations by blindly applying
axioms of algebra . Instead they learn , develop and use various methods and
strategies . Our equation solver , modeling this behavior , is accordingly a collection
of methods to be applied to an equation to be solved . Each method transforms
the equation by applying identities of algebra expressed as rewrite rules . The
362 An Equation Solver 22.1
(i) cos(x) . (1 - 2 . sin(x)) = 0

(ii ) x2 - 3 . x + 2 = 0
(iii ) 22':1: - 5 . 2:1:+ 1 + 16 = 0
Figure 22.1: Test equations
methods can and do take widely different forms . They can be a collection of rules
for solving the class of equations to which the method is applicable , or algorithms
implementing a decision procedure .
Abstractly a method has two parts : a condition testing whether the method
is applicable , and the application of the method itself .
The type of equations our program can handle are indicated by the three
examples in Figure 22.1. They consist of algebraic functions of the unknown , that
is + , - , * , / , and exponentiation to an integer power , and also trigonometric and
exponential functions . The unknown is x in all three equations .
We briefly show how each equation is solved .
The first step in solving equation (i ) in Figure 22.1 is factorization . The
problem to be solved is reduced to solving cos(x) = 0 and 1- f2.sin (x) = o. A solution
to either of these equations is a solution to the original equation .
Both the equations cos(x) = O and 1- 2.sin (x) = O are solved by making x the
subject of the equation . This is possible since x occurs once in each equation .
The solution to COS
( x) = 0 is x= arccos( 0) . The solution of 1- 2.sin ( x) = 0 takes
the following steps:
1- 2.sin (x ) = 0,
2.sin (x ) = 1,
sin (x ) = 1/ 2,
x = arcsin (1/ 2) .
In general , equations with a single occurrence of the unknown can be solved by an

algorithmic method , called isolation . The method repeatedly applies an appropriate
inverse function to both sides of the equation until the single occurrence of
the unknown is "isolated " as the left -hand side of the equation . Isolation solves
1- 2.sin (x) = 0 by producing the above sequence of equations .
Equation (ii ) in Figure 22.1, xZ- 9.x + 2= O, is a quadratic equation in x. We all
learn in high school a formula for solving quadratic equations . The discriminant ,
b2- 4.a.ciscalculated , in this case (- 9) 2 - 4.1.2 which equals 1, and two solutions
are given : x= ( - ( - 9) + VI )/ 2 which equals 2, and x= ( - ( - 9) --.j "i)/ 2 which equals 1.
22.1 An overview of equation solving 363
The key to solving equation (iii ) in Figure 22.1 is to realize that the equation
is really a quadratic equation in ~ . The equation ~ .x_5.f! + 1 + 16= 0 can be
rewritten as (~ )2- 5'2'~ + 16= O. This can be solved for fJXgiving two solutions
of the form ~ = Rhs, where Rhs is free of x. Each of these equations are solved
for x to give solutions to equation (iii ).
PRESS was tested on equations taken from British A -level examinations in
mathematics . It seems that examiners liked posing questions such as equation
(iii ) which involved the student manipulating logarithmic , exponential or other
transcendental functions into forms where they could be solved as polynomials .
A method called homogenization evolved to solve equations of these type .
The aim of homogenization is to transform the equation into a polynomial in
some term containing the unknown. (We simplify the more general homogenization
of PRESS for didactic purposes.) The method consists of four steps which
we illustrate for equation (iii ). The equation is first parsed and all maximal nonpolynomial
terms containing the unknown are collected with duplicates removed.
This set is called the offenders set. In the example it is { & :I:,~ +l } . The second
step is finding a term , known as the reduced term . The result of homogenization
is a polynomial equation in the reduced term . The reduced term in our example
is ~ . The third step of homogenization is finding rewrite rules that express
each of the elements of the offenders set as a polynomial in the reduced term .
Finding such a set guarantees that homogenization will succeed. In our example
the rewrite rules are & :1:= (~ )2 and 2(:1:+1) = 2.~ . Finally , the rewrite rules are
applied to produce the polynomial equation .
We complete this section with a brief overview of the equation solver . The
basic predicate is solve_equation(Equation,X ,Solution) . The relation is true if
Solution is a solution to Equation in the unknown X . The complete code appears
as Program 22.1.
Program 22.1 has four clauses for solve_equation , one for each of the four
methods needed to solve the equations in Figure 22.1. More generally , there is
a clause for each equation solving method . The full PRESS system had several
more methods .
Our equation solver ignores several features that might be expected . There
is no simplification of expressions , no rational arithmetic , no record of the last
equation solved , no help facility , and so forth . PRESS did contain many of these
facilities as discussed briefly in the background section at the end of this chapter .
22.2 Factorization
Factorization is the first method attempted by the equation solver . Note

that the test whether factorization is applicable is trivial , being unification with
the equation A * B = O. If the test succeeds, the simpler equations are recursively
solved . The top -level clause implementing factorization is
solve_equation (A * B = O,X ,Solution ) .--

factorize (A * B ,X ,Factors \ [ ]) ,
remove _duplicates (Factors ,Factors l ) ,
solve Jactors (Factorsl ,X ,Solution ) .
The top -level clause in Program 22.1 has a cut as the first goal in the body . This
is a green cut : none of the other methods depend on the success or failure of
factorization . In general we omit green cuts from clauses we describe in the text .
22 .3 Isolation
A useful concept to locate and manipulate the single occurrence of the unknown
is its position . The position of a subterm in a term is a list of argument
numbers specifying where it appears . Consider the equation cos(x) = O. The term
cos(x) containing x is the first argument of the equation , and x is the first (and
only ) argument of cos(x) . The position of x in cos(x) = 0 is therefore [1,1]. This is
indicated in the diagram in Figure 22.2. The figure also shows the position of x
in 1- 2.sin (x) = 0 which is [1,2,2,1] .
The clause defining the method of isolation is
solve_equation (Equation ,X ,Solution ) +-

single _occurrence (X ,Equation ) ,
position (X ,Equation , [Side/Position ]) ,
maneuver -sides(Side,Equation ,Equationl ) ,
isolate (Position ,Equation 1,Solution ) .
The condition characterizing when isolation is applicable is that there be a

single occurrence of the unknown X in the equation , checked by single_occurrence.
The method calculates the position of X with the predicate position . The isolation
of X then proceeds in two stages. First , maneuver _sides ensures that X appears
on the left -hand side of the equation , and second, isolate makes it the subject of
the formula .
22.3 Isolation 365
solve _equation ( Equation , Unknown ,8olution ) +-

Solution is a solution to the equation Equation in the unknown Unknown
solve _equation (A * B = O,X ,Solution ) +-

,.,
factorize (A * B ,X ,Factors \ [ ]) ,
remove _duplicates (Factors ,Factcrs 1) ,
solve Jactors (Factorsl ,X ,Solution ) .
solve_equation (Equation ,X ,Solution ) +-
single -occurrence (X ,Equation ) ,
,.,
position (X ,Equation , (Side IPosition ]) ,
maneuver ....sides(Side ,Equation ,Equation 1) ,
isolate (Position ,Equationl ,Solution ) .
solve_equation (Lhs = Rhs ,X ,Solution ) +-
polynomial(Lhs,X),
polynomial(Rhs,X) ,
,.,
polynomial - normal -Iorm (Lhs - Rhs ,X ,Poly Form ) ,
solve_polynomial _equation (Poly FormiX ,Solution ) .
solve_equation (Equation ,X ,Solution ) i - .
homogenize (Equation ,X ,Equationl ,Xl ) ,
,.,
solve_equation (Equationl ,Xl ,Solutionl ) ,
solve_equation (Solutionl ,X ,Solution ) .
The factorization method
factorize ( Expression ,Subterm , Factors ) +-
splits the multiplicative term Expression into a
difference -list of Factors containing the Subterm .
factorize (A * B ,X ,Factors \ Rest ) +-

!, factorize (A ,X ,Factors \ Factorsl ) , factorize (B ,X ,Factorsl \ Rest ) .
factorize (C ,X , [C IFactors ] \ Factors ) i -
subterm(X ,C), !.
factorize(C ,X ,Factors\ Factors).
solve-factors (Factors , Unknown , Solution ) +-
Solution is a solution of the equation Factor = O in the
Unknown for some Factor in the list of Factors .
Program 22 . 1: A program for solving equations

366 An EquationSolver 22.3
solve Jactors ( [ Factorl Factors J , X , Solution ) + -
solve _ equation ( Factor = O , X , Solution ) .
solve Jactors ( [ Factor I Factors ] , X , Solution ) + -
solve Jactors ( Factors , X , Solution ) .
The isolation method
single _ occurrence ( Subterm , Term ) + -
occurrence ( Subterm , Term , ! ) .
maneuver - sides ( l , Lhs = Rhs , Lhs = Rhs ) + - ! .
maneuver - sides ( 2 , Lhs = Rhs , Rhs = Lhs ) + - ! .
isolate ( [ N I Position ] , Equation , Isolated Equation ) + -
isolax ( N , Equation , Equationl ) ,
isolate ( Position , Equationl , Isolated Equation ) .
isolate ( [ ] , Equation , Equation ) .
Axioms foT Isolation
isolax ( l , - Lhs = Rhs , Lhs = - Rhs ) . % Unary minus
% Addition
isolax ( 1 , Terml + Term2 = Rhs , Terml = Rhs - Term2 ) .
% Addition
isolax ( 2 , Terml + Term2 = Rhs , Term2 = Rhs - Terml ) .
% Subtraction
isolax ( 1 , Terml - Term2 = Rhs , Terml = Rhs + Term2 ) .
% Subtraction
isolax ( 2 , Terml - Term2 = Rhs , Term2 = Terml - Rhs ) .
isolax ( l , Terml * Term2 = Rhs , Terml = Rhsj Term2 ) + - % Multiplication
Term2 # O .
isolax ( 2 , Terml * Term2 = Rhs , Term2 = Rhsj Terml ) + - % Multiplication
Terml # O .
isola . x ( l , Terml jTerm2 = Rhs , Terml = Rhsj ( - Term2 ) ) . % Exponentiation
isola . x ( 2 , Termlj Term2 = Rhs , Term2 = log ( base ( Terml ) , Rhs ) ) . % Exponentiation
isolax ( l , sin ( U ) = V , U = arcsin ( V ) ) .

% Sine
isolax ( l , sin ( U ) = V , U = 7r - arcsin ( V ) ) .
% Sine
isolax ( l , cos ( U ) = V , U = arccos ( V ) ) .
% Cosine
isolax ( l , cos ( U ) = V , U = - arccos ( V ) ) .
% Cosine
The polynomial methods
polynomial ( Term , X ) + - See Program 11 . 4
polynomial _ normal _ form ( Expression , Term , PolyNormalForm ) + -
Poly NormalForm is the polynomial normal form of
Expression , which is a polynomial in Term
Program 22 . 1 ( Continued )
22..'? Isolation 367
polynomial -I1ormal. 1orm(Polynomial ,X ,NormalForm) +-

polynomial .1orm(Polynomial,X ,PolyForm) ,
remove-zero_terms (PolyForm,NormalForm), !.
polynomial Jorm (X ,X ,[(l ,1)]) .
polynomial Jorm (X iN ,X ,[(l ,N)]).
polynomial Jorm (Term 1+ Term2,X ,Poly Form) ~
polynomial Jorm (Terml ,X ,PolyForm l ),
polynomial Jorm (Term2,X ,PolyForm2),
add_polynomials (Poly Form 1,PolyForm2,PolyForm).
polynomial Jorm (Terml - Term2,X ,PolyForm) ~
polynomial Jorm (Term 1,X ,Poly Forml ),
polynomial Jorm (Term2,X ,Poly Form2),
subtract _polynomials (Poly Forml ,PolyForm2,PolyForm) .
polynomial Jorm (Term 1* Term2,X ,Poly Form) ~
polynomial Jorm (Terml ,X ,Poly Forml ),
polynomial Jorm (Term2,X ,Poly Form2),
multiply _polynomials (Poly Form 1,PolyForm2,PolyForm).
polynomial Jorm (TermiN ,X ,PolyForm) ~ !,
polynomial Jorm (Term,X ,PolyForml ) ,
binomial (PolyForml ,N ,Poly Form).
polynomial Jorm (Term ,X ,[(Term,O)]) ~
free_of(X ,Term) , t.
remove..zero_terms ([(0,N) IPoly] ,Poly 1) +-
!, remove..zero_terms(Poly,Polyl ).
remove..zero_terms([(C,N) IPoly],[(C,N) IPolyl ]) +-
C ~ 0, !, remove..zero_terms(Poly,Polyl ).
remove..zero_terms([ ],[ ]).
Polynomial manipulation routines
add_polynomials(Polyl ,Poly2,Poly) +-
Poly is the sum of Polyland Poly2 , where Polyl ,
Poly2 and Poly are all in polynomial form
add_polynomials([ ],Poly,Poly) +- !.
add_polynomials (Poly, [ ] ,Poly) +- !.
add_polynomials([(Ai ,Ni ) IPolyl ],[(Aj ,Nj ) IPoly2],[(Ai ,Ni ) IPoly]) +-
Ni > Nj , !, add_polynomials(Polyl ,[(Aj ,Nj ) IPoly2],Poly).
add_polynomials([(Ai ,Ni) IPolyl ] ,[(Aj ,Nj ) IPoly2],[(A ,Ni ) IPoly]) +-
Ni = := Nj , !, A := Ai + Aj , add_polynomials(Polyl ,Poly2,Poly).
add_polynomials([(Ai ,Ni ) IPolyl ],[(Aj ,Nj ) IPoly2] ,.[(Aj ,Nj ) IPoly]) +-
Ni < Nj , !, add_polynomials([(Ai ,Ni )IPolyl ],Poly2,Poly).
8ubtract_polynomials(P oly1,P oly2, Poly) +-

Poly is the difference of Poly1 and Poly2 , where Poly1 ,
Poly2 and Poly are all in polynomial form .
subtract _polynomials (Poly 1,Poly2,Poly) +-

multiply ...single(Poly2,(- 1,O),Poly3),
add_polynomials (Poly 1,Poly3 ,Poly), !.
multiply _single(Polyl ,Monomial, Poly) +-
Poly is the product of Polyland Monomial , where Polyl ,
and Poly are in polynomial form , and Monomial has the
form C,N) denoting the monomial C*xN
multiply -single([(Cl ,Nl ) IPoly1],(C,N),[(C2,N2) IPoly]) +-
C2 := C1*C, N2 := Nl + N, multiply -single(Poly1,(C,N),Poly).
multiply -single([ ],Factor,[ ]).
multiply_polynomials(P olyl ,P oly2,Poly) ~
Poly is the product of Polyland Poly2 , where Polyl ,
Poly2 and Poly are all in polynomial form
multiply -polynomials([(C,N) IPoly1] ,Poly2,Poly) +-

multiply -Bingle(Poly2,(C,N),Poly3),
multiply _polynomials (Poly 1,Poly2,Poly4),
add_polynomials (Poly3,Poly4,Poly) .
multiply -polynomials([ ],P,[ ]).
binomial (Poly,l ,Poly) .
Polynomial equation solver
solve_polynomial-equation(Equation, Unknown, Solution) +-

Solution is a solution to the
polynomial Equation in the unknown Unknown
solve_polynomial _equation(PolyEquation ,X ,X = - Bj A ) +-
linear (PolyEquation ), I,
pad (Poly Equation ,[(A ,l ) ,(B,O)]).
solve_polynomial_equation(PolyEquation ,X ,Solution) +-
quadratic(Poly Equation), I,
pad (Poly Equation ,[(A ,2),(B ,l ),(C,O)]),
discriminant (A ,B,C,Discriminant ),
root (X ,A ,B,C,Discriminant ,Solution) .
discriminant (A ,B,C,D) +- D := B *B - 4*A * C.
22 . 3
Isolation 369
root ( X , A , B , C , O , X = - B / ( 2 * A ) ) .
root ( X , A , B , C , D , X = ( - B + sqrt ( D ) ) / ( 2 * A ) ) + - D > o .
root ( X , A , B , C , D , X = ( - B - sqrt ( D ) ) / ( 2 * A ) ) + - D > o .
pad ( [ ( C , N ) I Poly ] , [ ( C , N ) I Polyl ] ) + -
! , pad ( Poly , Polyl ) .
pad ( Poly , [ ( O , N ) I Polyl ] ) + -
pad ( Poly , Polyl ) .
pad ( [ ] , [ ] ) .
linear ( [ ( CoefI , l ) I Poly ] ) .
quadratic ( [ ( CoefI , 2 ) I Poly ] ) .
The homogenization method
homogenize ( Equation , X , Equationl , Xl ) ~
The Equation in X is transformed to the polynomial

Equationl in Xl where Xl contains X .
homogenize(Equation ,X ,Equationl ,Xl ) +-
offenders(Equation ,X ,Offenders),
reduced_term (X ,Offenders,Type,Xl ),
rewrite (Offenders,Type,Xl ,Substitutions),
substitute (Equation ,Substitutions ,Equationl ).
offenders(Equation, Unknown, Offenders) +-
Offenders is the set of offenders of the equation in the Unknown
offenders(Equation ,X ,Offenders) +-
parse(Equation ,X ,Offenders1\ [ ]),
remove_duplicates(Offendersl ,Offenders).
multiple (Offenders).
reduced_term (X ,Offenders,Type,Xl ) +-
classify(Offenders,X ,Type),
candidate(Type,Offenders,X ,Xl ) .
Heuristics for exponential equations
clagsify(Offenders,X ,exponential) +-
exponential_offenders(Offenders,X ).
exponential_offenders([A t BIOffs],X ) +-
free_of(X ,A ), subterm (X ,B), exponential_offenders(Offs,X ).
exponential_offenders([ ],X ).
candidate(exponential,Offenders,X ,A jX ) +-
base(Offenders,A ) , polynomial -exponents(Offenders,X ).
base ( [A j BIOffs ] ,A ) + - base ( Offs ,A ) .

base ( [ ] ,A ) .
polynomial _exponents ( [A i BIOffs ] ,X ) + -
is - polynomial ( B ,X ) , polynomial - exponents ( OtIs ,X ) .

polynomial _exponents ( [ ] ,X ) .
Parsing the equation and making substitutions
parse ( Expression , Term , Offenders ) +-

Expression is traversed to produce the set of Offenders in Term ,
that is , the nonalgebraic subterms of Expression containing Term
parse(A+ B,X,Ll \ 12) i -

!, parse(A,X,Ll \ 13), parse(B,X,L3\ 12).
parse(A*B,X ,11\ L2) i -
!, parse(A,X,Ll \ 13), parse(B,X,L3\ L2).
parse(AB ,X ,11\ L2) i -
!, parse(A,X,Ll \ L3), parse(B,X,L3\ L2).
parse(A= B,X,11\ L2) i -
!, parse(A,X,Ll \ L3), parse(B,X,13\ L2).
parse(A jB ,X,L) i -
integer(B), !, parse(A,X,L).
parse(A,X,L\ L) i -
free_of(X,A), !.
parse(A,X,[AIL]\ L) +-
subterm(X,A), !.
substitute ( Equation , Substitutions ,Equationl ) +-
The list of Substitutions is applied to Equation to produce Equationl
substitute (A + BiSubs ,New A + New B ) +-
I, substitute (A ,Subs,New A ) , substitute (B ,Subs,New B ) .
substitute (A * BiSubs ,New A * New B ) +-
substitute (AB ,Subs,New A - New B ) +-
substitute (A = BiSubs ,New A = New B ) +-
substitute (A tB ,Subs,New A tB ) +-
integer (B ) , I, substitute (A ,Subs,New A ) .
substitute (A ,SubsiB ) +-
member (A = BiSubs ) , I.
substitute (A ,Subs,A ) .
Program 22 . 1 (Continued )
22.3 Isolation 371
Finding homogenization rewrite rules

rewrite ([Off IOffs],Type ,Xl ,[Off= Term I Rewrites]) +-
homog_axiom (Type,Off,Xl ,Term) ,
rewrite (Offs,Type,Xl ,Rewrites).
rewrite ([ ],Type,X ,[ ]).
Homogenization axioms
homog_axiom(exponential,A j (N*X ),A jX ,(A jX )jN ).
homog_axiom(exponential,A j (- X ),A jX ,l / (A jX )).
homog_axiom(exponential,A j (X + B),A jX ,A jB *A jX ).
Utilities
subterm(Sub,Term) +- SeeProgram 9.2.
posi~ion (Term,Term,[ ]) ~ !.
position (Sub,Term,Path ) ~
compound(Term), functor (Term,F ,N), position (N ,Sub,Term,Path), !.
position (N ,Sub,Term,[N IPath]) +-
arg(N ,Term,Arg ), position (Sub,Arg ,Path).
position (N ,Sub,Term,Path) +-
N > 1, ni := N- 1, position (ni ,Sub,Term,Path).
free_of(Subterm,Term) +-
occurrence(Subterm,Term,N), !, N= O.
single_occurrence(Subterm,Term) ~
occurrence(Subterm,Term,N), !, N= l .
occurrence(Term,Term,l ) +- !.
occurrence(Sub,Term,N) +-
compound(Term), !, functor (Term,F ,M), occurrence(M ,Sub,Term,O,N).
occurrence(Sub,Term,O).
occurrence(M ,Sub,Term,Nl ,N2) +-
M > 0, !, arg(M ,Term,Arg ), occurrence(Sub,Arg ,N), N3 := N+ Nl ,
Ml := M - l , occurrence(Ml ,Sub,Term,N3,N2).
occurrence(O,Sub,Term,NN ).
multiple ([Xl ,X2IXs]).
Testing and data
test_press(X ,Y ) +- equation(X ,EU ), solve_equation(EU ,Y ) .
equation(l ,cos(x) * (1- 2*sin(x) )= O,x ).
equation(2,xj2 - 3*x+ 2= 0,x ).
equation(3,2j (2*x )- 5*2j (x+ l )+ 16= 0,x ).
Figure 22.2: Positionof subtermsin terms
It is useful to define single_occurrence in terms of the more general predicate

occurrence( Subterm , Term ,N) which counts the number of times N that Subterm
occurs in the term Term . Both occurrence and position are typical structure
inspection predicates . Both are posed as exercises at the end of Section 9.2. Code
for them appears in the utilities section of Program 22.1.
The predicate maneuver _sides(N ,Equation ,Equationl ) consists of two facts :
maneuver -sides(l ,Lhs = Rhs ,Lhs = Rhs ) .

maneuver -sides(2,Lhs = Rhs ,Rhs = Lhs ) .
Its effect is to ensure that the unknown appears on the left -hand side of Equationl .
The first argument N , the head of the position list , indicates the side of the
equation in which the unknown appears . A 1 means the left -hand side, and the
equation is left intact . A 2 means the right -hand side, and so the sides of the
equation are swapped .
The transformation of the equation is done by isolate / 3. It repeatedly applies
rewrite rules until the position list is exhausted :
22.3 Isolation 373
isolate ( [N IPosition ] ,Equation ,Isolated Equation ) +-

isolax (N ,Equation ,Equationl ) ,
isolate (Position ,Equationl ,Isolated Equation ) .
isolate ( [ ] ,Equation ,Equation ) .
The rewrite rules , or isolation axioms , are specified by the predicate iso-
lax(N ,Equation ,Equation1 ) . Let us consider an example used in solving 1-
2,sin (x) = 0. An equivalence transformation on equations is adding the same quantity
to both sides of an equation . We show its translation into an isolax axiom for
manipulating equations of the form u- v= w. Note that rules need only simplify
the left -hand side of equations , since the unknown is guaranteed to be on that
side.
Two rules are necessary to cover the two cases whether the first or second
argument of u- v contains the unknown . The term u- v= w can be rewritten to
either u= w+ v or v= u- w. The first argument of isolax specifies which argument
of the sum contains the unknown . The Prolog equivalent of the two rewrite rules
is then
isolax(1,Terml - Term2 = Rhs,Terml = Rhs+ Term2).

isolax(2,Terml - Term2 = Rhs,Term2 = Terml - Rhs).
Other isolation axioms are more complicated . Consider simplifying a product on

the left -hand side of an equation . One of the expected rules would be
isolax(1,Terml *Term2 = Rhs,Terml = Rhsj Term2).
If Term !! equals zero , however , the rewriting is invalid . A test is therefore added
which prevents the axioms for multiplication being applied , if the term by which
it divides is o. For example ,
isolax(l ,Terml *Term2 = Rhs,Terml = Rhsj Term2) +- Term2 =1=O.
Isolation axioms for trigonometric functions illustrate another possibility that

must be catered for - multiple solutions- An equation such as sin(x) = 1/ 2 that
is reached in our example has two solutions between 0 and 2-7r- The alternate
solutions are handled by having separate isolax axioms :
isola.x(l ,sin(U) = V ,U = arcsin(V )).
isola.x(l ,sin(U) = V ,U = 1r - arcsin(V )) .
In fact the equation has a more general solution . Integers of the form 2.n'7r
can be added to either solution for arbitrary values of n. The decision whether a
particular or general solution is desired depends on context , and semantic infor
mation , independent of the equation solver .
Further examples of isolation axioms are given in the complete equation

solver , Program 22.1.
The code described so far is sufficient to solve the first equation in Figure 22.1,
cos(x) .(1- 2.sin (x) ) = O. There are four answers; arccos( O) , - arccos(O) , arcsin ((l -
0)/ 2) , 1r- arcsin ( (1- 0)/ 2) . Each can be simplified , for example , arcsin ((1- 0)/ 2) to
1r/ 6, but will not be unless the expression is explicitly evaluated .
The usefulness of an equation solver depends on how well it can perform
such simplification , even though simplification is not strictly part of the equation
solving task . Writing an expression simplifier is nontrivial , however . It is undecidable
whether two expressions are equivalent in general . Some simple identities
of algebra can be easily incorporated , for example , rewriting O+ u to u. Choosing
between other preferred formse .g., (1 + x) 3 and 1+ 3.x+ 3.xZ+ x3, depends on
context .
22.4 Polynomial
Polynomial equations are solved by a polynomial equation solver , applying

various polynomial _methods . Both sides of the equation are checked whether
they are polynomials in the unknown . If the checks are successful, the equation
is converted to a polynomial normal form by polynomial _normal _form , and the
polynomial equation solver 8olve_polynomial - equation is invoked :
solve_equation (Lhs = Rhs ,X ,Solution ) +-

polynomial (Lhs ,X ) ,
polynomial (Rhs ,X ) ,
polynomial -I1ormal . 1orm (Lhs - Rhs ,X ,Poly ) ,
solve_polynomial _equation (Poly ,X ,Solution ) .
The polynomial normal form is a list of tupies of the form (Ai ,Ni ) , where
Ai is the coefficient of XNi , which is necessarily nonzero . The tupies are sorted
into strictly decreasing order of Ni ; for each degree there is at most one tuple .
For example , the list [(lift ) ,( - 3,1) ,( ft,0)] is the normal form for -;;2- 3.x+ ft. The
leading term of the polynomial , is the head of the list . The classical algorithms
for handling polynomials are applicable to equations in normal form . Reduction
to polynomial normal form occurs in two stages:
polynomial -rlormal Jorm (Polyno ~ ial ,X ,NormalForm ) +-

polynomial Jorm (Polynomial ,X ,Poly Form ) ,
remove -zero_terms (Poly Form ,NormalForm ) .
22.4 Polynomial 375
The predicate polynomial_form (X,Polynomial,PolyForm) decomposes the

polynomial . Poly Form is a sorted list of coefficient -degree tupies , where tupies
with zero coefficients may occur .
It is convenient for many of the polynomial methods to assume that all the
terms in the polynomial form have nonzero coefficients . Therefore the final step
of polynomial _normal _form is removing those terms whose coefficients are zero.
This is achieved by a simple recursive procedure remove_zero_terms .
The code for polynomial _form directly echoes the code for is_polynomial . For
each clause used in the parsing process, there is a corresponding clause giving the
resultant polynomial . For example, the polynomial form of a term xrl. is [(l ,n)]
which is expressed in the clause
polynomial Jorm (XtN ,X ,[(l ,N)]).
The recursive clauses for polynomial _form manipulate the polynomials in order
to preserve the polynomial form . Consider the clause
polynomial Jorm (Poly 1+ Poly2,X ,PolyForm) +-

polynomial Jorm (Poly 1,X ,Poly Forml ),
polynomial Jorm (Poly2 ,X ,Poly Form2),
add_polynomials (PolyForm 1,PolyForm2,PolyForm).
The procedure add_polynomials contains an algorithm for adding polynomials in

normal form . The code is a straightforward list of the possibilities that can arise .
add_polynomials ([ ] ,Poly,Poly) .
add_polynomials ( [P IPoly],[ ],(P IPoly]).
add_polynomials ([(Ai ,Ni ) IPolyl ] ,[(Aj ,Nj ) IPoly2] ,[(Ai ,Ni ) IPoly]) ~
Ni > Nj , add_polynomials(Polyl ,[(Aj ,Nj ) IPoly2],Poly).
add_polynomials ( [(Ai ,N) IPoly 1),[(Aj ,N) IPoly2] , [(A ,N) IPoly]) ~
Ni = := Nj , A := Ai + Aj , add_polynomials(Polyl ,Poly2,Poly) .
add_polynomials([(Ai ,Ni) IPolyl ],[(Aj ,Nj) IPoly2],[(Aj ,Nj )IPoly]) ~ '
Ni < Nj , add_polynomials([(Ai ,Ni )IPolyl ],Poly2,Poly).
Similarly , the procedures subtract_polynomials, multiply_polynomials and binomial

are algorithms for subtracting , multiplying and binomially expanding polynomials
in normal form to produce results in normal form . The subsidiary predicate
multiply _single(Polyl ,Monomial,Poly2) multiplies a polynomial by a monomial
(C,N) to produce a new polynomial .
Once the polynomial is in normal form , the polynomial equation solver is
invoked . The structure of the polynomial solver is identical to the structure of
the overall equation solver . The solver is a collection of methods that are tried
in order to see which is applicable and can be used to solve the equation . The
predicate solve _ polynomial _ equation is the analogous relation to solve _ equation .
The second equation in Figure 22 . 1 is quadratic and can be solved with
the standard formula . The equation solver mirrors the human method . The
polynomial is identified as being suitable for the quadratic method by checking
( with quadratic ) if the leading ! erm in the polynomial is of second degree . Since
zero terms have been removed - in putting the polynomial into its normal form ,
pad puts them back if necessary . The next two steps are familiar : calculating the
discriminant , and returning the roots according to the value of the discriminant .
Again multiple solutions are indicated by having multiple possibilities :
solve _ polynomial _ equation ( Poly , X , Solution ) + -
quadratic ( Poly ) ,
pad ( Poly , [ ( A , 2 ) , ( B , l ) , ( 0 , 0 ) ] ) ,
discriminant ( A , B , 0 , Discriminant ) ,
root ( X ,A , B , O , Discriminant , Solution ) .
discriminant ( A , B , C , D ) + - D : = ( B * B - 4 * A * C ) .
root ( X , A , B , C , O ,X = - B / ( 2 * A ) ) .
root ( X ,A , B , C , D ,X = ( - B + sqrt ( D ) ) / ( 2 * A ) ) + - D > O .
root ( X , A , B , C , D ,X = ( - B - sqrt ( D ) ) / ( 2 * A ) ) + - D > O .
Other clauses for solve _ polynomial _ equation constitute separate methods for
solving different polynomial equations . Linear equations are solved with a simple
formula . In PRESS , cubic equations are handled by guessing a root and then
factoring , reducing the equation to a quadratic . Other tricks recognize obvious
factors , or that quartic equations missing a cubic and a linear term are really
disguised quadratics .
22 . 5 Homogenization
The top - level clause for homogenization reflects the transformation of the
original equation into a new equation in a new unknown , which is recursively
solved , and its solution obtained for the original unknown :
solve _ equation ( Equation ,X , Solution ) + -
homogenize ( Equation ,X , Equationl , Xl ) ,
solve _ equation ( Equationl , XI , Solution I ) ,
solve _ equation ( Solutionl ,X , Solution ) .
The code for homogenize / I , implements the four stages of homogenization as

22.5 Homogenization 377
described in Section 22 . 1 . The offenders set is calculated by offenders / 3 which
checks that there are multiple offenders . If there is only a single offender , homogenization
will not be useful :
homogenize ( Equation ,X , Equationl , Xl ) + -
offenders ( Equation ,X , Offenders ) ,
reduced _ term ( X , Offenders , Type , Xl ) ,
rewrite ( Offenders , Type , Xl , Substitutions ) ,
substitute ( Substitutions , Equation , Equationl ) .
The predicate reduced _ term / 1, finds a reduced term , that is a candidate for the
new unknown . In order to structure the search for the reduced term , the equation
is classified into a type . This type is used in the next stage to find rewrite rules
expressing each element of the offenders set as an appropriate function of the
reduced term . The type of the example equation is exponential . PRESS encodes
a lot of heuristic knowledge about finding a suitable reduced term . The heuristics
are dependent on the type of the terms appearing in the offenders set . To aid the
structuring ( and retrieval ) of knowledge , finding a reduced term proceeds in two
stages - classifying the type of the offenders set and finding a reduced term of
that type :
reduced - term ( X , Offenders , Type , Xl ) + -
classify ( Offenders ,X , Type ) ,
candidate ( Type , Offenders ,X , Xl ) .
We look at the set of rules appropriate to our particular equation . The

offenders set is of exponential type because all the elements in the offenders set
have the form AB where A does not contain the unknown , but B does. Standard
recursive procedures check that this is true .
The heuristic used to select the reduced term in this example is that if all
the bases are the same, A , and each exponent is a polynomial in the unknown , X ,
then a suitable reduced term is A x :
candidate ( exponential ,Offenders ,X ,A jX ) +-

base( Offenders ,A ) , polynomial _exponents ( Offenders ,X ) .
The straightforward code for base and polynomial _exponents is in the complete
program . The heuristics in PRESS are better developed than the ones shown
here . For example , the greatest common divisor of all the leading terms of the
polynomials is calculated and used to choose the reduced term .
The next step is checking whether each member of the offenders set can
be rewritten in terms of the reduced term candidate . This involves finding an
appropriate rule . The collection of clauses for homogenize_axiom constitute the

possibly applicable rewrite rules . In other words , relevant rules must be specified
in advance . The applicable rules in this case are
homogenize _axiom (exponential ,A t (N *X ) ,A tX ,(A tX ) tN ) .
homogenize _axiom (exponential ,A t (X + B ) ,A tX ,A tB * A tX ) .
Substituting the term in the equation echoes the parsing process used by
offenders as each part of the equation is checked whether it is the appropriate
term to rewrite .
Exercises for Chapter 22
(i ) Add isolation axioms to Program 22.1 to handle quotients on the left -hand
side of the equation . Solve the equation x/ 2= 5.
(ii ) Add to the polynomial equation solver the ability to solve disguised linear
and disguised quadratic equations . Solve the equations 2:r:3- 8= x3, and x4-
5x2 + 6= 0.
(iii ) The equation cos(f2.x) - sin (x) = D can be solved as a quadratic equation in
sin (x) by applying the rewrite rule cos(f2.x) = 1- f2.sin2 (x) . Add clauses to
Program 22.1 to solve this equation . You will need to add rules foridentifying
terms of type trigonometric , heuristics for finding trigonometric reduced
terms , and appropriate homogenization axioms .
(iv ) Rewrite the predicate free_of( Term ,X) so that it fails as soon as it finds an
occurrence of X in Term .
(v ) Modify Program 22.1 so that it solves simple simultaneous equations .
22 .6 Background
Symbolic manipulation was an early application area for Prolog . Earlyex -

amples are programs for symbolic integration (Bergman and Kanoui , 1973) and
for proving theorems in geometry (Welham , 1976) .
The PRESS program , from which Program 22.1 is adapted , owes a debt
to many people . Many of the researchers in the mathematical reasoning group
working with Alan Bundy at the University of Edinburgh have tinkered with
the code. Published descriptions of the program appear in Bundy and Welham
( 1981) , Sterling et al . (1982) and Silver (1986) . The last reference has a detailed
discussion of homogenization .
22.6 Background 379
PRESS includes various modules , not discussed in the chapter , that are interesting
in their own right : for example , a package for interval arithmetic (Bundy ,
1984) , an infinite precision rational arithmetic package developed by Richard
O ' Keefe , and an expression simplifier based on difference - structures as described
in Section 15.2, developed by Lawrence Byrd . The successful integration of all
these modules is strong evidence for the practicality of Prolog for large programming
projects .
The development of PRESS showed up classic.points of software engineering .
For example , at one stage the program was being tuned prior to publishing some
statistics . Profiling was done on the program , which showed that the predicate
most commonly called was free_of. Rewriting it as suggested in Exercise (iv )
above resulted in a speedup of 35 percent in the performance of PRESS .
Program 22.1 is a consider ably cleaned-up version of PRESS . Tidying the
code enabled further research . Program 22.1 was easily translated to other logic
programming languages , Concurrent Prolog and FCP (Sterling and Codish , 1986) .
Making the conditions when methods were used more explicit , enabled the writing
of a program to learn new equation solving methods from examples (Silver , 1986) .
Chapter 23
A COInpiler
Our final application is a compiler . The program is presented top- down . The
first section outlines the scope of the compiler and gives its definition . The next
three sections describe the three components : the parser , the code generator and
the assembler .
23 . 1 Overview of the compiler
The source language for the compiler is PL , a simplified version of Pascal

designedsolely for the purposes of this chapter. It contains an assignment statement
, an if-then-else statement, a while statement and simple I / O statements.
The language is best illustrated with an example . Figure 23.1 contains a program
for computing factorials written in PL . A formal definition of the syntax of the
language is implicit in the parser in Program 23.1.
The target language is a machine language typical for a one-accumulator
computer. Its instructions are given in Figure 23.2. Each instruction has one (explicit
) operand which can be one of four things : an integer constant, the addressof
a storage location , the address of a program instruction , or a value to be ignored .
Most of the instructions also have a second implicit operand which is either the
accumulator or its contents . In addition there is a pseudoinstruction block that
reserves a number of storage locations as specified by its integer operand .
The scope of the compiler is clear from its behavior on our example . Figure
23.3 is the translation of the PL program in Figure 23.1 into machine language .
The compiler produces the columns labeled instruction and operand.
The task of compiling can be broken down into the five stages given in Figure
23 . 4. The first stage transforms a source text into a list of tokens . The list of
program factorialj
begin
read value ;
count := 1 ;
result := 1 ;
while count < value do
begin
count := count + 1j
result := result * count
end .,
write result
end
Figure 23.1: A PL - program for computing factorials
ARITHMETIC CONTROL
I/ O, etc.
Literals Memory
jumpeq read
addc add jumpne write
subc sub jumplt halt
mulc mill jumpgt
divc div jumple

.
loadc load Jumpge
.
store Jump
Figure 23.2: Target language instructions
tokens is paxsed in the second stage , syntax analysis , to give a source structure .
The third and fourth stages, respectively , transform the source structure into
relocatable code, and assemble this into absolute object code. The final stage
outputs the object program .
Our compiler implements the middle three stages. Both the first stage of
lexical analysis and the final output stage are relatively uninteresting and are
not considered here . The top level of the code handles syntax analysis , code
generation and assembly.
The basic predicate compile ( Tokens, ObJ'ect Code) relates a list of tokens Tokens
to the ObJ'ect Code of the program the tokens represent . The compiler compiles
correctly any legal PL program , but does not handle errors ; that is outside
the scope of this chapter . The list of tokens is assumed to be input from some
rMC
382 A Compiler 23.1
~~
symbol address instruction operand
~tijtij
READ 21
LOADC
STORE
LOADC
STORE
LABELl LOAD
SUB
JUMPGE
LOAD
ADDC
STORE COUNT
LOAD RESULT
MUL COUNT
STORE RESULT
JUMP LABELl
LABEL2 LOAD RESULT
WRITE
HALT
COUNT BLOCK
RESULT
VALUE
Figure 23.3 Assembly code version of a factorial program
Source Lexical Analysis Token Syntax Analysis Source

Text I List I Structure
Code Generation Object Assembly Object Output Object

j Structure - - - + Structure - - + Program
(relocatable) (absolute )
Figure 23.4: The stages of compilation
previous stage of lexical analysis . The parser performing the syntax analysis ,
implemented by the predicate parse, produces from the Tokens an internal parse
tree Structure . The structure is used by the code generator encode to produce
relocatable code Code. A dictionary associating variable locations to memory
address es and keeping track of labels is needed to generate the code. This is the
compile ( Tokens, Object Code) +-

ObJ.ect Code is the result of compilation of
a list of Tokens representing a PL program .
compile (Tokens ,Object Code ) +-

parse (Tokens ,Structure ) ,
encode ( Structure ,Dictionary ,Code ) ,
assemble ( Code ,Dictionary ,Object Code ) .
The parser
parse( Tokens, Structure ) +-

Structure represents the successfully parsed list of Tokens.
parse (Source ,Structure ) +-

pl _program (Structure ,Source\ [ ]) .
pl_programS) -+- [program], identifier(X), ['j'], statement(S).
stateraent((8;8s)) ~
[begin], stateraent(8), rest..stateraents (8s).
stateraent(assign(X,V)) ~
identifier(X), [':= '], expression (V).
stateraent(if(T ,81,82)) ~
[if ], test(T), [then], stateraent(81), [else], statement(82).
stateraent(while(T ,8)) ~
[while], test(T), [do], stateraent(8).
statement(read(X)) ~
[read], identifier(X).
statement (write (X )) - +
[write ], expression (X ) .
rest -8tatements ((SiSs)) - + [' ;'], statement (S) , rest -8tatements (Ss) .
rest -8tatements (void ) - + [end].
expression (X ) - + pl _constant (X ) .
expression (expr (Op ,X ,Y )) - + pl _constant (X ) , arithmetic _op (Op ) , expression (Y ) .
arithmetic _op ('+ ') ~ [' + '].
arithmetic _op ('- ') ~ ['- '] .
arithmetic -op (' * ') ~ [' * '] .
arithmetic _op (' I ') ~ [' I '].
pl _constant (name (X )) - + identifier (X ) .
pl _constant (number (X ) ) - + plinteger (X ) .
Program 23 .1: A compiler from PL to machine language
384 A Compiler 23.1
identifier (X ) - + [X ], { atom(X )} .
pI Jnteger(X ) - + [X ], {integer(X )} .
test(compare(Op,X ,Y )) - + expression(X ), comparison_op(Op), expression(Y ).
-
comparison _op ('= ') - +
~'= ']
' .
comparison _op ('# ') - +

:'# ']
comparison _op (' > ') - +
I:'>'] .
comparison _op (' < ') - +

I'<'] .
comparison _op (' ?: ') - +

I'~'] .
comparison _op (' ~ ') - +

I'~'] .
The code generator

encode(StructureJDictionary ,RelocatableCode) +-
Relocatable Code is generated from the parsed Structure
building a Dictionary associating variables with address es.
encode((XjXs ),D ,(YjYs )) +-
encode(X ,D ,Y ), encode(Xs,D,Y s).
encode(void ,D ,no_op).
encode(assign(Name,E),D ,(Codej instr (store,Address))) +-
lookup (Name,D ,Address), encode_expression(E,D,Code).
encode(if (Test,Then,Else),D,
(TestCodej Then Codej instr (jump ,L2); label(LI ); ElseCode; label(L2))) +-
encode_test (Test,LI ,D ,TestCode),
encode(Then,D ,ThenCode),
encode(Else,D ,ElseCode).
encode(while(Test,Do) ,D ,
(label(LI ); TestCode; DoCode; instr (jump ,LI ); label(L2))) +-
encode_test(Test,L2,D,TestCode), encode(Do,D ,DoCode).
encode(read(X ),D ,instr (read,Address)) +-
lookup (X ,D ,Address) .
encode(write (E),D,(Code; instr (write ,O))) +-
encode_expression(E,DiCode) .
encode-expression(Expression,Dictionary , Code) +-
Code corresponds to an arithmetic Expression .
encode-expression(number(C) ,D ,instr (loadc,C) ) .
encode_expression(name(X ) ,D,instr (load,Address)) +-
lookup (X ,D,Address) .
encode_expression(expr(Op,EI ,E2) ,D ,(Load;instruction )) +-
singleinstruction (Op ,E2,D ,Instruction ),
encode_expression(E I ,D ,Load).
encode
-expression (expr(Op,El ,E2),DiCode) +-
not singleinstruct ion(Op,E2,D,Instruction),
single-operation(Op,E1,D,E2Code,Code) ,
encode _expression (E2,D,E2Code).
singleinstruct ion(Op,number(C) ,D,instr(OpCode,C)) +-
literal_operation(Op,OpCode).
singleinstruct ion(Op,name(X),D,instr(OpCode,A)) +-
memory_operation(Op,OpCode), lookup(X,D,A).
single_operation(Op,E,D,Code,(Code;Instruction)) +-
commutative(Op), singleJ.nstruction(Op,E,D,Instruction).
single_operation(Op,E,DiCode,
(Code;instr(store,Address);Load;instr(OpCode,Address))) +-
not commutative(Op),
lookup('temp',D,Address),
encode -expression
(E,D ,Load) ,
op_code(Op,E,OpCode).
op_code(Op,number(C) ,OpCode) +- literal-operation(Op,OpCode).
op_code(Op,name(X),OpCode) +- memory_operation(Op,OpCode).
literal_operation('+ ',addc). memory_operation('+ ',add).
literal-operation('- ' ,subc). memory_operation('- ' ,sub).
literal_operation('* ',mulc). memory_operation('*',mul).
literal_operation(' f ',divc). memory_operation(' f ',div).
commutative(' + '). commutative(' *').
encode
_test(compare(Op,El ,E2),Label,D,(Code; instr(OpCode,Label) )) +-
comparison _opcode(Op,OpCode),
encode _expression
(expr('- ',El ,E2) ,DiCode).
comparison
-opcode('= ' jumpne). comparisoll-opcode(' ' jumpeq).
comparison
_opcode('> ' jumple). comparison
_opcode('2::' jumplt ).
comparison
_opcode('< ' jumpge). comparison
_opcode('~ ' jumpgt).
lookup(Name,Dictionary,Address) +- SeeProgram15.9
The assembler
assemble
( Code,Dictionary, TidyCode) +-
TidyCodeis the result of assemblingCoderemoving
no_opsand labeL ." and filling in the Dictionary.
386 A Compiler 23.1
assemble ( Code , Dictionary , Tidy Code ) + -
tidy _ and _ count ( Code , liN , Tidy Code \ ( instr ( halt , O ) ; block ( L ) ) ) ,
Nl := N + l ,
allocate ( Dictionary ,N 1 , N2 ) ,
L := N2 - Nl , !.
tidy _ and _ count ( ( Codel ; Code2 ) ,M ,N , TCodeI \ TCode2 ) + -
tidy _ and _ count ( Code I ,M , MI , TCodeI \ Rest ) ,
tidy _ and _ count ( Code2 , MI ,N , Rest \ TCode2 ) .
tidy _ and _ count ( instr (X ,Y ) ,N , NI , ( instr (X ,Y ) ; Code ) \ Code ) + -
Nl := N + I .
tidy _ and _ count ( label ( N ) , NN , Code \ Code ) .
tidy _ and _ count ( no _ op ,N ,N , Code \ Code ) .
allocate ( void , NN ) .
allocate ( dict ( Name , Nl , Before , After ) , NO ,N ) + -
allocate ( Before , NO , Nl ) ,
N2 := Nl + l ,
allocate ( After , N2 ,N ) .
Program 23 . 1 ( Continued )
second argument of encode . Finally , the relocatable code is assembled into object
code by assemble with the aid of the constructed Dictionary .
The testing data and instructions for the program are given as Program
23 .2 . The program factorial is the PL program of Figure 23 . 1 translated into a
list of tokens . The two small programs consist of a single statement each , and
test features of the language not covered by the factorial example . The program
testl tests compilation of a nontrivial arithmetic expression , while test2 checks
the if - then - else statement .
23 . 2 The parser
The parser proper is written as a definite clause grammar , as described in
Chapter 16 . The predicate parse as given in Program 23 .1 is just an interface
to the DCG , whose top - level predicate is pI _ program . The DCG has a single
argument , the structure corresponding to the statements , as will be described . A
variant of Program 16 .2 is assumed to translate the DCG into Prolog clauses . The
convention of that program is that the last argument of the predicates defined by
the DCG is a difference - list :

23.2 The parser 387
test_compiler(X ,Y ) +-
program(X ,P), compile(P,Y ).
program (testl , [program,testl ,';',begin,write ,x ,'+ ',y ,'- ',z,' / ' ,2,end]).
program (test2, [program,test2,';',
begin,if ,a,' > ',b,then,max,':= ' ,a,else,max,':= ',biend]).
program(factorial )
[program,factorial ,';,
,begin
,read ,value ,' ; '
,
count , ' .-
, -
' , 1" ' .'
,
result ,
' ,.-- ' , 1 " ' . '
,while ,count , ' < ' ,value ,do
,begin
, count , ' ..= ' , count " ' + ' 1 " ' .'
,
result ,
' .-
. -
' , result "
' * ' count
,
end ,
' ., '
,write ,result
,end]).
Program 23.2: Testing and data
parse (Source,Structure ) +-
pl _program (Structure ,Source\ [ }) .
The first statement of any PL program must be a program statement . A program

statement consists of the word program followed by the name of the program . We
call words that must appear for rules of the grammar to apply standard identifiers ,
the word program being an example . The name of the program is an identifier in
the language . What constitutes identifiers , and more generally constants , will be
discussed in the context of arithmetic expressions . The program name is followed
by a semicolon , another standard identifier , and then the program proper begins .
The body of a PL program consists of statements , or more precisely a single
statement that may itself consist of several statements . All this is summed up in
the top level grammar rule :
pl _programS ) - + [program ], identifier (X ) , [' j'], statement (S) .
The structure returned as the output of the parsing is the statement constituting
the body of the program . For the purpose of code generation the top level
program statement has no significance , and is ignored in the structure built .
388 A Compiler 23.2
The first statement we describe is a compound statement . Its syntax is the

standard identifier begin followed by the first statementS say, in the compound
statement , and then the remaining statements 8s. The structure returned for a
compound statement is (8;8s) where ; is used as a two -place infix functor . Since
S, Ss or both may be compound statements or contain them , the structure is
returned recursive . The semicolon is chosen as functor to echo its use in PL for
denoting sequencing of statements :
statement ((SiSs) ) ~ [begin ], statement (S) , rest -Btatements (Ss) .
Statements in PL are delimited by semicolons . The rest of the statements

is accordingly defined as a semicolon followed by a nonempty statement , and
recursively the remaining statements :
rest -statements ((SiSs)) - + [' ;'], statement (S) , rest -statements (Ss) .
The end of a sequence of statements is indicated by the standard identifier end.

The atom void is used to mark the end of a statement in the internal structure .
The base case of rest_statements is therefore
rest -statements (void ) - + [end].
The above definition of statements precludes the possibility of empty statements

. Programs and compound statements in PL cannot be empty .
The next statement to discuss is the assignment statement . It has a simple

syntactic definition - a left -hand side , followed by the standard identifier := ,
followed by the right -hand side. The left -hand side is restricted to being a PL
identifier while the right -hand side is any arithmetic expression , whose definition
is to be given :
statement (assign(X ,E )) - + identifier (X ) , [' := '] , expression (E ) .
The structure returned by the successful recognition of an assignment statement

has the form assign(X ,E) . The (Prolog ) variable E represents the structure
of the arithmetic expression , while X is the name of the (PL ) variable to be assigned
the value of the expression . It is implicitly assumed that X will be a PL
identifier .
For simplicity , we restrict ourselves to a subclass of arithmetic expressions .

Two rules define the subclass . An expression is either a constant , or a constant
followed by an arithmetic operator and recursively an arithmetic expression . Examples
of expressions in the subclass are x, 9, 2.t and x+ y- z/ 2, the expression in
the test case testl in Program 23.2:
23.2 The parser 389
expression (X ) ~ pl _constant (X ) .
expression
- (,expr
- (.Op~ ,X ,Y .)). +-
pl _constant (X ) , arithmetic _op (Op ) , expression (Y ) .
This subclass of expressions does not respect the standard precedence of arithmetic
operators . The expression x.2+ y is parsed as x.( 2+ y) . On the other hand ,
the expression x + y- z/ 2 is interpreted unambiguously as x+ ( y- (z/ 2)) . We restrict
ourselves to the subclass to simplify both the code and its explanation in this
chapter .
For this example , we restrict ourselves to two types of constants in PL : iden -
tifiers and integers . The specification of pI_constant duly consists of two rules .
Which of the two is found is reflected in the structure returned . For identifiers X ,
the structure name (X) is returned , while number (X) is returned for the integer
X:
pI _constant (name (X )) -+- identifier (X ) .

pI _constant (number (X )) -+- p I Jnteger (X ) .
For simplicity we assume that PL integers and PL identifiers are Prolog
integers and atoms , respectively . This allows the use of Prolog system predicates
to identify the PL identifiers and integers . Recall that the curly braces notation
of DCGs is used to specify Prolog goals :
identifier ( X ) - + [X ] , { atom (X ) } .
plinteger ( X ) - + [X ] , { integer (X ) } .
In fact all grammar rules that use PL identifiers and constants could be modified
to call the Prolog predicates directly if greater efficiency is needed .
A list of arithmetic operators is necessary to complete the definition of arithmetic
expressions . The form of the statement for addition , represented by " + " , is
given below . The grammar rules for subtraction , multiplication and division are
analogous , and appear in the full parser in Program 23.2:
arithmetic _op ('+ ') - + [' + '].
The next statement to be discussed is the conditional statement , or if -then -

else. The syntax for conditionals is the standard identifier if followed by a test (to
be defined ) . After the test , the standard identifier then is necessary, followed by a
statement constituting the then part , the standard identifier else and a statement
constituting the else part , in that order . The structure built by the parser is
if ( T, 81, 82) where T is the test , 81 is the then part and 82 is the else part :
390 A Compiler 23.2
statement(if (T ,81,82)) -+
[if ], test(T), [then], statement(Sl), [else], statement(S2).
Tests are defined to be an expression followed by a comparison operator and
another expression . The structure returned has the form compare ( Op , X , Y) , where
Op is the comparison operator , and X and Yare the left - hand and right - hand
expressions in the test , respectively :
test ( compare ( Op ,X ,Y ) ) - +-
expression ( X ) , comparison _op ( Op ) , expression (Y ) .
The definition of comparison operators using the predicate comparison _ op is
analogous to the use of arithmetic _ op to define arithmetic operators . Program

23 . 1 contains definitions for = , # , > , < , ~ , and ::; .
While statements consist of a test and the action to take if the test is true .
The structure returned is while ( T , S ) where T is the test and S is the action . The
syntax is defined by the following rule :
statement ( while ( T ,8 ) ) - + [while ] , test ( T ) , [do ] , statement (8 ) .
I / O is handled in PL with a simple read statement and a simple write statement

. The input statement consists of the standard identifier read followed by a
PL identifier , and returns the structure read ( X ) , where X is the identifier . Write
statements are similar :
statement ( read ( X ) ) - + [read ] , identifier (X ) .

statement ( write ( X ) ) - + [write ] , expression (X ) .
Collecting together the various pieces of the DCG described above gives a
parser for the language . Note that ignoring the arguments in the DCG gives a
formal BNF grammar for PL .
Let us consider the behavior of the parser on the test data in Program 23 . 2 .
The parsed structures produced for the two single statement programs have the
form ( structure ) ; void where ( structure ) represents the parsed statement . The write
statement is translated to
write ( expr ( + , name ( x ) , expr ( - , name ( y ) , expr ( j , name ( z ) , numb er ( 2 ) ) ) ) ) ,
while the if _then _else statement is translated to
if ( compare( > , name ( a) , name ( b) ) , assign( max , name ( a) ) , assign( max, name ( b)) ) .
The factorial program is parsed into a sequence of five statements followed by

void . The output after parsing for all three test programs is given in Figure 23.5.
This is the input for the second stage of compilation , code generation .
Program testl :
write ( expr ( + ,name (x ) ,expr (- ,name (y ) ,expr (j ,name (z) ,number (2) )) ) ) ;void
Program test .2:
if (compare (> ,name (a) ,name (b )) ,assign(max ,name (a) ) ,assign (max ,name (b))
) ;void
Program test S:
read (value ) ;assign ( count ,number (l ) ) ;assign(result ,number (l ) ) ;

while ( compare ( < ,name ( count ) ,name (value )) ,
(assign (count ,expr ( + ,name ( count ) ,number ( 1))) ;
assign(result ,expr ( * ,name (result ) ,name ( count ) ) ) ;void ) ) ;
write (name (result )) ;void
Figure 23.5: Output from parsing
23 .3 The code generator
The basic relation of the code generator is encode( Structure , Dictionary , Code) ,
which generates Code from the Structure produced by the parser . This section
echoes the previous one. The generated code is described for each of the structures
produced by the parser representing the various PL statements :
Dictionary relates PL variables to memory locations , and labels to instruction

address es. The dictionary is used by the assembler to resolve locations of labels
and identifiers . Throughout this sectionD refers to this dictionary . An incomplete
ordered binary tree is used to implement it as described in Section 3 of Chapter
15. The predicate lookup (Name ,D , Value) (Program 15.9) is used for accessing the
incomplete binary tree .
The structure corresponding to a compound statement is a sequence of its

constituent structures . This is translated into a sequence of blocks of code, recursively
defined by encode. The functor ",-" is used to denote sequencing . The
empty statement denoted by void is translated into a null operation , denoted
no_op. When the relocatable
" is removed . code is traversed during assembly this "pseudoinstruction
The structure produced by the parser for the general PL assignment statement
has the form assign(Name ,Expression ) where Expression is the expression to
be evaluated and assigned to the PL variable Name . The corresponding compiled
392 A Compiler 23.3
form calculates the expression followed by a store instruction whose argument is
the address corresponding to Name . The representation of individual instructions
in the compiled code is the structure instr ( X , Y ) where X is the instruction and
Y is the operand . The appropriate translation of the assign structure is therefore
( Code ; instr ( store , Address ) ) , where Code is the compiled form of the expression ,
which , after execution , leaves the value of the expression in the accumulator . It
is generated by the predicate encode _ expression ( Expression , D , Expression Code ) .
Encoding the assignment statement is performed by the clause
encode ( assign ( Name , Expression ) , D , ( Code ; instr ( store , Address ) ) ) ~
lookup ( Name , D , Address ) , encode _ expression ( Expression , D , Code ) .
This clause is a good example of Prolog code which is easily understood
declaratively but hides complicated procedural bookkeeping . Logically , relationships
have been specified between Name and Address , and between Expression
and Code . From the programmer ' s point of view it is irrelevant when the final
structure is constructed , and in fact the order of the two goals in the body of
this clause can be swapped without changing the behavior of the overall program .
Furthermore , the lookup goal , in relating Name with Address , could be making
a new entry , or retrieving a previous one , where the final instantiation of the
address happens in the assembly stage . None of this bookkeeping needs explicit
mention by the programmer . It goes on correctly in the background .
There are several cases to be considered for compiling the expression . Constants
are loaded directly ; the appropriate machine instruction is loadc C where
C is the constant . Similarly identifiers are compiled into the instruction load
A where A is the address of the identifier . The two corresponding clauses of
encode _ expression are
encode - expression ( number ( C ) , D , instr ( loadc , C ) ) .
encode _ expression ( name ( X ) , D , instr ( load , Address ) ) + -
lookup ( X , D , Address ) .
The general expression is the structure expr ( Op , El , E2 ) where Op is the operator
, el is a PL constant and Ell is an expression . The form of the compiled
code depends on Ell . If it is a PL constant , then the final code consists
of two statements : an appropriate load instruction determined recursively by encode
_ expression and the single instruction corresponding to Op . Again it does
not matter in which order the two instructions are determined . The clause of
encode _ expression is
encode _ expression ( expr ( Op , El , E2 ) , D , ( Loadj Instruction ) ) + - -
single Jnstruction ( Op , E2 , DiInstruction ) ,
encode _ expression ( EliD , Load ) .

The nature of the single instruction depends on the operator and whether
the PL constant is a number or an identifier . Numbers refer to literal operations
while identifiers refer to memory operations:
single-instruction (Op,number(C),D ,instr (Opcode,C)) +-
literal _operation (Op,Opcode) .
single-instruction (Op,name(X ),D ,instr (Opcode,A )) +-
memory-operation (Op,Opcode), lookup (X ,D ,A ) .
A separate table of facts is needed for each sort of operation .

The respective form
of the facts is illustrated for " + " .
literal _ operation ( + , addc ) . memory _operation ( + ,add ) .
A separate calculation is necessary when the second expression is not a constant
and cannot be encoded in a single instruction . The form of the compiled
code will be determined from the compiled code for calculating E2 , and the single
operation determined by Op and El :
encode _ expression ( expr ( Op , El , E2 ) , DiCode ) + -
not single instruct ion ( Op , E2 , D , Instruction ) ,
single _ operation ( Op , E 1 , D , E2Code , Code ) ,
encode _ expression ( E2 , D , E2Code ) .
In general , the result of calculating E2 must be stored in some temporary
location , called " $ temp " in the code below . The sequence of instructions is then
the code for E2 , a store instruction , a load instruction for El and the appro -
The predicates shown

priate memory operation addressing the stored contents .
previously are used to construct the final form of the code :
single _ operation ( Op , E , D , Code ,
( Code ;
instr ( store , Address ) ;
Load ;
instr ( OpCode , Address ) )
) + -
not commutative ( Op ) ,
lookup ( ' $ temp ' , D , Address ) ,
encode - expression ( E , D , Load ) ,
op _ code ( Op ,E , OpCode ) .
An optimization is possible if the operation is commutative , e . g . , addition or
multiplication , which circumvents the need for a temporary variable . In this case
394 A Compiler 23.3
the memory or literal operation can be performed on el , assuming that the result
of computing E2 is in the accumulator:
single_operation(Op,E,D ,Code,(Code;Instruction)) +-
commutative(Op), single~nstruction(Op,E,DiInstruction).
The next statement is the conditional if -then -else parsed into the structure
if( Test, Then,Else) . To compile the structure , we have to introduce labels where
instructions can jump to . For the conditional we need two labels marking the
beginning and end of the elsepart respectively. The labels have the form label(N) ,
where N is the address of the instruction . The value of N is filled in during the
assembling stage , when the label statement itself is removed . The schematic of
the cod~ is given by the third argument of the following encode clause:
encode(if (Test,Then,EIse),D,
(TestCode;
Then Code ;
instr (jump ,L2);
label(Ll );
E IseCodej
label (L2 ) )
)+-
encode_test (Test,Ll ,D ,TestCode) ,
encode(Then,D,ThenCode),
encode(Else,D,ElseCode) .
In order to compare two arithmetic expressions , we subtract the second from

the first and make the jump operation appropriate to the particular comparison
operator . For example , if the test is whether two expressions are equal , we circumvent
the code if the result of subtracting the two is not equal to zero . Thus
comparison_opcode('= ',jumpne) is a fact. Note that the label which is the second
argument of encode_test is the address of the code following the test .
encode_test (compare(Op,El ,E2) ,Label,D ,(Code; instr (OpCode,Label))) +-

Cornparison_opcode(Op,OpCode) , ,
encode_expression(expr('- ',El ,E2),D ,Code).
The next statement to consider is the while statement . The statement is
parsed into the structure while( Test, Statements). A label is necessarybefore the
test , then the test code is given as for the if -then -else statement , then the body
of code corresponding to Statements and a jump to re-perform the test . A label
is necessary after the jump instruction for when the test fails .
Program testl :
( ( ( ( instr ( load , Z ) ; instr ( divc , 2 ) ) ; instr ( store , Temp ) ; instr ( load ,Y ) ;
instr ( sub , Temp ) ) ; instr ( add ,X ) ) ; instr ( write , O ) ) ; no _ op
Program test2 :
( ( ( instr ( load , A ) ; instr ( sub , B ) ) ; instr ( jumple , Ll ) ) j ( instr ( load ,A ) ;
instr ( store , Max ) ) jinstr ( jump , L2 ) ; label ( Ll ) j ( instr ( load , B ) ; instr ( store , Max ) ) ;
label ( L2 ) ) ; no _ op
Program factorial :
instr ( read , Value ) ; ( instr ( loadc , l ) ; instr ( store , Count ) ) ; ( instr ( loadc ,l ) ;
instr ( store , Result ) ) ; ( label ( Ll ) ; ( ( instr ( load , Count ) ; instr ( sub , Value )) ;
;
( ( instr ( load , Result ) ; instr ( mul , Count ) ) ; instr ( store , Result ) ) ; no _op ) ;
instr ( jump , Ll ) ; label ( L2 ) ) ; ( instr ( load , Result ) ; instr ( write , O ) ) ; no _ op
Figure 23 .6 : The generated code
encode ( w hile ( Test , Do ) ,D ,
( label ( Ll ) j
Test Codej
Do Codej
instr ( jump , Ll ) ;
label ( L2 ) )
) +-
encode - test ( Test , L2 , D , Test Code ) ,
encode ( Do , D , Do Cod e) .
The I / O statements are straightforward . The parsed structure for input ,
read ( . X) , is compiled into a single read instruction where the table is used to get
the correct address :
encode ( read ( X ) , D , instr ( read , Address ) ) +-
lookup ( X , D , Address ) .
The output statement is translated into encoding an expression , and then a write
instruction :
encode ( write ( E ) , D , ( Code ; instr ( write ,O ) ) ) +-
encode _ expression ( E , DiCode ) .

396 A Compiler 23.3
Figure 23 .6 contains the relocatable code after code generation and before
assembly for each of the three examples of Program 23 . 2 . Mnemonic variable
names have been used for easy reading .
23 .4 The assembler
The final stage performed by the compiler is assembling the relocatable code
into absolute object code . The predicate assemble ( Code , Dictionary , Object Code )
takes the Code and Dictionary generated in the previous stage , and produces the
object code . There are two stages in the assembly . During the first stage , the
instructions in the code are counted , at the same time computing the address es
of any labels created during code generation and removing unnecessary null operations
. This tidied code is further augmented by a halt instruction , denoted
by instr ( halt , 0 ) , and a block of L memory locations for the L PL variables and
temporary locations in the code . The space for memory locations is denoted by
block ( L ) . In the second stage address es are created for the PL and temporary
variables used in the program : .
assemble ( Code ,Dictionary , Tidy Code ) +-
tidy _and _count ( Code , liN , Tidy Code \ ( instr ( halt ,O ) ;block (L ) ) ) ,
Nl := N + l ,
allocate ( Dictionary ,Nl ,N2 ) ,

L := N2 - NI .
The predicate tidy _ and _ count ( Code , M , N , Tidy Code ) tidies the Code into Tidy -
Code where the correct address es of labels have been filled in , and the null operations
have been removed . Procedurally , executing tidy _ ana _count constitutes
a second pass over the code . M is the address of the beginning of the code ,
while N is one more than the address of the end of the original code . Thus the
number of actual instructions in Code is N + 1- M . Tidy Code is represented as a
difference - structure based on " ;, ' .
The recursive clause of tidy _ and _ count demonstrates both standard difference -
structure technique , and updating of numeric values :
tidy _and _count ( ( Codel ; Code2 ) ,M ,N , TCodel \ TCode2 ) +-

tidy - alld _count ( Codel ,M ,Ml , TCodel \ Rest ),
tidy _and _count ( Code2 ,M 1 ,N ,Rest \ TCode2 ).
Three types of primitives occur in the code : instructions , labels and no _ops .
23.4 The assembler 397
Program testl :
instr (load,11) jinstr (divc,2) jinstr (store,12)jinstr (load,10) j
instr (sub,12) jinstr (add,9) jinstr (write ,O) jinstr (halt ,O) jblock(4)
Program test2:
instr (load,10) ;instr (subill ) ;instr (jumple ,7) ;instr (load,10) ;
instr (store,12) ;instr (jump ,9) jinstr (load,ll ) jinstr (store,12) j
instr (halt ,O) ;block (3)
Program factorial :
instr ( read , 21 ) ; instr ( loadc , l ) ; instr ( store , 19 ) ; instr ( loadc ,l ) ;
instr ( store , 20 ) ; instr ( load , 19 ) ; instr ( sub , 21 ) ;
instr ( jumpge , 16 ) ; instr ( load , 19 ) ; instr ( addc , l ) ; instr ( store , 19 ) ;
instr ( load , 20 ) ; instr ( mill , 19 ) ; instr ( store , 20 ) ;
instr ( jump , 6 ) ; instr ( load , 20 ) ; instr ( write , O ) ; instr ( halt , O ) ; block ( 3 )
Figure 23 . 7 : The compiled object code
Instructions are handled routinely . The address counter is incremented by one ,
and the instruction is inserted in a difference - structure :
tidy _ and - count ( instr (X ,Y ) ,N , Nl , ( instr ( X ,Y ) ; Code ) \ Code ) + -
Nl := N + l .
Both labels and no -ops are removed without updating the current address or
adding an instruction to the tidied code:
tidy _and _count (label (N ) ,NN ,Code \ Code ) .
tidy _and _count (no _op ,NN ,Code \ Code) .
Declaratively the clauses are identical . Procedurally , the unification of the label
number with the current address causes a major effect in the program . Every
reference to the label address is filled in . This program is another illustration of
the power of the logical variable .
The predicate allocate (Dictionary ,M ,N) has primarily a procedural interpretation
. During the code generation as the dictionary is constructed , storage locations
are associated with each of the PL variables in the program , plus any
temporary variables needed for computing expressions . The effect of allocate is
to assign actual memory locations for the variables , and fill in the references to
them in the program .
398 ACorn piler 23.4
The variables are found by traversing the Dictionary . M is the address of the
memory location for the first variable , while N is one more than the address of
the last . The order of variables is alphabetic corresponding to their order in the
dictionary . The code also completes the dictionary as a data structure .
allocate ( void , NN ) .
allocate ( dict ( Name , N 1 , Before , After ) , NO , N ) + -
allocate ( Before , NO , Nl ) ,
N2 : = Nl + l ,
allo cate ( After , N2 , N ) .
The compiled test programs of Program 23 . 2 appear in Figure 23 . 7 .
Exercises for Chapter 23
( i ) Extend the compiler so that it handles repeat loops . The syntax is repeat
( statement ) until ( test ) . Extensions to both the parser and the compiler need
to be made . Test the program on
program repeat ;
begin
1. , - I ,
, - ,
repeat
begin
write ( i ) ;
i : = i + l
end
until i = 11
end .
( ii ) Extend the definition of arithmetic expressions to allow arbitrary ones . In the
encoder , you will have to cater for the possibility of needing several temporary
variables .
23 . 5 Background
The compiler described is based on a delightful paper by Warren ( 1980 ) .

Appendix
A . Working with Prolog
Prolog implementations vary in the details of how the user interacts with
the Prolog system , and how it develops Prolog programs . Here we give a general
overview of how one might interact with a standard Prolog system .
Prolog systems are usually file -oriented . That is, the source of the program
under development resides in one or more files . The standard cycle of program
development is :
While the program is not complete do
Compose (part of ) the program using a text editor ,
and place it in a file ;
Enter Prolog , and consult the file ;
Run the program , usually under the Prolog debugger .
Consult is the standard Edinburgh Prolog system predicate for loading a set of
procedures residing in some file . In an operating system which can keep suspended
process es, usually the Prolog system and the text editor process es are
both kept simultaneously . If so, only the file that has been changed need to be
consulted . Otherwise , the entire program needs to be consulted afresh every time .
Alternatively , in a Prolog system that can save its state on a file , used under an
operating system which cannot keep process es, it may be advised to checkpoint
portions of a program which have been debugged into a saved Prolog state , and
start Prolog with that saved state .
Some Prolog systems , e.g. Quintus Prolog , allow an even better interaction
between Prolog and the text editor .
Considering debugging , each Prolog system has its own conventions . However
, most modem debuggers are based on Byrd 's box model of debugging (Warren
, 1981) . In this model , one can inspect a goal when it is called , when it
400 Appendix
when it fails, and when it is retried . Such a debugger was shown in

succeeds ,
Chapter 19, and is incorporated in Wisdom Prolog
.
B . System Predicates
This section describes all the evaluable system predicates available in Wisdom
Prolog . These predicates are provided in advance by the system and they
cannot be redefined by the user . Any attempt to add clauses or delete clauses
to an evaluable predicate will fail with an error message, and leave the evaluable
predicate unchanged . Evaluable predicates are available for the following tasks :
Input / Output
Reading -in programs
Opening and closing files
Reading and writing Prolog terms
Getting and putting characters
Arithmetic
Affecting the flow of the execution
Classifying and operating on Prolog terms
(metalogical facilities )
Term Comparison
Debugging facilities
Environment facilities
NAME MEANING
Types:
atom ( Atom )
Atom is an atom .
integer ( I ) I is an integer .
atomic ( A ) A is an atom or an integer .
constant ( X )
Same as atomic .
functor ( St , F , A ) F is the principal functor of St and A is its arity .
arg ( N , S , Sn ) Sn is the Nth argument of S.
var ( V )
V is a variable
nonvar ( C )
C is not a variable .
Program manipulation :
assert ( Clause ) Assert a clause at the end of the program .

assert a ( Clause ) Assert a clause at the beginning of the program .
Appendix 401
Same as assert .
a. ssertz ( Clause )
Retract a clause unified with Clause .
retract ( Clause )
abolish ( F ,A ) Retract ( erase ) all the clauses ,
with functor F and arity A .
consult ( File ) Read - in the program which is in the file File .
When a directive is read it is executed .
When a clause is read it is put alter any
clause already read for that procedure .
reconsult ( File ) Same as consult but old clauses of procedures
defined in File are retracted from the program .
clause ( GiB ) B is a body of a clause whose head unifies with G .
listing List the current program .
listing ( Name ) List the predicates named Name in the program .
I/ O :
read (T ) T is the next term , delimited by a " fullstop "
( a ' . ' followed by < CR > or a space ) ,
on the current input file . .
Fails if the next element on the current output
stream does not unify with T or if passed EOF .
sread ( T , VB ) Read the term T and V s is a list of pairs ;
the variable name and the variable itself .
write (T ) Write T on the current output me .
writeq (T ) Write T , with quotes if needed .
display (T ) Display T on the terminal .
displayq (T ) Display T on the terminal with quotes if needed .
displayl (L ) Display a list of objects .
print (T ) Has a hook for pretty printing ;
write your own " portray ( T ) " .
see ( File ) File is the new current input me .
File is unified with the name of the current

seeing ( File )
input file .
seen Closes the current input stream .
tell ( File ) Let File be the current output stream .
File is unified with the name of the current .

telling ( File )
output me .
told Close the current output stream .
flush Flush the current output file
( the system uses buffer I / O ) .
get ( C ) Get a printable character from the current
Input me .
402 Appendix
getO(C) Get a character from the current input file .
put(C) Put the character C on the current output file .
tab(N) Prints N blanks on the current output file .
nl Print a newline character on the current
output file .
skip(C) Skip characters till C , on the current input
stream .
ttyget (C) Get C from the terminal .
ttyput (C) Echo an ascii character to the terminal .
ttynl Echo a newline character to the terminal .
ttyskip (C) Skip till C from the terminal .
ttytab (N) Print N blanks on the terminal .
op(P,Type,Op) Define operator Op with the priority P and
type Type .
Op can also be a list of names .
save(File) Save the current state on file File .
log List the data base on file ' log ' .
Debugging :
trace Prompt for a goal to trace .
trace(G) Trace the goal G .
General :
true Always succeeds .
fail Always fails .
! Cut
exit End Prolog session .
abort Abort the execution .
call(G) Call G .
not (G) If G succeeds not ( G ) fails .
name(AiL ) L is the list of the characters in A .
repeat Succeed any number of times .
, conjunction .
, disjunction .
- .. umv .
x = y X unifies with Y .
\= Negation of = .
Tl = = T2 Tl and T2 are identical .
Tl \ = = T2 Negation of = = .
system(Comm) Executes Comm in the operating system .

Appendix 403
systemp(F ,A ) F is the functor and A is the arity of a

system predicate .
save_term (T ) push to stack.
unsave_term (T ) pop out of the stack.
member(X ,Xs) X is a member of Xs.
append(Xs,Y siZs) Zs are the Y s appended to Xs.
Special:
iterate (G) Do G until it fails (efficiently).
fork _exec(me,Comm) a -like command.
ancestor(G ,N) The goal G is the Nth ancestor of the current
goal (used by the debugger).
cutg(G) ancestor cut .
retry (G) Retry goal G.
Arithmetics :
- Arithmetic system calls :
Tl < T2 The value of the arithmetic expression Tl is less

than the arithmetic expression T2 .
Tl = \ = T2 Not equal.
Tl > T2 Greater than .
Tl ~ T2 Greater than or equal .
Tl ~ T2 Less than or equal .
Tl = := T2 Not equal .
R := ExpRis the result of the arithmetic expression Exp .
R is Exp Same as := .
- Arithmetic operations :
X + Y Addition .
X - Y Substruction .
X * Y Multiplication .
X / Y Division . -
X modY X modulo Y .
- X Unary minus .
+X Unary plus .
Consulting and reconsulting :

reconsulting is called by
[met , file2, . . ., . . .j .
or - reconsult(filel ) , reconsult(me2), . . .
404 Appendix
whereas consulting is performed by
[ + file , + file2 , . . . , . . .] .
or - consult ( filel ) , consult ( file2 ) , . . .
Note that this can be done only at the top level .
To assert procedures from the terminal you should use the user file :
[ user ] or [ + user ]
and then type its clauses .
Hooks :
The user can define his own shell by defining the shellj O predicate .
The system shell ( $ shell ) by default is defined as :
$ shell :- shell , abort .
$ shell :-
ttynl , display ( ' 1 ? - ' ) , sread ( Goalb , Vs ) ,
s _ expand - goal ( Goalb , Goal ) ,
user - call ( Goal , V s ) , abort .
expand _ goal :
Is called by the shell converting the top level goal .
Using this predicate the user can define his own conversions
to the top level goal .
expand _ clause :
Same as expand - goal but for the consulted clauses .
Shell:
s-expand -goal System expand goal .
user _call Execute the call of the user .
display . xesult (Vs ) Display the value of the variables .
get . xeply Get the user reply from the terminal .
cons Jist For consulting a number of files using lists .
Appendix 405
C . Predefined Operators
For I / O of compound terms it is more convenient to use operators , unary or

binary . The unary ones may be prefix , which means they precede the argument ;
postfix which means they follow the argument ; or infix - those that come in
between two arguments .
To prevent ambiguity , each operator gets a precedence and an association ,
to distinguish between two operators with the same precedence . The type of
association and number of arguments are described by the following conventions :
For prefix :
fx means that the precedence of the argument must be lower
than the precedence of the operator .
fy means that the precedence of the argument may be equal
to the precedence of the operator .
For postfix:
xf and yf - analogously the same conventions of the prefix .
For infix :
xIx xfy yfx - mean that both sub expressions which are the arguments of the
operator must be of lower precedence than the operator itself ;
only the left -hand argument should be of lower precedence ;
only the right -hand argument should be of lower precedence ; respectively .
To definean operatortype:
I 7- op(Precedence
, Type, Op).
WherePrecedence is from 1 to 1200, Typeis oneof the mentioned
above
, Opis
the operator
's nameor a list of names.
Remember that the precedence of the arguments must be lower then 1000
which is the precedence of the ' ,' Thusyoushould
write
assert( (A :- B) )
and not
assert(AB )
406 Appendix
Operator definition :
:- (op(12.00,fx ,[ :- , ?- ])).
:- op(1200, xrx,[ (:- ) , < - , -+- ]).
:- op(llOO,xfy,';').
:- op(lOOO,xfy,',') .
:- op(900,fx ,[not]).
:- op(700,xfx ,[ = , \ = , is, := , = .. , - - , \ = = , = := , = \ = , < , > , ~ , ~ ]) .
:- op(500,yfx ,[+ ,- ,\ ]).
:- op(500,fx ,[(+ ),(- )]).
:- op(400,yfx ,[* ,j ,j I ]).
:- op(300,xfx ,[mod]).
References
Apt , K .R . and van Emden , M .H ., Contributions to the Theory of Logic Programming

, J . ACM 29 , pp . 841- 862, 1982.
Ben -David , A . and Sterling , L ., A Prototype Expert System for Credit Evaluation ,
Proc . International Workshop on Artificial Intelligence in Economics and
Management , Zurich , Switzerland , 1985.
Berge , C ., The Theory of Graphs and its Applications , Methuen & Co ., London ,
1962 .
Bergman , M . and Kanoui , H ., Application of Mechanical Theorem Proving to

Symbolic Calculus , Proc . Third International Symposium on Advanced Computing
Methods in Theoretical Physics , CNRS , Marseille , 1973.
Bloch , C ., Source-to - Source Transformations Of Logic Programs , Tech . Report

CS-84-22, Department of Applied Mathematics , Weizmann Institute Of Science
, Rehovot , Israel , 1984.
Bowen , K . and Kowalski , R ., Amalgamating Language and MetaLanguage , in
(Clark and Tarnlund , 1982), pp. 153- 172.
Boyer , R .S. and Moore , J .S., A Computational Logic , Academic Press , ACM
Monograph Series, 1979.
Bowen , D .L ., Byrd , L ., Pereira , L .M ., Pereira , F .C .N . and WarrenD .HiD ., Prolog
on the DE C System - 10 user 's manual , University of Edinburgh , 1981.
Breuer , G . and Carter , H .W ., VLSI Routing in Hardware and Software Concepts
in VLSI, G. Rabbat (ed.), Van Nostrand Reinhold, 1983.
Bruynooghe, M ., The Memory Management of Prolog Implementation , in (Tarn-
jund , 1980).
Bruynooghe, M . and Pereira, L .M ., Deductive Revision by Intelligent Backtracking
, in (Campbell, 1984).
408 References
Bundy , A ., A Computer Model a / Mathematical Reasoning , Academic Press, 1983.

Bundy , A ., A Generalized Interval Package and its Use for Semantic Checking ,
ACM Transactions on Mathematical Software 10 , pp . 392- 407, 1984.
Bundy , A . and Welham , R ., Using Meta -level Inference for Selective Application
of Multiple Rewrite Rules in Algebraic Manipulation , Artificial Intelligence
16 , pp . 189 - 212 , 1981 .
Burstall , R .M . and Darling ton , J ., A Transformation System for Developing Recursive

Programs , J . AGM 24 , pp . 46- 67, 1977.
Byrd , L ., Understanding the Control Flow of Prolog programs, in (Tarnlund ,

1980).
Campbell, J .A . (ed.), Implementations Of Prolog, Ellis Horwood Publication , Distributed
By John-Wiley & Sons, New York , 1984.
van Caneghem, M . (ed.) , Prolog-II user's Manual, 1982.
van Caneghem, M . and WarrenD .HiD . (eds.), Logic Programming and its Applications
, Ablex Publishing Co., 1986.
Chikayama , T ., Unique Features of ESP , Proc . International Conference on Fifth
Generation Computer Systems, pp . 292- 298, Tokyo , JapaJl , 1984.
Clark , K .L ., Negation as Failure, in (Gallaire and Minker , 1978).

Clark , K .L . and GregoryS ., A Relational Language for Parallel Programming ,
Proc . ACM Conference on Functional Languages and Computer Architecture ,
1981 .
Clark , K .L . and GregoryS ., PARLOG : Parallel Programming in Logic , Research

Report 84/ 4, Department of Computing , Imperial College of Science and
Technology , England , 1984.
Clark , K .L . and McCabe , F .G ., The Control Facilities of IC -Prolog in Expert

Systemsin the Microelectronic Age, D. Michie (ed.), pp. 153- 167, University
of Edinburgh , Scotland , 1979.
Clark , K .L . and McCabe , F .G ., PROLOG : A Language for Implementing Expert
Systems, in Machine Intelligence 10, Hayes, Michie and Pao (eds.), pp. 455-
470 , Ellis Horwood , 1982 .
Clark , K .L . and Tarnlund , SA ., A First Order Theory of Data and Programs ,

Information Processing 77 , pp . 939- 944, North Holland , 1977.
Clark , K .L . and Tarnlund , SA . (eds.), Logic Programming, Academic Press,

London , 1982 .
References 409
Clark , K .L , McCabe , F .G . and GregoryS

., IC -Prolog Language Features , in
(Clark and Tarnlund , 1982).
Clocksin , W .F . and Mellish , C .S., Programming in Prolog , 2nd Edition , Springer -
Verlag , New York , 1984.
Coelho ~H .~Cotta , J .C . and Pereira , L .M .~How to Solve it in Prolog , 2nd Edition ,

Lab oratorio Nacional de Engenharia Civil , Lisbon , Portugal , 1980.
Cohen , J ., Describing Prolog by Its Interpretation and Compilation , J. ACM 28 ,

pp . 1311 - 1324 , 1985 .
Colmerauer , A ., Les system es-Q ou un Formalisme pour Analyser et Synthesizer

des Phrases sur Ordinateur , Publication Interne No . 43, Dept .
d ' Informatique , Universite de Montreal , Canada , 1973.
Colmerauer , A ., Kanoui , H ., Pasero , R . and Roussel , P., Un Systeme de Communication

Homme -machine en Francais , Research Report , Groupe Intelligence
Artificielle , Universite Aix - Marseille II , France , 1973 .
Colmerauer , A ., Prolog -II , Manuel de reference et modele theorique , Groupe

d 'lntelligence Artificielle Universite d ' Aix -Marseille II , 1982.
Colmerauer, A ., Prolog And Infinite Trees, in (Clark and Tarnlund , 1982).

Deo , N ., Graph Theory with Applications to Engineering and Computer Science,
Prentice - Hall , 1974 .
Dincbas ,M . and Le Pape ,J .P., Metacontrol of Logic Programs in METALOG ,

International Conference on Fifth Generation Computer Systems, November
1984 .
Dudeney , H .E ., Amusements in Mathematics , Thomas Nelson and Sons, London ,

1917 .
Dwork , C ., Kanellakis , P.C . and Mitchell , J .C ., On the Sequential Nature of

Unification , J. Logic Programming 1, pp . 35- 50, 1984.
Eggert , P.R . and Chow , K .P., Logic Programming Graphics with Infinite Terms ,
Tech . Report University of California , Santa Barbara 83-02, 1983.
Elcock , E .W ., The Pragmatics of Prolog : Some Comments , Proc . Logic programming

Workshop '89, pp . 94- 106, Algarve , Portugal , 1983.
van Emden , M ., Warren 's Doctrine on the Slash, Logic Programming Newsletter ,
December , 1982 .
van Emden , M . and Kowalski , R ., The Semantics Of Predicate Logic as a Programming

Language , J . ACM 23 , pp . 733- 742, 1976.
410 References
Even , S., Graph Algorithms , Computer Science Press, 1979.
Gallaire , H . and Lasserre , C ., A Control Metalanguage for Logic Programming )

in (Clark and Tamlund , 1982).
Gallaire , H . and Minker , J ., Logic And Databases, Plenum Publishing Co ., New
York , 1978 .
Gallaire , H ., Minker , J . and Nicolas , JiM ., Logic and Databases : A Deductive

Approach , Computing Surveys 16 , pp . 153- 185, 1984.
Hammond,P., Micro-Prolog for Expert Systems, Chapter 11 in Micro -Prolog: Programming
in Logic, Clark and McCabe (eds.), Prentice Hall 1984.
Hill , R ., LUSH -Resolution and its Completeness , DCL Memo 78, Department of
Artificial Intelligence , University of Edinburgh , 1974.
Hopcroft , J .E . and Ullman , J .D ., Introduction To Automata Theory , Languages,

Computation , Addison -Wesley, Reading , Massachussets , 1979.
Jaffar , J ., Lassez, J .L . and Lloyd , J .W ., Completeness of the Negation as Failure

Rule , Proc . of the International Joint Conference on Artificial Intelligence ,
pp . 500- 506, Karlsruhe , Germany , 1983.
Kahn , K .M ., A Primitive for the Control of Logic Programs , Proc . International
IEEE Symposium on Logic programming , Atlantic City , 1984.
Knuth , D ., The Art Of Computer Programming , Volume 1, Fundamental Algorithms

, Addison - Wesley, Reading , Massachussets , 1968.
Knuth , Do, The Art Of Computer Programming , Volume 3, Sorting and Searching ,
Addison - Wesley, Reading , Massachussets , 1973.
Kowalski , R ., Predicate Logic as a Programming Language , Proc . IFIP Congress,

North - Holland , Stockholm 1974 .
Kowalski , R ., Logic For Problem Solving , North -Holland , 1979.
Kowalski , R ., Algorithm = Logic + Control , Communications of the ACM 22 ,

pp . 424 - 436 , 1979 .
Li , D ., A Prolog Database System , Research Studies Press, Ltd ., England , 1984.

Lloyd , J .W ., Foundations Of Logic Programming , Springer Verlag , 1984.
Martelli , A . and Montanari , U., An Efficient Unification Algorithm , A CM Transactions
on Programming Languagesand Systems4(1) , 1982.
Matsumoto , Y ., Tanaka , H . and Kiyono , M ., BUP : A Bottom -Up Parsing System
for Natural Languages, in (van Caneghem and Warren, 1986).
References 411
Mellish , C .S., Some Global Optimizations for a Prolog Compiler , J . Logic Programming
2 , pp . 43- 66, 1985.
Minsky , M ., Semantic Information Processing , MIT Press, Cambridge , Massachusetts

, 1968.
Naish, L ., Negation and Control in Prolog, Tech. Report 85/ 12, University of
Melbourne , Australia , 1985 .
Naish , L ., All Solutions Predicate in PROLOG , Proc . of IEEE Symposium on

Logic Pragramming , Boston , 1985.
Naish , L ., Automating Control For Logic Programs , J . Logic Programming 2 , pp .

167 - 184 , 1985 .
Nakashima , H ., Tomura S. and Ueda , K ., What is a Variable in Prolog ? Proc .

of the International Conference on Fifth Generation Computer Systems, pp .
327- 332, lOOT , Tokyo , 1984.
Nilsson , N .J ., Problem Solving Methods In Artificial Intelligence , Mcgraw -Hill

Publications , New York , 1971
Nilsson , N .J ., Principles Of Artificial Intelligence , Tioga Publishing Co ., Palo

Alto , California , 1981 .
O ' Keefe , R .A ., Programming MetaLogical Operations in Prolog , DAI Working

Paper No . 142, University of Edinburgh , 1983.
O ' Keefe , R .A ., On the Treatment of Cuts in Prolog Source- Level Tools , Proc . 1985
Symposium on Logic Programming , IEEE Computer Society Press, Boston ,
1985 .
Paterson , M .S. and Wegman , M .N ., Linear Unification , J. Computer and Systems

Sciences 16 , pp . 158 - 167 , 1978 .
Pereira , L .M ., Logic Control with Logic , Proc . First International Logic Programming
Conference , pp . 9- 18, Marseille , 1982.
Pereira , F .C .N . and WarrenD .HiD ., Definite Clause Grammars for Language

Analysis - A Survey of the Formalism and a Comparison with Augmented
Transition Networks , Artificial Intelligence 13 , pp . 231- 278, 1980.
Peter , R ., Recursive Functions , Academic Press , New York , 1967 .
Plaisted , D .A ., The Occur -Check Problem in Prolog , New Generation Computing

2 , pp . 309 - 322 , 1984 .
Powers , D ., Playing Mastermind More Logically , SIGART Newsletter 89 , pp .

28 - 32 , 1984 .
412 References
Quintus Prolog Reference Manual , Quintus Computer Systems Ltd ., 1985.

Reiter , R ., On Closed World Databases , in Logic and Databases, Gallaire , H .
and Minker , J. (eds.), Plenum Press, 1978, pp. 55- 76. Also in Readings in
Artificial Intelligence, Webber and Nilsson (eds.), Published by Tioga, 1981.
Robinson , J .A ., A Machine -Oriented Logic Based On the Resolution Principle , J .
ACM 12 , pp . 23- 41, January 1965.
Robinson, J.A . and Sibert, E.E., LOGLISP : Motivation , Design and Implementation
, in (Clark and Tarnlund , 1982).
Schank , R .C . and Riesbeck , C ., Inside Computer Understanding : Five Programs
Plus Miniatures , Lawrence Erlbaum , Hillsdale , N .J . , 1981 .
Schank , R .C . and Abelson ,RiP ., Scripts , Plans , Goals, and Understanding ,

Lawrence Erlbaum , Hillsdale , N .J . , 1977 .
Sedgewick , R ., Algorithms , Addison -Wesley, 1983.

Shapiro , E ., Algorithmic Program Debugging , MIT Press , Cambridge , Massachus-
sets , 1983 .
Shapiro , E ., A Subset of Concurrent Prolog and its Interpreter , Tech . Report

TR -OO3, ICOT -Institute for New Generation Computer Technology , Tokyo ,
Japan , January 1983.
Shapiro , E ., Logic Programs with Uncertainties : A Tool for Implementing Rule -
Based Systems , Proc . 8th International Joint Conference on Artificial Intelligence
, pp . 529- 532, Karlsruhe , Germany , 1983.
Shapiro , E ., Playing Mastermind Logically , SIGART Newsletter 85 , pp . 28- 29,
1983 .
Shapiro , E ., Alternation and the Computational Complexity of Logic Programs ,

J . Logic Programming 1, pp . 19- 33, 1984.
Shapiro, E., SystemsProgramming in Concurrent Prolog, in (van Caneghemand

Warren, 1986).
Shapiro , E . and Takeuchi , A ., Object Oriented Programming in Concurrent Prolog
, New Generation Computing 1, 1983.
Shortliffe , E .H ., Computer Based Medical Consultation , MYCIN , North -Holland ,
New York , 1976 .
Silver , B ., Meta -level Inference , Elsevier Science, Amsterdam , Netherlands , 1986.

Silverman , W ., Hirsch , M ., Houri , A . and Shapiro , E ., The Logix System User
Manual , Weizmann Institute of Science , Rehovot , Israel , 1986 .
au rJ Iva - ; ' - S ' ; . - ' ap " - . ~ - ' aim
8SL61
"
"
-
'
"
"
' '
sa
.
'
~
414 References
Intelligence 10, pp. 441- 454, Hayes, Michie and Pao (eds.), Ellis Horwood,
1982.
WarrenD .HiD ., Perpetual Processes - An Unexploited Prolog Technique, Proc.

Prolog programming environments workshop, Sweden, 1982.
WarrenD .HiD ., Optimizing Tail Recursion in Prolog, in (van Caneghem and
Warren, 1986).
WarrenD .HiD ., Pereira, F. and Pereira L .M ., User 's Guide to DE Csystem - l0
Prolog , Occasional Paper 15, Department of Artificial Intelligence , University
of Edinburgh , 1979.
Weizenbaum , J ., ELIZA - A Computer Program For The Study Of Natural Language

Communication Between Man And Machine , CA CM 9 , pp . 36- 45,
1966 .
Weizenbaum
-- ., J ., Computer Power and Human Reason, W .R . Freeman & Co .,
1976 .
Welham, R ., Geometry Problem Solving , Research Report 14, Department of

Artificial Intelligence , University of Edinburgh , UK , 1976.
Winograd , T ., Language as a Cognitive , Process, Volume I , Syntax , Addison -
Wesley, Reading , Massachusetts , 1983.
Winston , P.R ., Artificial Intelligence , Addison -Wesley, Reading , Massachusetts ,

1977 .
List of PrograInS
Program 1.1: A Biblical family database 3

Program 1.2: Biblical family relationships 13
Program 2.1: Defining family relationships
21
Program 2.2: A circuit for a logical and _gate 23
Program 2.3: The circuit database with names 26
Program 2.4: Course rules 27
Program 2.5: The ancestor relationship 30
Program 2.6: A directed graph
30
Program 2.7: The transitive closure of the edge relationship 30
Program 3.1: Defining the natural numbers
34
Program 3.2: The less than or equal relation 36
Program 3.3: Addition 36
Program 3.4: Multiplication as repeated addition
39
Program 3.5: Exponentiation as repeated multiplication
39
Program 3.6: Computing factorials
39
Program 3.7: The minimum of two numbers 39
Program 3.8a: A non - recursive definition of modulus 40
Program 3.8b : A recursive definition of modulus 40
Program 3.9: Ackermann ' s function 41
Program 3.10: The Euclidean algorithm 42
CoCo
Program 3.11: Defining a list .

Program 3.12: Membership of a list
Program 3.13: Prefix es and suffix es of a list
Program 3.14: Determining sublists of lists
Program 3.15: Appending two lists
Program 3.16: Reversing a list
Program 3.17: Determining the length of a list
Program 3.18: Deleting all occurrences of an element from a list
Program 3.19: Selecting an element from a list
Program 3.20: Permutation sort
416 List of Programs
O0
Program 3.21: Insertion sort
Program 3.22: Quicksort
Program 3.23: Defining binary trees
Program 3.24: Testing tree membership
Program 3.25: Determining when trees are isomorphic
Program 3.26: Substituting for a term in a tree
Program 3.27: Travers als of a binary tree
Program 3.28: Recognizing polynomials
Program 3.29: Derivative rules
Program 3.30: Towers of Hanoi
Program 3.31: Satisfiability of Boolean formulae
Program 5.1: A simple program using not 89
Program 7.1: Yet another family example 104
Program 7.2: Merging ordered lists 111
Program 7.3: checking for list membership 111
Program 7.4: Selecting the first occurrence of an element from a list 113
Program 7.5: Non -membership of a list 114
Program 7.6: Testing for a subset 114
Program 7.7: Testing for a subset 115
Program 7.8: Translating word for word 116
Program 7.9: Removing duplicates from a list 117
Program 7.10: Reversing with no duplicates 118
Program 8.1: Computing the greatest common divisor of two integers 124
Program 8.2: Computing the factorial of a number 125
Program 8.3: An iterative factorial 127
Program 8.4: Another iterative factorial 127
Program 8.5: Generating a range of integers 128
Program 8.6a: Summing a list of integers 129
Program 8.6b : Iterative version of summing a list of integers using an
accumulator 129
Program 8.7a: Computing inner products of vectors 130
Program 8.7b : Computing inner products of vectors iteratively 130
Program 8.8: Computing the area of polygons 130
Program 8.9: Finding the maximum of a list of integers 131
Program 8.10: Checking the length of a list 131
Program 8.11: Finding the length of a list 131
Program 8.12: Generating a list of integers in a given range 131
Program 9.la : Flattening a list with double recursion 136
Program 9.lb : Flattening a list using a stack 136
Program 9.2: Finding subterms of a term 139

Program 9.3: A program for substituting in a term 140
Program 9.4: Subterm defined using = .. 142
Program 9.5a: Constructing the list corresponding to a term 143
Program 9.5b : Constructing the term corresponding to a list 143
Program 10.1: Multiple uses for plus 147
Program 10.2: A multipurpose length program 148
Program 10 .3: A more efficient version of grandparent 148
Program 10.4: Testing if a term is ground 149
Program 10.5: Unification algorithm 150
Program 10.6: Unification with the occurs check 152
Program 10.7: Occurs in 154
Program 10.8: Logical disjunction 156
Program 11.1: Merging ordered lists 158
Program 11.2: Merging with cuts 160
Program 11.3: Minimum with cuts 160
Program 11.4: Recognizing polynomials 161
Program 11.5: Interchange sort 162
Program 11.6: Negation as failure 165
Program 11.7: Implementing # 167
Program 11.8a: Deleting elements from a list 170
Program 11.8b: Deleting elements from a list 170
Program 11.9: If then else statement 170
Program 11.10a: Determining welfare payments 172
Program 11.lOb : Determining welfare payments 172
Program 12.1: Writing a list of terms 176
Program 12.2: Reading in a list of words 177
Program 12.3: Towers of Hanoi using a memo -function 181
Program 12.4: Basic interactive loop 182
Program 12.5: A line editor 184
Program 12.6: An interactive shell 186
Program 12.7: Logging a session 187
Program 12.8: Basic interactive repeat loop . 189
Program 12.9: Consulting a file 189
Program 13.1: Verifying a goal 195
Program 13.2: Numbering the variables in a term 195
Program 13.3: Variant 196
Program 13.4: Writing out a term with non -numeric variable names 197
Program 13.5: Using global flags 197
Program 13.6: Generating new symbols 198

Program 14 . 1 : Finding parts of speech in a sentence 208
Program 14 . 2 : Naive generate - and - test for the N queens problem 210
Program 14 . 3 : Placing one queen at a time 211
Program 14 . 4 : Map coloring 212
Program 14 . 5 : Test data for map coloring 213
Program 14 . 6 : A puzzle solver 214
Program 14 . 7 : A description of a puzzle 216
Program 14 . 8 : Connectivity in a finite DAG 220
Program 14 . 9 : Finding a path by depth - first search 220
Program 14 . 10 : Connectivity in a graph 220
Program 14 . 11 : A depth - first planner 222
Program 14 . 12 : Testing the depth - first planner 222
Program 14 . 13 : An interpreter for a nondeterministic finite automaton 225
Program 14 . 14 : An NDFA that accepts the language ( ab ) * 225
Program 14 . 15 : A push - down automaton interpreter 226
Program 14 . 16 : NPDA for palindromes over a finite alphabet 226
Program 14 . 17 : A program accepting palindromes 227
Program 14 . 18 : A program solving geometricanalogies 230
Program 14 . 19 : Analogy test data 230
Program 14 . 20 : ELIZA 232
Program 14 . 21 : McSAM 234
Program 14 . 22 : Test data for McSAM 235
Program 15 . 1 : Concatenating difference - lists 241
Program 15 . 2 : Flattening a list of lists using difference - lists 241
Program 15 . 3 : Reverse with difference - lists 244
Program 15 . 4 : Quicksort using difference - lists 244
Program 15 . 5 : A solution to the Dutch flag problem 246
Program 15 . 6 : Dutch flag with difference - lists 246
Program 15 . 7 : Normalizing plus expressions 248
Program 15 . 8 : Dictionary lookup from a list of tupies 250
Program 15 . 9 : Dictionary lookup in a binary tree 250
Program 15 . 10 : Melting a term 251
Program 15 . 11 : A queue process 253
Program 15 . 12 : Flattening a list using a queue 254
Program 16.1: A Prolog program for parsing the language defined in
Figure 16 . 1 258
Program 16.2: Translating grammar rules to Prolog clauses 259
Program 16.3: A DCG computing a parse tree 261
Program 16.4: A DCG with subject / object agreement 262
Program 16.5: A DCG for recognizing numbers 263

Program 17.1: Set predicates 269
Program 17.2: Applying set predicates 270
Program 17.3: Implementing a set predicate using difference -lists , assert
and retract 270
Program 17.4: Testing connectivity breadth -first in DAG 273
Program 17.5: Testing connectivity breadth first in a graph 273
Program 17.6: Lee routing 276
Program 17.7: Producing a KWIC index 279
Program 17.8: Second order predicates in Prolog 281
Program 18.1: A depth -first state -transition framework for problem solving 285
Program 18.2: Solving the Wolf , -Goat , and Cabbage problem 286
Program 18.3: Solving the Water Jugs problem 288
Program 18.4: Hill -climbing problem solving framework 291
Program 18.5: Test data . 292
Program 18.6: Best -first problem -solving framework 294
Program 18.7: Concise best -first problem solving framework 295
Program 18.8: Framework for playing games 297
Program 18.9: Choosing the best move . 297
Program 18.10: Choosing the best move with the minimax algorithm 300
Program 18.11: Choosing a move using minimax with alpha -beta pruning 301
Program 19.1: A meta -interpreter for pure Prolog 304
Program 19.2: Building a proof tree 306
Program 19.3: A meta -interpreter for full Prolog 308
Program 19.4: A tracer for pure Prolog 310
Program 19.5: A tracer for Prolog 310
Program 19.6: Oven placement expert system 312
Program 19.7: An interactive shell 312
Program 1~.8: An interactive shell with "why " explanations
315
Program 19.9: Explaining a proof 316
Program 19.10: A meta -interpreter for reasoning with uncertainty 318
Program 19.11: Reasoning with uncertainty with threshold cutoff 318
Program 19.12: A meta -interpreter detecting a stack overflow 321
Program 19.13: A nonterminating insertion sort 322
Program 19.14: Incorrect and incomplete insertion sort 323
Program 19.15: Bottom -up diagnosis of a false solution 324
Program 19.16: Top -down diagnosis of a false solution 326
Program 19.17: Diagnosing missing solution 327
Program 20.1: Playing Mastermind 337
Program 20 .2 : A program for playing a winning game of Nim 341

Program 20.3: A complete program for playing Kalah 349
Program 21.1: A credit evaluation system 356
Program 21 .2 : Test data for the credit evaluation system 357
Program 22.1: A program for solving equations 371
Program 23.1: A compiler from PL to machine language 386
Program 23.2: Testing and data 387
List of Figures
Figure 1.1: An abstract interpreter for logic programs 12

Figure 1 .2 : Tracing the interpreter 14
Figure 1 .3 : A simple proof tree 14
Figure 2 .1 : Defining inequality 20
Figure 2 .2 : A logical circuit 22
Figure 2 .3 : An or-gate 24
Figure 2 . 4: A simple graph 30
Figure 3 .1 : Proof trees establishing completeness of programs 35
Figure 3 .2 : Equivalent forms of lists 44
Figure 3 .3 : Proof tree verifying a list 44
Figure 3 .4 : A proof tree for appending two lists 47
Figure 3 .5 : Proof trees for reversing a list 50
Figure 3 .6 : Comparing trees for isomorphism 59
Figure 4 .1: A unification algorithm 71
Figure 4 .2 : An abstract interpreter for logic programs 73
Figure 4 .3 : Tracing the appending of two lists 75
Figure 4 .4 : Different traces of the same solution 75
Figure 4 .5 : Solving the Towers of Hanoi 77
Figure 4 .6 : A nonterminating computation 78
Figure 5 .1 : A nonterminating computation 83
Figure 5 .2 : Two search trees 87
Figure 5 .3 : Search tree with multiple success nodes 87
Figure 5 .4 : Search tree with an infinite branch 88
Figure 6 .1 : Tracing a simple Prolog computation 96
Figure 6 .2 : Multiple solutions for splitting a list 97
Figure 6 .3 : Tracing a quicksort computation 98
Figure 7.1: A nonterminating computation 106
Figure 7.2: Variant search trees 112
422 List of Figures
Figure 7.3: Tracing a reverse computation 118

Figure 8.1: Computing factorials iteratively 126
Figure 9.1: System type predicates 135
Figure 9.2: Tracing the substitute predicate 141
Figure 11.1: The effect of cut 159
Figure 14.1: A solution to the 4 queens problem 209
Figure 14.2: A map requiring 4 colors 213
Fig \Ire 14.3: Directed graphs 219
Figure 14. 4: Initial and final states of a blocks world problem 223
Figure 14.5: A simple automaton 225
Figure 14.6: A geometric analogy problem 229
Figure 14.7: Sample conversation with ELIZA 231
Figure 14.8: A story filled in by McSAM 236
Figure 14.9: Three analogy problems 237
Figure 15.1: Concatenating difference -lists 240
Figure 15.2: Tracing a computation using difference -lists 243
Figure 15.3: Un normal ized and normalized sums 248
Figure 16.1: A simple context -free grammar 257
Figure 17.1: Sample data 267
Figure 17.2: Power of Prolog for various searching tasks 272
Figure 17.3: The problem of Lee routine for VLSI circuits 274
Figure 17. 4: Input and output for keyword in context problem 277
Figure 17.5: Second-order predicates 281
Figure 18.1: The water jugs problem 287
Figure 18.2: A simple game tree 299
Figure 19.1: Tracing the metainterpreter 305
Figure 19.2: Fragment of a table of system predicates 307
Figure 19.3: A session with the interactive shell 314
Figure 19.4: Generating an explanation 314
Figure 19.5: Explaining one rule at a time 317
Figure 20.1: A starting position for Nim 338
Figure 20.2: Computing rum -sums 339
Figure 20.3: Board positions for Kalab 344
Figure 22.1: Test equations 362
Figure 22.2: Position of subterms in terms 372
Figure 23.1: A PL -program for computing factorials 381
- (~
List of Figures
Figure 23.2: Target language instructions

Figure 23.3: Assembly code version of a factorial program
Figure 23.4: The stages of compilation
Figure 23.5: Output from parsing
Figure 23.6: The generated code
Figure 23.7: The compiled object code
Index
abstract interpreter , 12- 14, 72- 78, area , 130

95 arg , 138 , 143
accumulator , 118 - 119 , 125 - 127 , 137 , argument , 4 , 16
211 , 221 , 242 - 244 , 267 , 277 arithmetic
bottom - up construction of lists , logic programs for , 33- 42

118 Prolog programs for , 121- 132
definition , 126 - 127 arithmetic expression , 122- 123, 388-
generalization to difference -list , 389
242 - 244 arity , 4, 16, 21
problems with being basis of set- askable , 313
predicate , 267 assembler , 396 - 398
Ackermann '8 function , 41 assert , 179 - 181 , 267
addition , 36 - 37 , 122 assignment
alpha -beta pruning , 300- 302 destructive , 99 , 141
alphabetic variant , 68- 69, 196 in conventional languages , 141
alternating Thring machine , 90 statement in PL , 386 , 388
ANALOGY , 228 , 236 atom , 2
ancestor cut , 307 - 308 atom , 134 - 135
ancestor rule , in why explanation , automata , 224 - 227
314 automatic transformation , 254
anonymous variable , 199 backtracking , 97, 99, 158- 160, 178,
APES , 330 190 , 206 - 207 , 236 , 304 - 305
append, 47- 48, 70, 74, 81, 84- 85, 96, deep, 97, 193
104 , 106 , 109 , 164 , 240 , 244 , intelligent , 236
257 , 278 loss of info . in pure Prolog , 266
apply parser , 258
comnland in editor , 183 - 184 shallow , 97
second-order predicate , 280- 282 bag_of, 268- 269
426 Index
benchmark , 203 common instance , 6 , 68

best - first search , 292 - 294 commutative operation , 393
between , 128 commutative l' elation , 106
binary tree , 57- 61, 250 comparison of Prolog with con-
binding , 71- 72 ventionallanguages , 99- 101
blocks -world problem , 221- 224 comparison operator , 123
Boolean formula , 65 - 66 compilation
bottom - up construction of solutions , of arithmetic expression , 388- 390,
118 - 119 , 202 , 243 , 248 392 - 394
breadth - first search , 221 , 271 - 273 , of assignment statement , 391- 394
290 , 292 , 295 of if 0 statement, 390, 395
call , 155 of if - then - else statement , 390 , 394
car , 43 of while statement , 390 , 394 - 395
Cartesian product , in relational stages , 381 - 382
algebra , 31 compiler , 380- 398
cdr , 43 overview , 380 - 386
certainty factor (seealso inexact code , 383 - 386
reasoning), 319 complete list , 84, 106, 109, 113
certainty threshold , 319 complete natural number , 83
chain rule , for derivatives , 65 complete structure , 106
character I / O, 176- 177 complete type , 83
character string , inserting in write , completeness
176 of program , 15 , 17 , 34 , 35
circuit , logic program , 22- 24 recursive data structure , 83
circular definition , 106 complexity , 84- 85
clause , 9 , 14 , 17 , 75 - 76 , 95 , 179 depth , 85
definition , 9 , 17 goal-size, 85
empty , 76 length , 85
Horn , 9 time , 85
indexing , 163- 164 compound statement , 388, 391
iterative , 9 , 17 compound term , 4, 16, 25, 84, 137-
nondeterministic choice , 14 , 95 144
order (seerule order) size of , 84

reduction , 75 - 76 , 95 computation
unit , 9 , 17 deterministic , 76 , 88
clause , 179 , 304 goal , 72, 77, 95
closcd world assumption , 88 loss of information on backtracking
code generation (for PL ), 391- 396 , 266

collateral for loan evaluation , 352 - 353 nondeterministic , 88
coloring planar maps , 212- 213 nonterminating , 72 , 87 , 105 - 107 ,
comment , 22 , 200 124 , 264 , 268 , 320
Index 427
of logic program , 12, 17, 72 rule order in negation as failure ,

of Prolog program , 95- 98 165
output , 72 search tree pruning , 157

parallel , 78 simulation in metainterpreter , 307
redundant , 111 cut - fail combination , 165 - 167
computation models , 224- 227 implementing metalogical predicate
conceptual dependency , 233, 238 , 167
concurrent logic language , 78, 190 in negation as failure , 165- 167
Concurrent Prolog , 78, 94, 150, 156, safe use , 167
379 DAGS (seedirected acyclic graphs)
conjunctive goal , 72, 179 data abstraction , 25 - 28 , 214
conjunctive query , 7- 8 data manipulation , in Prolog , 99
consing , 43, 241 data structure , 83 , 100 , 115 - 119 , 141 ,
constant , 16 , 84 , 134 194 , 233
size of , 84 creation in Prolog , 99
context , finding keywords in , 277- 279 cyclic , 252
context - free grammar , 256 - 259 in Prolog , 115- 119
translation to Prolog program , . incomplete , 119, 233, 239- 255
258 - 259 recursive , 81 , 247
context -dependent information , 261 database , logical , 19
control flow , 99 , 106 relational , 30 , 32
conventional language , comparison simple , 19- 24
with prolog , 99- 101 effect of goal order on database
coroutining , 237 programming , 106
correctness , of program , 15 , 17 , 34 - DCG , 256 - 265 , 386
35 , 125 relationship with context -free
credit evaluation system , 351 - 360 grammar , 256 , 260
cut , 157 - 174 , 267 , 307 , 364 generative feature , 264
definition , 158 debugging , enhanced meta -interpreter
effect of , 157 - 158 , 168 - 172 for , 320- 328
effect on storage space , 160 declarative reading , 9, 51- 52, 242, 304
green (see green cut) declarative semantics , 80
in conjunction with fail , 167 deep backtracking , 97, 193
in expressing mutually exclusive default rule , 171 - 173
test , 157 definite clause grammar (seeDCG)
in if - then - else statement , 170 - 171 delete , 52 - 53 , 169 - 170
incompleteness in implementing denotational semantics , 82
negation as failure , 166 depth -bounded metainterpreter , 322
loss of flexibility , 161, 168- 171, depth -complexity , 85
173 depth -first
restriction on rule order , 165 search , 87 , 95 , 104 - 105 , 221 , 284 ,
428 Index
290 empty clause , 76

traversal of graph , 220 empty list , 43 , 114 , 240
derivative , 62 - 64 empty queue , 252
destructive assignment , 99, 141 empty tree , 57
deterministic computation , 76, 86, 88 equation , 69
dictionary , 249- 252, 255, 391, 396 equation solving (also seePRESS),
difference - list , 239 - 245 , 248 , 254 , 257 , 361 - 378
259 , 272 complete code , 365- 371

compatibility of , 241 definition , 361
concatenation , 240 - 241 equivalence transformation , 361,
head , 239 373
tail , 239 factorization , 362 , 364

difference - structure , 247 - 248 , 379 , homogenization , 363, 376- 378
396 isolation , 362 , 364 , 372 - 374
difference - sum , 247 overview , 361 - 363
differentiation , 62 - 64 , 142 polynomial , 61- 62, 160- 161, 374-
directed acyclic graph , 221, 272 376
directed graph , 29- 30, 221 quadratic (seeunder polynomial )

disjunction (also seeif-then-else), 11, simplification , 374
156 testing condition , 362
disjunction , in Boolean formula , 65- error , runtime , 122 , 124
66 error condition , 99 - 100 , 122 , 135
disjunctive goal , 156 error handling , 99- 100, 122
disjunctive relationship , 31 Euclidean algorithm , 123
divide - and - conquer , 55 evaluable predicate (seesystem predicate
divide - and - query , 326 )
division , 122 evaluation , of arithmetic expression ,
domain 122 - 123
intended , 320 evaluation function , 290 , 292 , 297 - 299

of computations of logic program , exception handling (seeerror handling
82 - 83 , 106 )
termination , 83 execution model of Prolog , 94- 98
don 't - care nondeterminism , 218 existential quantification , 9
don 't - know non determinism , 218 - 219 existential query , 5 - 6 , 14 - 15 , 268
double recursion , 57 , 59 , 135 , 244 expert systems
Dutch flag problem , 245- 246 for credit evaluation , 351 - 360
echo , 183 enhaIlced metainterpreters for ,
editor , 183 - 185 311 - 319
Edinburgh Prolog , 95, 121- 122, 148, explanation , for expert system ,
191 , 199 , 307 313 - 318
ELIZA , 231 - 232 , 238 exponential equation , 377

Index 429
exponentiation , 38, 39 generate - and - test , 55 , 206 - 217

expression , 61 , 122- 123 in game playing , 335
extra -logical predicate , 175- 190 optimization , 207- 209
for i / o, 175- 178 generator , 207 , 209
for program access & manipulation gensym , 198
, 179- 180 get , 177
types of , 175 GHC , 78 , 94
fact , 2 - 3 , 17 , 179 global flags , 198
definition , 2 global variable , 198
universal , 6- 7 goal
factorial , 38 - 39 , 124 - 126 conjunctive , 72, 179
factorization , 362 , 364 computation of , 72, 95
failure node , 86 , 309 definition , 3
failure -driven loops , 188- 189, 209, derived , 13
350 disjunctive (seedisjunctive goal)
false solution , 320 , 322 - 326 dynamic construction of , 280
FOP , 379 ground , 16- 18, 73
financial rating for loan evaluation , invocation , 72 , 99
352 - 353 parent , 72
find _all _dl, 271 reduction , 13 , 72 , 75 - 76
finding path to a node , 221, 272 selection , 14
finite failure , 88 - 89 sibling , 72
first -order logic , comparison with size , 85
second - order logic , 280 goal order , 76, 107- 109, 148, 193, 304,
fixpoint of a logic program , 81 309
flag , 198 & left recursion , 108

flattening a list , 135 - 137 , 241 - 242 , & nonterminating computation ,
253 107 - 109
for _all , 270 comparison with clause order , 107

freezing terms , 153- 155, 179 effect on termination , 107
freeze, 153- 155, 179, 196 effect on trace , 76
function grammar
algebraic , 362 context free (seecontext-free

relationship to relation , 35 grammar)
functor , 4 , 137 - 138 , 142 definite clause (seeDCG)
definition , 4 grammar rule , 256 , 258
predicate , 137- 138, 143 granularity , of a metainterpreter ,
game playing framework , 296 305 - 306
game tree , 299 graph , 29- 30, 219- 221, 272

garbage collection , 164, 189, 193, 350 connectivity , 29 - 30 , 221
generalization , 5 cyclic , 272
430 Index
directed , 29 - 30 , 219 - 221 instance ,

directed acyclic , 219- 221, 272 common (seecommon instance)
greatest common divisor , 41 - 42 , definition , 5 , 68 , 17
123 - 124 ground , 11, 15
green cut , 157 - 162 , 173 , 364 instantiation , 7 , 153
effect on declarative meaning , 162 instruction , 380 - 381 , 397
ground intelligent backtracking , 236
definition , 4 interactive
goal , 16- 17, 73 loop , 182
instance , 11 , 15 program , 182 - 187
object (seeunder freeze) prompting , 313- 314
reduction , 13 interchange sort , 161- 162
term , 17 intermediate structure , 135 - 136 , 242
query , 6 interpretation of a logic program , 81
has _property , 280 interpreter
Herbrand baBe , 81 abstract (see abstract interpreter )
Herbrand universe , 80 - 81 as metaprogram , 304
hill -climbing , 290- 292 intersection , in relational algebra , 32
homogenization , 363, 376- 378 isolation , 362 , 364 , 372 - 374
Horn clause , 9 isomorphism , of binary tree , 58- 59,
how explanation , 316- 317 219
la -Prolog , 94, 119, 236 iteration , 125 - 132
identifier in PL , 387 iterative clause , 9 , 17 , 126
identity , 3, 151 iterative procedure , 126
if - then - else statement , 170 - 171 iterative program , 125
incomplete data structure , 119, 233, join , in relational algebra , 32
239 - 255 Kalab , 343 - 350
incomplete list , 84, 106, 109, 113, 116, key-value pairs , 249
239 , 249 knowledge base, simple (seeexpert
incomplete structure , 119, 242 system)
incomplete type , 83 KWIC , 277 - 279 , 283
indexing , 193- 194 label , in assembled code , 396 - 397
infinite graph , 221, 272 lambda calculus , 94
infinite search tree , 76 , 88 , 104 , 269 lambda expression , 282- 283
inner product , 128- 129 last call optimization (seetail recursion
inorqer traversal of binary tree , 59 optimization )
input / output , character level, 176- Lee algorithm , 273- 277, 283
177 left recursive rule , 106
input / output , reading in a list of lemma , 181
words , 177 length complexity , 85
insertion sort , 55 , 322 length of list , 50, 131, 148
Index 431
lexical analysis , 382 meaning , 15- 16, 34

LIPS , 193 , 203 declarative , 81
Lisp , 43, 94 definition . 15
list , 43 - 51 , 97 , 100 , 106 , 109 , 111 - 115 , intended , 15 , 17 , 52 , 82 - 83 , 320 ,
131 322 - 323 , 328
complete , 83, 106, 109, 113 of logic program , 15- 17

definition , 43 melt , melting frozen term , 154, 180,
251 - 252
empty , 43 , 114 , 240
flattening , 135 - 137 , 241 - 243 , 253 melt _new , 155
head , 43 member , 44 - 45 , 47 , 111 - 113 , 171 ,

207 - 208
incomplete , 7, 13, 84, 106, 109,
113 , 239 , 249 memo - function , 181 - 182
length , 50, 131, 148 in game playing , 337

merging , 111, 157- 159 in search improvement , 290
recursive argument , 52 merge sort , 55
splitting , 47, 97 merging sorted lists , 111, 157- 159

tail , 43 metainterpreter , 185 , 303 - 330
type definition , 43 for debugging , 320- 328
list processing program , composition depth -bounded , 322
of , 111 - 119 definition , 303
logging facility , 186- 188 enhanced , 308 , 311 , 319 , 320 - 323
logic program , defintion , 10, 17 for expert systems , 311 - 319

interpretation , 81 granularity , 305- 306
logic puzzles , 214- 216 proof tree , 306, 308, 314, 323, 325-
328
logical connectives (seeunder metavariable
) run - time overhead , 330
logical consequence, 3, 5, 10 visibility of system predicate , 308

logical deduction , 10, 17 metaknowledge , 317
logical database , 19 metaprogramming , 155, 303, 320
logical disjunction , 156 metavariable , 155 - 156 , 215 , 304
logical implication , 4, 9 metalogical predicate , 146- 150, 167,

282
logical variable , 4, 71- 72, 100, 127,
193 , 242 , 260 , 397 metalogical test (also seeunder test) ,
LOG LISP , 119 124 , 147 - 152
lookup, 249- 251, 391 minimal model , 81
mapping , of list , 115, 280 minimal recursive program , 34 , 106 ,

113
map _list , 280
marker , in set-predicate , 271 minimax algorithm , 298- 300
mastermind , 334 - 337 , 350 minimum , 39 , 110 , 160
maximum , 131 missing solution , 327- 328
McSAM , 233 - 235 , 238 mod , 40 , 122
432 Index
monotonic mapping , 82 simulation , 224 - 227

most general unifier (mgu), 69, 74 nondeterministic finite automaton ,
MU -Prolog , 94, 119 224 - 225
multiple solutions , 37 nonvar , 147
using accumulator , 267 normalize , 247
using set-predicate , 268- 270 not , 165
multiple success node , 87 number , 33 - 42 , 124
multiplication , 38, 122 parsing , 262- 264
MYCIN , 329 , 351 recursive structure , 124
N queens problem , 209- 211 numbervars , 195 - 196
name - clash , 73 object code, 381
name , 176 occurrence , 144 , 364 , 372
natural number , 33 - 42 , 81 occurs check , 69 - 70 , 79 , 85 , 149 , 252
negation , in logic program , 88- 90, occurs _in , 151 - 154
165 - 167 , 195 offenders set , 363 , 377
negation as failure , 88 - 90 , 165 - 167 , operational semantics , 80
270 , 282 operator
cut - fail combination , 167 binary , 121- 123
definition , 88 - 90 comparison , 123
distinction between not and cut , postfix , 122
166 prefix , 122
Nim , 338 - 343 palindrome , 226- 227
no doubles , 117 parallel computation , 78
non -ground terms , 151, 268 parallelism , 78
nonterminal symbols in gram ~ ar , parameter passing , 126
256 - 257 parent goal , 73, 308
non _member , 114 parent rule , in why explanation , 313
nonterminating computation , 72, 87, PARLOG , 78 , 94
105 - 107 , 124 , 264 , 268 , 320 - 322 parse tree , 260
nondeterminism , 14 , 75 - 76 , 88 , 206 - parser (for PL ) , 386, 390
236 , 256 parsing , with DCG , 256 - 265
combining with negation as failure , partial evaluation , 330
270 partition , 56, 109
combining with second-order , 272 path , 221
definition , 206 pattern matching , 231- 232, 235
don 't - care , 218 permutation , 54- 55, 113, 209
don ' t - know , 218 - 219 permutation sort , 55, 209
in game playing , 335 perpetual process , 255
nondeterministic choice , 14 , 95 PL , 380
nondeterministic computation , 88 plus , 37, 124
nondeterministic computation model polynomial , 61- 62 , 374- 376
Index 433
coefficient representation , 375 programmIng

conversion to normal form , 374 - 375 with side - effects , 180 , 190 , 198
using cut , 160- 161 bottom - up , 202
postorder traversal , 59- 60, 323 interactive , 182 - 188
pragmatics , 192- 203 style and layout , 198- 200
predicate tricks , 195 - 198
definition , 3 projection , in relational algebra , 31
evaluable (seesystem predicate) Prolog
extra-logical (seeunder extra-logical comparison with conventional languages
predicate) , 99 - 101
names computation , 95- 97
structure inspection , 137- 144, 281 execution mechanism , 95
system (seeunder system predicate higher order extension , 266- 283
) program efficiency , 192- 194
prefix , 45 pure , 94 , 200 , 266 , 272
preorder traversal , 59- 60 Prolog II , 94
PRESS , 361 , 363 , 376 - 379 proof tree , 14, 47, 50, 85, 88, 306, 308,
problem solving 314 , 323 , 325 - 328
effect of domain specific knowledge , prototyping , 202
289 - 290 pushdown automata , 226- 227
depth -first framework , 284- 285 put , 176
best - first framework , 292 puzzle solver , 216
hill -climbing framework , 290 query , 3 - 8 , 17
searching state space (also see conjunctive , 7- 8
searching state space, 284- 294 definition , 3
procedural reading of clauses, 9, 52, existential , 5 - 6 , 14 - 15 , 268
304 finding all instances (seeset expression
procedure )
definition , 11 second - order , 266 - 270
invocation, 99 simple , 3, 8
program solution to , 74 - 75
access and manipulation , 179- 180 queue , 252 - 255
completeness , 15, 17, 34- 35, 83 empty , 252
complexity dequeue, 252, 254
correctness , 15 , 17 , 34 - 35 , 82 - 84 , enqueue , 252 , 254
125 negative elements , 254
definition , 3 quicksort , 55- 56, 97- 98, 108, 244
development , 200- 202 Quintus Prolog , 190
functional , 37 range , 131
relational , 37 read , 175 - 177
termination , 81 , 105 - -107 reap , 270
434 Index
record structure (also seestructure ), rplacd , 241

100 rule , 8 - 12 , 27 - 30 , 105 , 171 - 173
recursion , 127 - 132 , 163 - 164 body , 8, 17
tail , 127 - 132 , 160 , 163 - 164 , 174 default , 171 - 173
depth , 193 definition , 8 , 17
recursive clause , 116 head , 8 , 17
recursive computation , 125 recursive , 28 - 30
recursive data structure , 81 , 83 , 116 , rule order , 103 - 105 , 114 , 165
247 effect on solution , 103 - 104
completeness , 83 restriction imposed by cut (seeunder
recursive procedure , conversion to set - cut)
predicate , 269 runtime error , 122 , 124
recursive process , 190 S- expression , 241
recursive program , 29 , 51 - 57 , 77 , 128 , samevar , 167 - 168
269 scheduling policy , 74, 78, 95
double , 57 , 59 , 135 , 244 scope of cut , in meta -interpreter
transformation to iterative program simulation , 307
, 125 - 132 scope of variable , 7
heuristics for goal order , 109 script , 233- 235
recursive rule , 28 - 31 , 105 - 106 , 114 - search
115 , 264 best - first , 292 - 294
definition , 28 breadth - first , 221 , 271 - 272 , 290 ,
left , 106 292 , 295
red cut , 168 - 171 , 173 , 267 depth -first , 87, 95, 104- 105, 221,
reduced term , 363 , 377 284 , 290 ,
reduction , 12 - 13 , 72 - 73 , 75 - 76 , 87 sequential , 206, 304
redundant computation , 111 order , 104
redundant solution , 109 - 111 , 159 search tree , 76 , 86 - 88 , 104 - 105
relation
pruning using cut (seeunder cut)
definition , 3 , 19 searching state space
relationship to function , 35 evaluation function , 290 , 292
relation scheme , 19 use of memo - function , 290
relational algebra , 31- 32 using heuristic guidance , 299
relational database , 30 - 32 searching game tree , 296- 301
Relational Language , 101 second-order logic
relocatable code , 381 extension of first order , 280
repeat loop (seefailure-driven loop) manipulating predicate names ,
resolvent , 12 , 72 , 74 280 - 281
retract , 179 - 180 , 267 second - order predicate . 280 - 282
reversing a list , 49 - 50 , 109 second-order programming , 266- 283,
rotation of list , 278 307
Index 435
combining with nondeterministic merge , 55
programming , 273 permutation , 55, 209

select , 53 , 113 quick , 55- 56, 97- 98, 108, 244
select-first , 113 specification formalism , 201
selection , in relational algebra , 31 stack , 69 - 70 , 137 , 226 - 227
semantics , 80 - 82 overflow , 321 - 322
declarative , 80 scheduling policy (also seescheduling
denotational , 81 policy ), 95
operational , 80 standard identifier , 387
sequential search, 206, 304 state space
set difference , in relational algebra , 31 search (seeunder searching state

set expression , 266- 270 space)
application , 271- 279 graph , 284, 296
set-flag , 196- 197 statement , compound , 388
set- of, 268- 269 empty , 388
set predicatE:;, 266- 271, 283- 284 step -wise refinement , 53
in place of recursive procedure , 269 stimulus/ responsepair , 231
nesting , 268 stream , 252
implementation , 271 string manipulation , 176

structure
primitive , 268
termination , 268 incomplete (seeincomplete structure
shared variable , 7- 8 , 32 , 100 , 166 , 213 )
in conjunctive query , 7- 8, 32 incremental buildup , 248
in negation as failure , 166 recursive , 59 , 124 , 247
instantiation , 7- 8 structure inspection : 137- 144, 281
shell , 185 - 187 structured data , 25 - 28
ground/ non-ground goal, 185 subject/ object number agreementin

for expert system , 313 - 316 , 330 grammar , 260 - 262
sibling goal , 72 sublist , 45 - 46 , 194
side - effects , 180 , 190 , 198 , 241 subset , 114
simple database , 19- 24 substitution , 5 , 17 , 60 , 68 , 140 - 142 ,

153
simple query , 3, 8
simplification , of expression (seeunder subterm , 138 - 139 , 142 , 150 - 152
equation solving) successor function , 34
size_of, 269 success branch , 309
SLD tree (see search tree) success node , 86

SLD resolution , 90 suffix , 45
snips , 173 sumlist , 128 - 129
sort symbolic expression , manipulation ,
insertion , 55 , 322 61 - 66 , 361 , 378
interchange , 161- 162 system predicate , 121- 123, 307
436 Index
arithmetic , 121 - 123 game , 299

definition , 123 isomorphism of , 58- 59
in meta -interpreter , 307 parse , 260 , 382
tail recursion optimization , 127- 132, search , 76 , 86 - 88 , 104 - 105
160 , 163 - 164 , 174 , 189 ) 194 , 350 traversal , 59 - 60 , 323
tail recursive loop ) 189) 350 tree _member , 58
target language , 380 Thring machine , 90, 228
temporary location , 393 alternating , 90
temporary variables , 393 type , 33
term , 4 , 25 , 68 ) 137 - 138 , 152 , 180 complete , 83
accessing, 137 condition , 38
building given list , 141 definition , 33
compound , 4, 16, 25) 84, 137- 144 incomplete , 83
copying ) 155) 180 metalogical predicate , 147
definition , 5 , 68 predicate , 134- 137, 147
finding subterm ) 138- 139 recursive , 33
general , 68 unary relation , type of a term , 134 -
identity , 3, 151 136
reading ) 175 uncertainty reasoning , 318- 319
size , 84 unfolding , 227, 236, 242, 244- 245
substitution , 140 unification , 68 - 73 , 76 , 79 , 84 , 100 ,
writing ) 175 116 , 149 - 150 , 193 - 194 , 208 , 245
term _unify , 150 algorithm , 69- 71, 84, 149- 150
tester , 207 , 209 , 211 including occurs check, 149- 150
time complexity , 84, 193 unifier , 69 , 74
token , 381 - 382 uninstantiated variable , 122
top - down construction of structures , union , in relational algebra , 31
116 - 117 , 202 , 242 - 245 , 248 , 260 unit clause , 9
Towers of Hanoi ) 64 - 65 ) 77 , 96 , 181 - univ predicate , 142- 143
182 universal modus ponens , 10 , 80
trace , 12 , 13 , 73 , 75 , 87 - 88 , 95 - 97 ) universal quantification , 6- 7, 9
242 , 308 - 311 , 328 universally quantified fact , 6
as metaprogram , 308 - 311 var , 146 - 147
of meta -interpreter , 305 variable
of Prolog computation , 95- 97 anonymous , 199
transformation , of recursion to iteration as object , 153- 155
) 125 - 132 binding , 71- 72
transitive closure of relation , 29 - 30 definition , 4
tree difference in Prolog , 4
binary , 57- 61 global , 198
empty , 57 identity testing , 151
Index 437
logical , 4 , 71 - 72 , 100 , 127 , 242 , 260 ,

uninstantiated (seeuninstantiated
397 variable)
name _ clash , 73
verification , 201
predicate names , 280
verify , 195- 196
renaming , 69 , 72
weak cut , 173
representation , 19
why explanation , 313- 314
scope ( see scope of variable )
Wisdom Prolog , 122, 307
shared , 7 - 8 , 32 , 100 , 213 write , 175
size, 84 zebra puzzle , 217- 218, 236
type , 100 zero - sum game , 299
type checking , 100
Order Form for Programming Examples to accompany
The Art of Prolog :
Advanced Programming Techniques
by Leon Sterling and Ehud Shapiro
Tear out or photocopy this page and send to
The MIT Press
College Department
55 Hayward Street
Cambridge , MA 02142
617 / 253 - 2884
Note : The diskette contains all programs shown in the book . They are written
for standard Edinburgh Prolog . You may have to adapt them to other varieties
of Prolog .
Please send the following :

Quantity Version Code Unit price Total
Signature
Ship to : Name
Address
City /State/Zip
Special Instruction
Order form for
WISDOM Prolo2
developed by Shmuel Sarra
at the Weizmann Institute of Science
A new Prolog interpreter with these special features:

. user definable shell and environment (UNIXTM-like)
. 100 system predicates
. 320K RAM used by user-data (PC only ) ; up to 80Mb on UNIXTMNMS
machines
. screen management
. exit to your O .S. w /o leaving the interpreter - so you can use your favorite
text -editor , invoke a system command (e.g., list the directory ) , or even
mount a new shell -interpreter atop the Prolog interpreter
For more information contact Motti Goldberg at : max @wisdom (CSNET or
BITNET )
The MIT Press

CollegeDepartment
55 Hayward Street
Cambridge, MA 02142
617/253-2884
Pleasesendthe following:
Quantity Version Code Unit price Total

The Art of Prolog

Uploaded by

Copyright:

Available Formats

The Art of Prolog

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Art of Prolog

Uploaded by

Copyright:

Available Formats

The Art of Prolog

MIT Press Series in Logic Programming

The Art of Prolog : Advanced Programming Techniques , by Leon

Logic Programming : Proceedings- of- the Fourth International Con -

Advanced Programming Techniques

with a foreword by David HiD . Warren

The MIT Press

This book was set in TEX by Sarah Fliegelm ann

Prints taken from Leonardo Da Vinci by Ludwig GoldscheiderJPhaidonPress, 1959

Library of Congress Cataloging -in -Publication Data

(MIT Press series in logic programming )

Part I . Logic Programs 1

Chapter 1 : Basic Constructs 2

1 . 3 The logical variable , substitutions and instances 4

1 . 6 Conjunctive queries and shared variables 7

1 . 8 A simple abstract interpreter 12

1 . 9 The meaning of a logic program 15

Chapter 2 : Database Programming 19

Chapter 3: Recursive Programming 33

Chapter 4: The Computation Model of Logic Programs

Chapter 5: Theory of Logic Programs

Part II . The Prolog Language 93

Chapter 6: Pure Prolog

Chapter 7: Programming in Pure Prolog

8.1 System predicates for arithmetic

Chapter 9: Structure Inspection

9.1 Type predicates 134

Chapter 10 : MetaLogical Predicates 146

Chapter 11: Cuts and Negation 157

Chapter 12: Extra -Logical Predicates 175

Chapter 13: Pragmatics 192

Part III . Advanced Prolog Programming Techniques 205

Chapter 14: Nondeterministic Programming 206

14 . 3 Simulating nondeterministic computation models

Chapter 15 : Incomplete Data Structures

Chapter 16 : Parsing with Definite Clause Grammars 256

Chapter 17 : Second - Order Programming

Chapter 19: MetaInterpreters 303

Part IV . Applications 333

Chapter20: Game-PlayingPrograms 334

Chapter 21 : A Credit Evaluation Expert System 351

Chapter 22 : An Equation Solver 361

Chapter 23: A Compiler 380

List of Programs 415

List of Figures 421

Programming in Prolog opens the mind to a new way of looking at computing .

There is a change of perspective which every Prolog programmer experiences when

first getting to know the language .

that a declarative statement of the form :

could also be interpreted procedurally as :

To solve P , solve Q and R and S .

I sat at a clattering teletype connected down an ordinary telephone line to an

be constructed as sequences of actions . There was one important rule , modell - ed

how to elaborate a plan by inserting an action in the middle of the plan . As an

On the contrary , Prolog is a programming language , borrowing its basic constructs

A recommended division of the book for a 13 - week course to senior undergraduates

encouraging students to develop a declarative style of writing programs , 4 weeks

There is considerable flexibility in the order of presentation . The material

Our assessment of students has usually been 50 % by homework assignments