A "Hands-on" Introduction to
Pure Logic Programming (Pure Prolog)

Slide 2 — Terms: variables, constants and structures

Variables start with an uppercase character or an underscore, and may contain underscores and digits: X, Im4u, A_little_garden, _, _x, _22.

If you want a variable whose name would otherwise start with a small letter, put an underscore in front — _x. And _ on its own is a special one: the anonymous variable. You may have met it in other languages; a lot of them have it, and it came originally from Prolog. It is a variable that is different from every other variable. Use it when you need a variable in a position but it will not share with anything else and you do not want to name it.

Constants have a lowercase first character and may contain underscores: a, dog, a_big_cat. Numbers are constants too — 23, and floating point numbers later. If you want a constant that starts with a capital, you cannot write it directly, because that would be a variable; you quote it: 'Hungry man'.

And a great many symbols are constants as well. Pretty much anything that does not start with an underscore or a capital is a constant. For example [], the empty list, is a constant — no different from a, just two characters.

Structures are a functor — the structure name, which looks like a constant — followed by a fixed number of arguments in parentheses, separated by commas:

date(monday, Month, 1994)

Arity is the number of arguments. date(monday, Month, 1994) has arity 3. Functors are usually written name/arity, so this one is date/3; the arity matters in many contexts.

And now a nice consequence: you can think of constants as functors of arity zero, with no arguments. That blends the two ideas rather elegantly — a constant is just a structure that happens to have no arguments. So the constant a is the functor a/0.

Slide 3 — More on terms

Some examples, and one that is not allowed:

Why is Tee(Alf, rob) illegal? Because the functor starts with a capital letter, so it would be a variable — and a variable in functor position takes us out of first-order logic into higher-order logic. (In Ciao you actually can do that, because Ciao supports higher order; but that is a different story, and it comes much later.)

a + b        which is exactly the term        '+'(a,b)

?- X = a+b.

X = a+b ?

?- X = +(a,b).

X = a+b ?

?- write(+(a,b)), nl.

a+b

?- write(foo(a,b)), nl.

foo(a,b)

?- write(a foo b).

{SYNTAX ERROR: (lns 2-1) , or ) expected in arguments
write( a
** here **
foo b ) .
}

Slide 4 — Rules and facts (clauses)

A rule has this shape:

p₀(t₁, ..., tₙ) :- p₁(...), p₂(...), ..., pₘ(...).

The vocabulary:

• p₀(t₁, ..., tₙ) is the head of the rule.
• Each pᵢ(...) to the right of the arrow is a literal.
• The set of all those literals is the body.
• The :- is the neck.

A fact is a special kind of rule: one with an empty body. When the body is empty we do not write the arrow either — we could write it with nothing after it, but that is a waste of time.

meal(soup, beef, coffee).                    % a fact

meal(First, Second, Third) :-                % a rule
    appetizer(First),
    main_dish(Second),
    dessert(Third).

Facts and rules together are called clauses. The piece of program above has two clauses: a fact and a rule.

Slide 5 — Predicates, programs and queries

pet(X) :- animal(X), barks(X).
pet(X) :- animal(X), meows(X).
pet(X) :- animal(X), roars(X), small(X).

animal(tim).
animal(spot).
animal(hobbes).

Two predicates means two procedures, like f and g in an imperative language. pet/1 is a procedure with three cases; it is a bit like a case statement, but it is a procedure, and you call it by name with arguments, exactly as you would elsewhere.

A program is a set of predicates. The program above is one program, composed of two predicates, each of which has three clauses — pet/1 with one fact and two rules if you fill in the third clause differently, animal/1 with three facts.

This terminology is worth learning properly, because it is used constantly from here on.

:- pet(X).

?- pet(X).

Slide 6 — The declarative meaning of facts and rules

It means two things, and here is something we will meet all the time: there is the logical view and the procedural or program view. This is at the same time a piece of logic and a program that runs. From the point of view of logic, what it says is called the declarative meaning.

Facts state things that are true. Remember that a fact has an empty body, and an empty body is like putting true there — it is the same thing. true is true; you do not have to prove it. So a fact says p if nothing: it is true by itself, with no conditions. When we write animal(spot) we are saying "spot is an animal".

In rules, the commas are conjunction, and :- is classical implication. So

p :- p₁, ..., pₘ.        means        p ← p₁ ∧ ... ∧ pₘ

So pet(X) :- animal(X), barks(X). reads as "X is a pet if it is an animal and it barks". That is exactly what it means from the logical point of view.

pet(X) :- animal(X), barks(X).
pet(X) :- animal(X), meows(X).

Slide 7 — The declarative meaning of predicates and queries

X is a pet if it is an animal and it barks; or X is a pet if it is an animal and it meows. Two alternative ways of being a pet.

And the same reading applies to a table of facts. animal(tim). animal(spot). animal(hobbes). says that there are three ways of being an animal — or, equivalently, that there are three individuals who are animals. Alternatives, again.

A query asks whether something follows from the program — and, if it does, for which values of its variables.

Slide 8 — "Execution" and semantics

:- module(_,_,[]).

pet(X) :- animal(X), barks(X).
pet(X) :- animal(X), meows(X).

animal(tim).
animal(spot).
animal(hobbes).

barks(spot).
meows(tim).
roars(hobbes).

So if we ask pet(X) — does there exist an X that is a pet? who is a pet? — the system tries to find a substitution for X that makes pet(X) true.

Just by looking, intuitively: an animal that barks — animal(spot) and barks(spot), so spot is certainly an answer. An animal that meows — animal(tim) and meows(tim), so tim is another.

The operational semantics is the other question: how does the system compute those answers? How does the program run? That distinction — the obvious logical semantics, and the mechanism that computes it — is one we will keep returning to.

