In this section we see an application of logic in a language called ``Prolog'' (for PROgramming in LOGic). Of particular interest is the ``inference engine'' used by the language to prove theorems (i.e. answer queries).
Prolog (PROgramming in LOGic) is a declarative (rather than procedural) language, with its own inference rules which allow the user to pose interesting questions of a database of facts and rules.
While the book uses a PROLOG ``pseudo-code'', we will use a freely obtainable (GNU General Public License) version of prolog (SWI-Prolog) to get a better feeling for prolog. On our course website is a demo file that I will use today in class. I encourage you to download SWI-Prolog and experient!
This is composed of facts and ``rules'' (which are also facts!). In terms of predicate logic, one creates predicate wffs on the fly, and establishes which elements of the domain make them true. For example,
animal(bear)
says that the predicate A(x) representing the predicate wff ``x is an animal'' is true for the constant ``bear''.
Facts can be binary, as well (and n-ary in general, of course):
eat(bear,fox)
asserts that the predicate wff E(x,y) given by ``x eats y'' is satisfied by bears and foxes (to the chagrin of the foxes, and the delight of the bears).
In addition, rules can be established to check whether logical connectives between facts are true. For example,
prey(x) if eat(y,x) and animal(x)
would tell us if an animal is eaten by something else. In fact, notice that it is expressed as an implication (begun by ``if''): translated in more standard predicate wff form, it might read
which Prolog treats as if it is universally quantified:
(i.e., the compilation of the rule means that it is true for all x and for all y). So, as promised, the Prolog ``rules'' are simply more complex predicate wffs, rather than inference rules which it might use to prove theorems.
Once the database is created (``compiled''), we can move on to the important issue of posing interesting questions to the database.
Our text lists ``is'' and ``which'' as examples of Prolog queries. The first tests an assertion, whereas the second asks for all instances which makes a statement true.
Example: Practice 27/28, p. 60/61
Proofs are based on Horn clauses, which are simply implications expressed as disjunctions using the implication rule:
The right-hand side above is an example of a Horn clause: a wff composed of predicates or the negations of predicates joined by disjunctions, where at most one predicate is unnegated.
So all the facts, which were expressed either as existential instantiations or as implications with universal generalization, are expressible as Horn clauses. A general argument (turned into a Horn clause) looks like
The prey(x) rule from above,
is expressed as a Horn clause as
Prolog uses Horn clauses to prove arguments by resolution (which is essentially disjunctive syllogism): it matches an unnegated predicate with a negated predicate in another rule.
For example, consider our rule prey(x), and the request for those animals which are prey:
which(x: prey(x))
How will Prolog operate? It seeks a rule with prey as an unnegated predicate (i.e. it is the consequent of an implication). It finds
Prolog then seeks unnegated E(y,x) or A(x) to collapse this argument using disjunctive syllogism. It finds, for example, that E(bear,fox). Using universal instantiation, Prolog reckons that
and combines the two to reduce the argument to
When Prolog encounters A(fox), it will resolve with that above to conclude
Alternatively, this can also be thought of as modus ponens: 
resolves to Pr(fox).
Example: watch the software SWI-Prolog resolve issues associated with Example 37/39, p. 63/64.
Example: Practice 28/29, p. 64/66
The reason that Prolog can prove theorems in this way is that the domain is finite: when you create the database, it is only possible to specify a finite collection of facts, which means that Prolog need only test a finite set of instances for truth.
Prolog offers us our first example of recursion, ``... in which the item being defined is itself part of the definition....'' While this is a very powerful and fascinating idea, it can go horribly awry in the form of infinite loops! We'll see some shortly.
Some rules are recursive in nature: for example, in problem #13, p. 68/70, we're asked to consider a Prolog database for parts of an automobile engine. Parts have been classified into big and small, and a rule exists which determines ``part-of''. Now we're to write a rule for ``component-of''. Since a screw may be a part of a filter, which is a part of the fuel system, we need a rule which can dig down into the structure of the parts to discover the true ``component-ness'' of a part within a part.
Consider the rule defined as two rules, as follows:
component-of(x,y) if part-of(x,y)
component-of(x,y) if part-of(x,z) and component-of(z,y)
The first definition gives us a base case: if x is a part of y, then it is certainly a component of y. On the other hand, the second definition allows us to determine that, since screw is a part of filter, and filter is a part of the fuel system, and fuel system is part of the engine, hence screw is a component of the engine.
Example: watch SWI-Prolog resolve in-food-chain(bear,X) (Example 38, p. 65/67).
Example: Practice 29/30, p. 66/68
Prolog uses a depth-first strategy for answering questions with recursion, rather than a breadth-first strategy. We'll explore both these search strategies later on in the course in greater detail.