?- barks(X).

X = spot ? ;
no

?- animal(X).

X = tim ? ;
X = spot ? ;
X = hobbes ? ;
no

?- pet(tim).

yes

?- pet(hobbes).

no

?- pet(X).

X = spot ? ;
X = tim ? ;
no

Slides 9–10 — Running programs, and the top-down operational meaning

?- use_module('2examples_bfall').

:- module(_,_,['sr/bfall']).

The operational semantics is resolution, which we now describe informally in a form you can follow by hand.

Given a query, take the leftmost literal — a procedure call — and look for a clause whose head matches it. Matching here is not equality: it is unification, which is the subject of the next four slides. If a matching clause is found, replace the call by that clause's body, with the matching substitution applied, and carry on. When nothing is left to prove, the query has succeeded, and the accumulated substitution is the answer.

If a call has several matching clauses, that is a choice point: the alternatives are tried in turn. If a call has no matching clause, we backtrack to the most recent choice point and take the next alternative there.

That is the whole mechanism. What makes it work as programming rather than as proof search is what the next slides are about.

Slide 11 — Unification: one operation with many uses

That is one operation covering what most languages need half a dozen mechanisms for. And it is one procedure to solve equations on data structures.

Take two equations: X = f(Y) and Y = a. They say X must equal f(Y) and Y must equal a. Unification solves that system: Y is a, which we knew, and for the whole thing to hold together X has to be f(a).

?- X = f(Y), Y = a.

X = f(a),
Y = a ?

?- X = f(Y), X = f(b).

X = f(b),
Y = b ?

Like many equation-solving procedures, it works by isolating variables and instantiating them with their values.

Slide 12 — Unification, more formally

Said again: given two terms A and B, how can we make them identical by giving values to the variables in them?

More formally, we want to find a variable substitution — X = a is a variable substitution, and a substitution in general is a set of them — a θ such that applying θ to A and applying θ to B makes the two equal. Or, if no such substitution exists, to fail: to say that this is impossible.

There are two rules in the process:

1. You can only give values to variables. You cannot change a constant: a is a. But X, being a variable, can become b or c or whatever is needed.
2. Structures can only be made identical by making their arguments identical — which is obvious once said.

The first is already identical, so nothing has to be done — the substitution is empty, and applying nothing to either side gives dog. The second gives X the value a; B was already a and stays put, and A, which was X, becomes a. The third makes one variable be the other — a bit trickier, since the variables are confusing at first, but you get the hang of it.

The fourth is the first genuinely non-trivial one, and worth walking through slowly. Start on the left: f against f, fine. First argument: X against m(h). These will never be identical unless X is m(h), so that is the first substitution. Continue: g against g, fine. Inside them, t against M — and since we may replace a variable by a constant or a structure, and nothing else, we set M = t.

Now apply the substitution to both sides and check. A becomes f(m(h), g(t)). B becomes f(m(h), g(t)). Identical. It worked.

?- f(X, g(t)) = f(m(h), g(M)).

M = t,
X = m(h) ?

?- f(X, g(t)) = f(m(h), t(M)).

no

Y = l(Y)

Slide 13 — The most general unifier

Take the pair from the previous slide, f(X, g(t)) against f(m(H), g(M)). One solution is {X = m(a), H = a, M = t}: apply it and both sides become f(m(a), g(t)). Identical — so it is a correct unifier. But look at what it did: it invented a value for H that nothing in the problem required.

The other solution is {X = m(H), M = t}, which leaves H alone entirely. Both make the terms equal; they are quite different substitutions.

That is what "minimal values" meant on the previous slide, and it matters, because committing early to a value that was not forced would lose solutions.

Slide 14 — The unification algorithm

Slide 15 — The unification algorithm: worked examples

?- p(X,f(b)) = p(a,Y).

X = a,
Y = f(b) ?

?- p(X,f(Y)) = p(a,g(b)).

no

?- p(X,X) = p(f(Z),f(W)).

X = f(W),
Z = W ?

?- p(X,f(Y)) = p(Z,X).

X = f(Y),
Z = f(Y) ?

?- p(X,f(X)) = p(Z,Z).

X = f(X),
Z = f(X) ?

Standard Prolog omits it, because it costs time on every single unification and almost never matters. It is available when you want it:

:- module(_,_,[]).
:- use_module(library(iso_misc)).

check(X, Z) :- unify_with_occurs_check(p(X,f(X)), p(Z,Z)).

?- check(X, Z).

no

Slide 16 — A schematic interpreter (SLD-resolution)

Input and output. The input is a logic program P and a query Q. The output is Qμ, where μ is an answer substitution — values for the variables that appear in the query, which Prolog prints as A = something, B = something. You get that if Q is provable from P, that is, if Q is a logical consequence of P. Otherwise you get failure, which may be a finite failure or an infinite one.

The algorithm. There is one intermediate data structure, called the resolvent, R. Initialize it to the query Q. Then, while R is not empty:

1. Take the leftmost literal in R; call it A.
2. Choose a clause from the program whose head unifies with A. That is where the unification algorithm of the previous slides is used: we need a substitution θ making the head and A identical.
3. When we take a clause we are careful to rename it — fresh names for its variables each time. If the clause has a variable X, it becomes X1 the first time we use the clause, X2 the second, and so on. This is so that repeated applications, especially of recursive clauses, do not get confused with each other.
4. Replace A in R by the body of the chosen clause, and apply θ to the whole resolvent.

When R becomes empty, we have a proof, and the composition of all the θs, restricted to the query's variables, is the answer.

C1: pet(X) :- animal(X), barks(X).
C2: pet(X) :- animal(X), meows(X).
C3: animal(spot).      C6: barks(spot).
C4: animal(tim).       C7: meows(tim).
C5: animal(hobbes).    C8: roars(hobbes).

Q = pet(X1)        R = animal(X1), meows(X1)        C2*   {P = X1}

Q = pet(tim)       R = meows(tim)                   C4*   {X1 = tim}

Q = pet(tim)       R = (empty)                      C7    {}

:- module(_,_,[]).

pet(X) :- animal(X), barks(X).
pet(X) :- animal(X), meows(X).

animal(tim).
animal(spot).
animal(hobbes).

barks(spot).
meows(tim).
roars(hobbes).

?- pet(P).

P = spot ? ;
P = tim ? ;
no

Slide 17 — The choices made in standard Prolog

1. Make a copy Q' of Q.
2. Initialize the resolvent R to { Q }.
3. While R is non-empty:
   1. Take the leftmost literal A in R.
   2. Take the first clause A' :- B₁, …, Bₙ (renamed) from P whose head has the same predicate symbol as A.
      • If there is a solution θ to A = A' (unification): replace A in R by B₁, …, Bₙ, and apply θ to both R and Q.
      • Otherwise take the next clause and repeat.
   3. If there are no more clauses, go back to the most recent pending choice.
   4. If there are no pending choices left, output failure.
4. When R is empty, output the solution μ to Q = Q'.
5. On request, explore the most recent pending branch for more solutions.

Slide 18 — Search rule and computation rule

The choice of clause defines the alternative paths to be explored, and execution explores that tree — depth-first, breadth-first, or otherwise. Since the schematic interpreter leaves the choice open, any logic programming system has to supply one:

Choosing a different clause changes the order in which solutions appear. Both of these are valid executions of the same program and the same query:

?- pet(X).                    ?- pet(X).
X = spot ? ;                  X = tim ? ;
X = tim ? ;                   X = spot ? ;
no                            no

The computation rule has a freedom of its own. We said "take the leftmost literal", but any literal would do — and you could even take several at once, which is where parallelism comes from.

Slides 19–21 — Alternative execution paths, and the "normal programming" view

The slides trace two of them side by side for ?- pet(X)., showing at each step the query, the resolvent, the clause chosen and the substitution. The first trace takes clause animal(tim) and reaches barks(tim), which has no matching clause: failure.

The starred entries in those tables are the choice points — the calls where other clauses were still applicable. Failure is not the end of the story: we go back to the last choice point and try the next alternative. Taking animal(spot) instead, barks(spot) does match, and the query succeeds with X = spot.

Typing ; at the ? prompt asks the system to go back and explore yet another branch.

Slide 22 — Continuations, and why Prolog is not slow

p(X,Y) :- q(X,Z), r(Z,Y).

Slide 23 — Programs with and without search

The slide draws the distinction precisely, and it is worth having the vocabulary.

Programs without search — those that do no "deep" backtracking. In practice that means a program whose procedures have either a single clause, or several of which only one is ever selected for any given call, so the clauses act as a case statement rather than as alternatives.

Programs with search — those with at least one procedure where more than one clause is selected for some calls. These perform search, by backtracking or by another search rule, and they have no direct counterpart in imperative or functional programming.

Slide 24 — The search tree

Take the pets program and the query pet(X). First there is a choice of clause for pet — the barks one or the meows one. Then animal(X) has three possibilities in each branch. Then barks(X) has one, and meows(X) has one. The points where the tree splits are the choice points; where a call has only one matching clause there is no real choice.

A different query gives a different tree. Ask pet(spot) instead. At the pet call there are still two choices, but at animal(spot) there is now only one, because X is already instantiated: animal(tim) and animal(hobbes) will not match. So the tree depends on the question — and for the same question, on the bindings of its variables.

The search and computation rules explain how this tree is explored. A search rule that takes the first clause, then the second, explores the leftmost branch first, then the next — which is depth-first.

Slide 25 — Characterizing the search tree

Go back to semi-decidability, the general limitation we met in the introduction: if you ask a question that has an answer, you will find it in finite time; if the answer is no, you may find that out in finite time, or you may not.

In terms of the search tree that means:

The picture shows the three cases: a tree that is finite and has solutions, a tree that is finite and has none, and an infinite tree, where a solution may sit to the right of a branch that never ends.

That is the fact everything else in this section follows from.

Slides 26–28 — Depth-first, breadth-first, and choosing between them

Breadth-first search explores the tree level by level: one step down this branch, one step down that one, then the next level everywhere, and so on. Since every solution is at finite depth, it will reach every one of them before falling down an infinite branch — breadth-first is complete.

The price is in time and, above all, memory: to be at any point in the exploration you must have the whole tree above you stored somehow, however compressed. Depth-first needs one branch; this needs the whole frontier.

Depth-first is what Prolog does by default, and for a good reason: it is efficient, and Prolog is meant to be a programming language. There are ways of reordering clauses so that infinite branches move to the right and depth-first finds the solutions first — but that requires understanding what is going on and thinking about it. That is the second part of the course. Here we can ignore it.

Ciao lets you choose, per module:

:- module(_, _, [sr/bfall]).     % breadth-first: complete, slower, more memory
:- module(_, _, []).             % default: Prolog's depth-first

Slides 29–30 — Control of search: clause and goal order

Two orderings are under your control, and both change how much work gets done.

The order of goals in a body. Consider:

:- module(_,_,[]).
:- use_module(library(system),[pause/1]).

a(X,Y) :- p(X), q(X,Y).     % p first, then q
b(X,Y) :- q(X,Y), p(X).     % q first, then p

p(4).
p(5).

q(1, a) :- lots_of_computing.
q(2, b) :- lots_of_computing.
q(4, c) :- lots_of_computing.
q(4, d) :- lots_of_computing.

lots_of_computing :- pause(3).

Same logic, same answers, very different amount of work. This is the generate-and-test versus constrain-and-generate distinction that the CLP deck later builds a whole chapter on.

Slide 31 — The role of unification in execution

• passing arguments in — the caller's terms meet the head's terms;
• returning results out — a variable in the call gets bound by the head;
• selecting a clause — a head that does not unify is simply not applicable.

:- module(_,_,[]).

animal(dog(barry)).
named(dog(Name), Name).

?- animal(A), named(A, Name).

A = dog(barry),
Name = barry ?

Slide 32 — "Modes"

In a functional language the arguments are all inputs and the return value is the output — a bunch of inputs and one output. Here it is not like that. Is the argument of pet/1 an input or an output? It depends. Ask pet(spot) and it is an input: you are handing spot to the procedure and asking it to check. Ask pet(X) and it is an output: you are asking the procedure to produce a value. Same argument, same procedure.

So arguments are bidirectional, and which role they play depends on their instantiation state at the moment of the call.

:- module(_,_,[]).

add(0, Y, Y).
add(s(X), Y, s(Z)) :- add(X, Y, Z).

?- add(s(0), s(s(0)), Z).

Z = s(s(s(0))) ?

?- add(s(0), Y, s(s(s(0)))).

Y = s(s(0)) ?

That combination of inputs and outputs has a name: the mode of a call. A three-argument predicate might be called in mode input-input-output, or input-output-input, or output-input-input, and so on. We write modes with + and -:

add(+X, +Y, -Z)     X and Y are given; Z is where the answer comes back

Slide 34 — Pure logic programs: an overview

Everything so far has been pure: no cut, no assert, no arithmetic evaluation, no negation. What we have is Horn clauses plus unification plus a search rule — and that is enough to program with, as the rest of this deck shows.

Slides 35–36 — Database programming

:- module(_,_,[sr/bfall]).

father_of(john, peter).
father_of(john, mary).
father_of(peter, michael).
mother_of(mary, david).
mother_of(jill, john).

grandfather_of(L,M) :-
    father_of(L,N),
    father_of(N,M).
grandfather_of(X,Y) :-
    father_of(X,Z),
    mother_of(Z,Y).

Queries first. Facts already in the program are easy:

?- father_of(john, peter).

yes

?- father_of(john, david).

no

?- father_of(john, X).

X = peter ? ;
X = mary ? ;
no

?- grandfather_of(X, Y).

X = john, Y = michael ? ;
X = john, Y = david ? ;
no

Both directions work equally well. Ask who is the grandfather of michael and you get john — via john, peter, michael — and no one else:

?- grandfather_of(X, michael).

X = john ? ;
no

?- grandfather_of(john, X).

X = michael ? ;
X = david ? ;
no

A second example makes the point that "database" need not mean people and dates. Here the facts are the topology of a circuit — which resistors and transistors connect which nodes — and the rules are a little bit of circuit theory, saying what an inverter, a NAND gate and an AND gate look like in terms of that topology:

:- module(_,_,[sr/bfall]).

resistor(power,n1).
resistor(power,n2).

transistor(n2,ground,n1).
transistor(n3,n4,n2).
transistor(n5,ground,n4).

inverter(Input,Output) :-
   transistor(Input,ground,Output),
   resistor(power,Output).

nand_gate(Input1,Input2,Output) :-
   transistor(Input1,X,Output),
   transistor(Input2,ground,X),
   resistor(power,Output).

and_gate(Input1,Input2,Output) :-
   nand_gate(Input1,Input2,X),
   inverter(X, Output).

?- and_gate(In1, In2, Out).

In1 = n3,
In2 = n5,
Out = n1 ?

Slides 37–40 — Structured data, data abstraction, and =

course(complog,wed,18,30,20,30,'M.','Hermenegildo',new,5102).

?- course(complog,Day,StartH,StartM,FinishH,FinishM,C,D,E,F).

Alternatively, structure it:

:- module(_,_,[]).

course(complog, Time, Lecturer, Location) :-
    Time     = t(wed, 18:30, 20:30),
    Lecturer = lect('M.','Hermenegildo'),
    Location = loc(new, 5102).

course(complog, t(wed,18:30,20:30), lect('M.','Hermenegildo'), loc(new,5102)).

?- course(complog, Time, A, B).

A = lect('M.','Hermenegildo'),
B = loc(new,5102),
Time = t(wed,18:30,20:30) ?

?- course(complog, Time, _, _).

Time = t(wed,18:30,20:30) ?

Now the general point. Terms are the only data structure, and they are enough. A structure groups related things: date(monday, Month, 1994) is a record with three fields; person(name(john,smith), age(23)) nests records inside records.

Two habits are worth forming early.

Use the anonymous variable for fields you do not care about. If you want the year out of a date, write date(_, _, Year) rather than inventing names you never use. Each _ is a different fresh variable, which is exactly what you want here.

Access fields by unification, not by taking things apart. To get at the year you do not call an accessor; you unify the whole term with a pattern and let the year fall out. That is what "data abstraction" means in this setting: the pattern is the accessor.

The = predicate deserves a note. X = Y is not assignment and not a test — it is a call to the unification algorithm, exactly as on slide 11. It succeeds if the two can be made identical, and binds whatever it must to achieve that.

Terms as data structures with pointers (slide 39). A term in memory is a functor cell followed by its arguments, and an argument that is a structure is a pointer to it. So f(g(a),X) is a cell for f/2, a pointer to a g/1 cell, and an unbound cell for X. Unification with f(Y,b) makes Y point at the g(a) structure — no copying — and fills in the X cell with b.

That is why unification is cheap, and why "modifying" a data structure is in quotes: you never overwrite anything, you bind variables that were left unbound.

The slide draws the heap after

main :-
    X = f(K,g(K)),
    Y = a,
    Z = g(L),
    W = h(b,L),
    % heap memory at this point --->
    p(X,Y),
    q(Y,Z),
    r(W).

Note the aliasing: K occurs twice in X, so both places point at the same cell, and L is shared between Z and W. Calling p(X,Y) passes pointers to these structures, not copies. Which is the summary: terms are data structures with pointers, and logical variables are declarative pointers — they can only be assigned once.

Slides 41–42 — Logic programs and the relational database model

The last one is the pretty one. In grandfather_of(L,M) :- father_of(L,N), father_of(N,M). the shared N is the join: the two tables are joined on the column where the variable is repeated. You do not write a join operator; you write the same variable twice.

Slide 43 — Deductive databases, Datalog and ASP

The field has grown languages of its own, and they are deliberately less powerful than Prolog. They take a subset of definite programs and restrict the syntax:

• Datalog allows no functors, and therefore no data structures: the only terms are the constants already in the database. Nor does it allow existential variables — a rule concludes only about individuals its body already mentions.
• Execution is bottom-up instead of Prolog's top-down search: start from the facts and apply the rules, with the T_P operator that the theory part of the course introduces, until nothing new is derived; then keep the part of that model the query asks about.

What the restrictions buy is reasoning. These systems support much stronger notions of negation, under the stable model semantics, which is the basis of Answer Set Programming (ASP): you state what holds and what cannot hold, and the system returns the models that satisfy it all. For knowledge representation and reasoning that is a very effective way to write a problem down.

Slide 45 — Recursive programming

:- module(_,_,[]).

parent(X,Y) :- father_of(X,Y).
parent(X,Y) :- mother_of(X,Y).

ancestor(X,Y) :- parent(X,Y).
ancestor(X,Y) :- parent(X,Z), ancestor(Z,Y).

father_of(john, peter).
father_of(john, mary).
father_of(peter, michael).
mother_of(mary, david).
mother_of(jill, john).

?- ancestor(john, X).

X = peter ? ;
X = mary ? ;
X = michael ? ;
X = david ? ;
no

Slides 46–47 — What about "not equal"?

The pure answer is to define the complement as a relation, positively. For naturals in Peano form:

:- module(_,_,[]).

person_num(john,    0).
person_num(peter,   s(0)).
person_num(mary,    s(s(0))).
person_num(michael, s(s(s(0)))).
person_num(david,   s(s(s(s(0))))).
person_num(jill,    s(s(s(s(s(0)))))).

diffnat(0, s(_)).                     % 0 differs from any s(...)
diffnat(s(_), 0).                     % any s(...) differs from 0
diffnat(s(X), s(Y)) :- diffnat(X,Y).  % same depth: look further in

different_person(X,Y) :-
    person_num(X,NX),
    person_num(Y,NY),
    diffnat(NX,NY).

?- different_person(john, mary).

yes

?- different_person(john, john).

no

And note the other half: to say two things are equal, you need no test at all. Use the same variable twice and unification does it.

Slides 48–49 — Types, and recursive types

Keep those two apart: the type is the set, the definition is the program.

Take weekday. The set of terms is 'Monday', 'Tuesday', … — in quotes, because they start with a capital and are constants, not variables. The definition is seven facts.

Now a structured type. A date is a weekday together with a day of the month, so the set of terms we want is date('Monday',23), date('Tuesday',24) and so on — and the definition is one clause using two other types:

:- module(_,_,[sr/bfall]).

weekday('Monday').    weekday('Tuesday').   weekday('Wednesday').
weekday('Thursday').  weekday('Friday').    weekday('Saturday').
weekday('Sunday').

day_of_month(1).  day_of_month(2).  day_of_month(31).

date(date(W,D)) :- weekday(W), day_of_month(D).

?- date(date('Monday',31)).

yes

?- date(date('Monday',23)).

no

:- module(_,_,[sr/bfall]).

nat_num(0).
nat_num(s(X)) :- nat_num(X).

% Integers: a natural, possibly with a minus in front.
pint( X) :- nat_num(X).
pint(-X) :- nat_num(X).

?- nat_num(s(s(s(0)))).

yes

Slides 50–53 — Arithmetic, the pure way

:- module(_,_,[sr/bfall]).

nat(0).
nat(s(X)) :- nat(X).

less_or_equal(0,X) :- nat(X).
less_or_equal(s(X),s(Y)) :- less_or_equal(X,Y).

plus(0,Y,Y) :- nat(Y).
plus(s(X),Y,s(Z)) :- plus(X,Y,Z).

?- less_or_equal(s(0), s(s(0))).

yes

?- less_or_equal(X, 0).

X = 0 ? ;
no

?- less_or_equal(X, s(s(0))).

X = 0 ? ;
X = s(0) ? ;
X = s(s(0)) ? ;
no

?- plus(s(0), s(s(0)), Z).

Z = s(s(s(0))) ?

?- plus(X, Y, s(s(0))).

X = 0,       Y = s(s(0)) ? ;
X = s(0),    Y = s(0) ? ;
X = s(s(0)), Y = 0 ? ;
no

?- plus(X, s(0), s(s(s(0)))).

X = s(s(0)) ?

?- plus(X, s(s(0)), s(0)).

no

plus(X,0,X) :- nat(X).
plus(X,s(Y),s(Z)) :- plus(X,Y,Z).

Slides 54–57 — Functional syntax

Writing plus(X, Y, Z) everywhere is faithful to the relational reading but verbose when you only want a value. Ciao's functional syntax package lets you write the same predicates as functions, without changing what they are:

:- use_package(functional).
:- fun_eval plus/2.

Ackermann's function is the standard example of something that is easy to define and expensive to compute. Written in a functional language over Peano numbers, it is three equations:

datatype nat = Zero | S of nat

fun ack 0 n = S n
  | ack (S m1) 0 = ack m1 (S 0)
  | ack (S m1) (S n1) = ack m1 (ack (S m1) n1)

:- module(_,_,[]).

ack(0, N, s(N)).
ack(s(M), 0, Val) :-
    ack(M, s(0), Val).
ack(s(M), s(N), Val) :-
    ack(s(M), N, Val1),
    ack(M, Val1, Val).

?- ack(s(s(0)), s(s(s(0))), X).

X = s(s(s(s(s(s(s(s(s(0)))))))))

Being a predicate rather than a function, it also runs in the other directions, which the functional definition cannot do at all:

?- ack(s(s(0)), Y, s(s(s(s(s(s(s(s(s(0)))))))))).

Y = s(s(s(0)))

Slide 56 writes the same three clauses in functional syntax, with s declared as a prefix operator so that the Peano numbers need no parentheses:

:- module(_,_,[]).
:- use_package(functional).
:- op(100,fy,s).

ack(  0,   N) := s N.
ack(s M,   0) := ack(M, s 0).
ack(s M, s N) := ack(M, ack(s M, N) ).

Slide 57 applies the same notation to a type, in four steps. Starting from nat/1, written with := naming the result argument:

nat := 0.
nat := s(X) :- nat(X).

nat := 0.
nat := s(~nat).

nat := 0.
nat := s(nat).

with the prefix operator the parentheses go too, and | writes the two clauses as one:

nat := 0.
nat := s nat.

nat := 0 | s nat.

That last line is a type definition as compact as a functional language's datatype, and it means exactly what we started with:

:- module(_,_,[]).
:- use_package(functional).
:- op(100,fy,s).

nat := 0 | s nat.

?- nat(s(s(0))).

yes

Slides 58–59 — Lists as a recursive type

A list is a binary structure — a pair whose first argument is an element and whose second is the rest of the list. To build it we need two things:

• a constant for the empty list, so that we know how to stop, exactly as 0 did for nat/1. It is written [] and it is a constant, no more mysterious than a;
• a functor of arity 2 for the pair. Traditionally this is . — overloaded and best avoided in your own programs, but that is the convention.

?- X = '.'(a,'.'(b,[])).

X = [a,b] ?

?- [a,b,c] = [X|Y].

X = a,
Y = [b,c] ?

?- [a] = [a,b|X].

no

?- [a,b] = [X|_].

X = a ?

?- [a,b,c,d,e,f,g] = [X,Y|Z].

X = a,
Y = b,
Z = [c,d,e,f,g] ?

:- module(_,_,[]).

list([]).
list([_|Y]) :- list(Y).

list_member(X, [X|L]) :- list(L).
list_member(X, [_|T]) :- list_member(X, T).

list_length([], 0).
list_length([_|T], s(N)) :- list_length(T, N).

Slides 60–61 — Append

:- module(_,_,[]).

list([]).
list([_|Y]) :- list(Y).

list_append([], L, L) :- list(L).
list_append([X|Xs], Ys, [X|Zs]) :- list_append(Xs, Ys, Zs).

?- list_append([1,2], [3,4], Z).

Z = [1,2,3,4] ?

?- list_append(X, Y, [1,2]).

X = [],     Y = [1,2] ? ;
X = [1],    Y = [2] ? ;
X = [1,2],  Y = [] ? ;
no

In between those two extremes there are the intermediate modes, and they are the ones worth trying by hand. Checking a result:

?- list_append([a,b], [1,2], [a,b,1,2]).

yes

?- list_append([a,b], Y, [a,b,1,2]).

Y = [1,2] ?

?- list_append(X, [1,2], [a,b,1,2]).

X = [a,b] ?

Slide 62 — One way to understand recursive programs

When writing a recursive predicate over a list, ask two questions and write one clause for each:

1. What holds for the empty list? That is the base case.
2. Assuming it holds for the tail, what holds for [H|T]? That is the step.

Slides 63–67 — Reverse, and the cost of getting it wrong

:- module(_,_,[]).

list([]).
list([_|Y]) :- list(Y).

list_append([], L, L) :- list(L).
list_append([X|Xs], Ys, [X|Zs]) :- list_append(Xs, Ys, Zs).

% naive: reverse the tail, then append the head at the end
reverse_naive([], []).
reverse_naive([X|Xs], Ys) :-
    reverse_naive(Xs, Zs),
    list_append(Zs, [X], Ys).

% accumulator: carry the answer being built
reverse_acc(Xs, Ys) :- reverse_(Xs, [], Ys).

reverse_([], Ys, Ys).
reverse_([X|Xs], Acc, Ys) :-
    NewAcc = [X|Acc],
    reverse_(Xs, NewAcc, Ys).

Both give the same answer:

?- reverse_naive([1,2,3], Y).

Y = [3,2,1] ?

?- reverse_acc([1,2,3], Y).

Y = [3,2,1] ?

?- reverse_naive(X, [3,2,1]).

X = [1,2,3] ?

X = [],       Y = []       ? ;
X = [_A],     Y = [_A]     ? ;
X = [_B,_A],  Y = [_A,_B]  ? ;
...

reverse_acc(Xs,Ys) :- reverse_(Xs,[],Ys).

reverse_([],Ys,Ys).
reverse_([X|Xs],Acc,Ys) :-
    NewAcc = [X|Acc],
    reverse_(Xs,NewAcc,Ys).

:- use_module(engine(runtime_control),[statistics/2]).
:- use_module(library(lists),[length/2]).

rev_naive(N,T) :-
    length(L,N),
    statistics(walltime, [_,_]),
    reverse_naive(L,_RL),
    statistics(walltime, [_,T]).

Slides 68–69 — Binary trees

For lists we used a pair — a functor of arity 2. For a binary tree we need arity 3: the contents of the node, the left subtree and the right subtree. And we need a constant for the empty tree, the way [] was the empty list; we call it void, though the name is arbitrary.

A binary tree is empty, or a node with an element and two subtrees:

:- module(_,_,[]).

binary_tree(void).
binary_tree(tree(_Element, Left, Right)) :-
    binary_tree(Left),
    binary_tree(Right).

tree_member(X, tree(X, Left, Right)) :- binary_tree(Left), binary_tree(Right).
tree_member(X, tree(_, Left, _Right)) :- tree_member(X, Left).
tree_member(X, tree(_, _Left, Right)) :- tree_member(X, Right).

?- binary_tree(tree(foo, void, tree(bar, void, void))).

yes

?- binary_tree(tree(a, b, c)).

no

?- binary_tree(tree(a, [], [])).

no

T = void ? ;
T = tree(_,void,void) ? ;
T = tree(_,void,tree(_,void,void)) ? ;
T = tree(_,tree(_,void,void),void) ? ;
...

tree_member/2 needs three clauses where the list version needed two, because there are two subtrees to look in rather than one tail. Otherwise it is the same thought: X is in the tree if it is the contents of this node, or if it is somewhere in the left branch, or somewhere in the right.

?- tree_example(_T), tree_member(e, _T).

no

Traversal turns a tree into a list, and the shape of the clause decides which traversal you get:

:- module(_,_,[]).

list([]).
list([_|Y]) :- list(Y).
list_append([], L, L) :- list(L).
list_append([X|Xs], Ys, [X|Zs]) :- list_append(Xs, Ys, Zs).

pre_order(void, []).
pre_order(tree(X,Left,Right), Elements) :-
    pre_order(Left, ElementsLeft),
    pre_order(Right, ElementsRight),
    list_append([X|ElementsLeft], ElementsRight, Elements).

tree_example(tree(a, tree(b, void, void), tree(c, tree(b, void, void), void))).

?- tree_example(T), pre_order(T, L).

L = [a,b,c,b],
T = tree(a,tree(b,void,void),tree(c,tree(b,void,void),void)) ?

Slide 70 — Polymorphism

lt_member(X, [X|Y])          :- list(Y).
lt_member(X, [_|T])          :- lt_member(X, T).
lt_member(X, tree(X, L, R))  :- binary_tree(L), binary_tree(R).
lt_member(X, tree(_, L, _))  :- lt_member(X, L).
lt_member(X, tree(_, _, R))  :- lt_member(X, R).

T = [M] ? ;
T = [M,_] ? ;
T = [_,M] ? ;
T = tree(M,void,void) ? ;
T = tree(_,[M],_) ? ;
T = tree(_,_,[M]) ? ;
T = [M,_,_] ? ;
...

Can you keep the types apart? Certainly — but you have to write it. Keep the two original definitions, each recursing into itself, and put a two-clause wrapper on top:

lt_member_separate(X,Y) :- list_member(X,Y).
lt_member_separate(X,Y) :- tree_member(X,Y).

Slide 71 — Recognizing (and generating) polynomials

• X is a polynomial in X;
• a constant is a polynomial in anything;
• sums, differences and products of polynomials in X are polynomials in X;
• a polynomial raised to the power of a natural number is one, and so is the quotient of a polynomial by a constant.

:- module(_,_,[sr/bfall]).

polynomial(X,X).
polynomial(Term,_X)       :- pconstant(Term).
polynomial(Term1+Term2,X) :- polynomial(Term1,X), polynomial(Term2,X).
polynomial(Term1-Term2,X) :- polynomial(Term1,X), polynomial(Term2,X).
polynomial(Term1*Term2,X) :- polynomial(Term1,X), polynomial(Term2,X).
polynomial(Term1/Term2,X) :- polynomial(Term1,X), pconstant(Term2).
polynomial(Term1^N,X)     :- polynomial(Term1,X), nat_num(N).

pconstant(X) :- nat_num(X).
pconstant(a).
pconstant(b).
pconstant(c).

nat_num(0).
nat_num(s(X)) :- nat_num(X).

?- polynomial(a * x ^ s(s(0)) + b, x).

yes

?- polynomial(a * x ^ x + b, x).

no

As always, the same definition enumerates: polynomial(P,x) produces x, a, b, c, 0, x+x, x-x, and onwards through the polynomials in x.

poly_f(X) := X
    | ~pconst_f
    | ~poly_f(X) + ~poly_f(X)
    | ~poly_f(X) - ~poly_f(X)
    | ~poly_f(X) * ~poly_f(X)
    | ~poly_f(X) / ~pconst_f
    | ~poly_f(X) ^ ~nat_num.

pconst_f := ~nat_num | a | b | c.

Slide 72 — Symbolic differentiation

:- module(_,_,[sr/bfall]).

deriv(X,      X, s(0)                 ).
deriv(C,     _X, 0                    ) :- pconstant(C).
deriv(U+V,    X, DU+DV                ) :- deriv(U,X,DU), deriv(V,X,DV).
deriv(U-V,    X, DU-DV                ) :- deriv(U,X,DU), deriv(V,X,DV).
deriv(U*V,    X, DU*V+U*DV            ) :- deriv(U,X,DU), deriv(V,X,DV).
deriv(U/V,    X, (DU*V-U*DV)/V^s(s(0))) :- deriv(U,X,DU), deriv(V,X,DV).
deriv(U^s(N), X, s(N)*U^N*DU          ) :- deriv(U,X,DU), nat_num(N).
deriv(log(U), X, DU/U                 ) :- deriv(U,X,DU).

pconstant(X) :- nat_num(X).
pconstant(a).
pconstant(b).

nat_num(0).
nat_num(s(X)) :- nat_num(X).

?- deriv(x*x, x, D).

D = s(0)*x+x*s(0) ?

?- deriv(log(x), x, D).

D = s(0)/x ?

Slides 73–74 — Graphs

:- module(_,_,[sr/bfall]).

path(X,Y) :- edge(X,Y).
path(X,Y) :- edge(X,Z), path(Z,Y).

edge(a,b).  edge(a,c).  edge(b,d).
edge(c,d).  edge(d,e).  edge(d,h).

?- path(a, e).

yes

Slide 75 — Automata as graphs

:- module(_,_,[sr/bfall]).

accept(S) :- initial(Q), accept_from(S, Q).

accept_from([], Q)      :- final(Q).
accept_from([C|Cs], Q)  :- delta(Q, C, NewQ), accept_from(Cs, NewQ).

initial(q0).
final(q0).

delta(q0, a, q1).
delta(q1, b, q0).
delta(q1, b, q1).

Two things are being represented, and it is worth keeping them apart:

• The strings are lists of constants: a b b is [a,b,b].
• The automaton is a graph, and here a graph is most easily a set of facts. initial(q0) and final(q0) mark the states; the three delta/3 facts are the arrows, directions and all.

Where exactly is the non-determinism? In the call to delta/3. Running forwards, Q and C are given and NewQ comes back — but in state q1 reading b there are two transitions, one staying in q1 and one returning to q0. Take the first; if something fails later, backtrack and take the other. Nothing had to be programmed for that: it is what having several clauses for a predicate means.

?- accept([a,b]).

yes

?- accept([a,b,b,b]).

yes

?- accept([a,a]).

no

?- accept([A,B,C,D]).

A = a, B = b, C = a, D = b ? ;
A = a, B = b, C = b, D = b ? ;
no

Slide 76 — Adding a stack: pushdown automata

:- module(_,_,[sr/bfall]).

npda_accept(S) :-
    npda_initial(Q),
    npda_accept_from(S, Q, []).

npda_accept_from([], Q, [])  :-
    npda_final(Q).
npda_accept_from([C|Cs], Q, Stack) :-
    npda_delta(Q, C, Stack, NewQ, NStack),
    npda_accept_from(Cs, NewQ, NStack).

% A concrete automaton:
npda_initial(q0).
npda_final(q1).

npda_delta(q0, C,     Stack, q0, [C|Stack]).
npda_delta(q0, C,     Stack, q1, [C|Stack]).
npda_delta(q0,_C,     Stack, q1,    Stack ).
npda_delta(q1, C, [C|Stack], q1,    Stack ).

The slide asks: what sequence does it recognize? Rather than being told, run it.

?- npda_accept([a,b,b,a]).

yes

?- npda_accept([a,b,a,b]).

no

?- npda_accept([a,b,c,b,a]).

yes

[a,a,a,a], [a,b,b,a], [a,c,c,a],
[b,a,a,b], [b,b,b,b], [b,c,c,b],
[c,a,a,c], [c,b,b,c], [c,c,c,c]

Slides 77–79 — The Towers of Hanoi

Three pegs, a stack of disks on the first, and the rules: move one disk at a time, never place a larger disk on a smaller one, and get them all from peg a to peg b using c.

With one disk you just move it. With two you cannot put the big one down first, so: small one to c, big one to b, small one on top. With three it takes seven moves. The legend says that when the monks of Hanoi finish moving their tower the world will end; apparently they are still at it.

What we want from the program is not just that it can be done, but the list of moves. Each move is a term move(A,B), meaning move the top disk of peg A to peg B.

The general predicate carries more than the number of disks: hanoi(N, Origin, Destination, Help, Moves). It needs Help because the pegs change roles — sometimes you are moving from a to b using c, and sometimes from a to c using b. Reasoning it out:

• One disk in Origin, wanted in Destination: move it. No help needed, and no rule can forbid it.
• s(N) disks: the bottom one has to get to Destination, so first move the N above it out of the way onto Help — using Destination as the spare. Then move the bottom disk across. Then move those N from Help to Destination — now using Origin, which is empty, as the spare.

:- module(_,_,[]).

list([]).
list([_|Y]) :- list(Y).
list_append([], L, L) :- list(L).
list_append([X|Xs], Ys, [X|Zs]) :- list_append(Xs, Ys, Zs).

hanoi_moves(N, Moves) :- hanoi(N, a, b, c, Moves).

hanoi(s(0), A, B, _, [move(A,B)]).
hanoi(s(N), A, B, C, Moves) :-
    hanoi(N, A, C, B, Moves1),
    hanoi(N, C, B, A, Moves2),
    list_append(Moves1, [move(A,B)|Moves2], Moves).

The two pictures are the base case and the general case: one disk moves straight across, and s(N) disks move as three smaller problems in sequence.

?- hanoi_moves(s(s(0)), M).

M = [move(a,c),move(a,b),move(c,b)] ?

?- hanoi_moves(s(s(s(0))), M).

M = [move(a,b),move(a,c),move(b,c),move(a,b),move(c,a),move(c,b),move(a,b)] ?

The program returns the moves as a list rather than printing them, so the plan is data: you can inspect it, count it with length/2, check it, or feed it to something else. That is worth contrasting with the usual imperative version, which prints as it goes and leaves you nothing.

Slide 80 — Learning to compose recursive programs

Everything here has been pure: no cut, no assert, no arithmetic evaluation, no negation. The next deck adds those — and much of what it has to say is about what they cost.