Diagrammatic reasoning in logic programming - CiteSeerX

Diagrammatic reasoning in logic programming Hans van Ditmarsch University of Groningen Cognitive Science and Engineering / Computing Science Grote Kruisstraat 2/1 9712 TS Groningen the Netherlands [email protected] / [email protected]

Abstract A refutation tree is a standard two-dimensional representation of resolution derivations.

Given a logic program, a computation rule and a goal, dierent resolution derivations result from selecting dierent matching clauses in the program. These derivations can be visualized as separate branches in the refutation tree. This process can also be reversed: given an refutation tree where leaf nodes are labelled with either succeed (for the empty clause) or fail, and neither other nodes nor links are labeled, one can construct a program, a computation rule and a goal that match this abstract tree. Thus we can introduce in a visual way basic logic programming concepts such as resolution strategies and nite failure. This might facilitate learning logic programming and Prolog. We are actually using here the computational eciency for students of diagrams to represent logic programming proof concepts. Also, the concept of an abstract refutation tree (art) opens the quest for proof theoretic equivalents of visual features of those trees: what is the class of logic programs that share a particular tree; does a `good' Prolog program result in a particular tree shape; in nite trees for logic programs always have a recurring pattern and thus can be nitely represented.1

1 Introduction If ever there was a fortress safe from diagrammatic reasoning it was standard proof theory. Wrong! Formal proofs are visualized in various ways, often for expository purposes. These visualizations are diagrams that can be visually manipulated in ways corresponding to proof concepts. We study one particular formal proof system: resolution, and one standardly accepted visualization in that area: refutation trees. In section 2 we describe some common visualizations of refutations. In section 3 we de ne refutation trees and abstract refutation trees, and relate the two. In section 4 we will present some arguments for using refutation trees and abstract refutation trees (art) in teaching logic programming and Prolog, and relate our experiences in that matter. In section 5 we will discuss our proposed visualization in relation to diagrammatic reasoning, and confront some as yet unanswered questions. Section 6 concludes the paper. 1 The author thanks the following persons for their comments on previous versions of this manuscript or for their useful criticisms of the subject: Johan van Benthem, Gerard Renardel, Rix Groenboom, Erik Saaman, Marc Pauli, Rineke Verbrugge, Gertjan van Noord, Michael Moortgat.

1

2 Visualizing resolution As we are concerned with visualizing resolution proof concepts, we start with a short overview of the relevant terminology. Short, as we will assume the reader to be mostly familiar with it.

Resolution A clause is a sequence p1; :::; pn ( q1; :::; qm with p1; :::; pn; q1; :::; qm (predicate

logic) atoms. Reminiscent of the disjunctive notation p1 _ ::: _ pn _ :q1 _ ::: _ :qm of this clause, the p1 ; :::; pn are also called positive literals and the q1 ; :::; qm negative literals (literals are atoms or negations of atoms). From two clauses with complementary literals, subject to a uni cation, one can derive by resolution a new clause, called the resolvent. An example: from Father(x; y) ( Parent(x; y); Male(x) and ( Father(john; mary) we derive the resolvent ( Parent(john; mary); Male(john), subject to the uni cation [x=john; y=mary]. A sequence of resolution proof steps is a derivation. A derivation that ends in the empty clause2 is a successful derivation or refutation. Otherwise it is called a failed derivation. A failed derivation can be of nite and of in nite length. The set of derivations given an initial set of clauses is can be represented by a refutation tree or refutation graph (to be explained).

SLD resolution Clauses having exactly one positive literal (i.e. to the left of the sym-

bol () are program clauses. Clauses (non-empty) without positive literals are goals. If program clauses have no negative literals they are facts, otherwise rules. An example: Father(x; y) ( Parent(x; y); Male(x) is a rule; ( Parent(john; mary); Male(john) is a goal, consisting of 2 subgoals; Parent(john; mary) ( is a fact. A set of program clauses is a logic program. If the initial clause set consists of a logic program and a goal, and if the selection of subgoals for resolution is according to a certain procedure (called a computation rule), we have SLD resolution3 . In this case the refutation tree is called an SLD tree.

Prolog A further re nement is the procedural mechanism of Prolog. Now, the computation rule is `select rst subgoal'; further, we regard the logic program not as a set but as a sequence of program clauses, and we choose program clauses matching the goal by the procedure (search rule) `take rst matching clause' plus backtracking. Prolog query (goal) execution is depth- rst search in the sld tree. How are these proof theoretic constructs represented? Representation is an issue for:    

resolution step (single derivation step) derivation refutation tree (set of derivations) program execution (search in a set of derivations)

We will discuss them below. In the rest of this paper we will restrict ourselves to refutation trees.

Resolution step A basic way of representing a resolution step is by mathematical text.

An example:

From Father(x; y) ( Parent(x; y); Male(x) and ( Father(john; mary) one can derive by resolution, subject to uni cation [x=john; y=mary]: ( Parent(john; mary ); Male(john).

2 3

The empty clause can be represented in various ways: (, 2, fg, nil. We prefer (. for: Selecting a literal, using a Linear strategy, restricted to De nite clauses

2

Derivation A derivation may be represented by a longer text, and set of refutations by an even longer one. One step towards more visually structured information is a { onedimensional { annotated sequence of lines: a linear proof. We give an example. Given the logic program: Father(x;y) ( Parent(x;y); Male(x) i Parent(john; mary) ( ii Male(john) ( iii a proof (a refutation) in linear format that John is Mary's father, is:

1 ( Father(john; mary) 2 Father(x; y) ( Parent(x;y); Male(x) 3 ( Parent(john; mary);Male(john) 4 Parent(john; mary) ( 5 ( Male(john) 6 Male(john) ( 7 (

goal clause i resolution, 1, 2, [x=john; y=mary] clause ii resolution, 3, 4 clause iii resolution, 5, 6

A two-dimensional representation, a proof tree, is more ecient for representing proofs than a linear proof, because the resolvent does not refer to the two clauses it has been derived from, but is visually - and therefore more directly - linked to them. As an example the previous refutation in tree format: ⇐ Father(john, mary)

Father(x, y) ⇐ Parent(x, y), Male(x) [x/john, y/mary]

Parent(john, mary) ⇐

⇐ Parent(john, mary), Male(john) ⇐ Male(john)

Male(john) ⇐ ⇐

Figure 1: Resolution proof tree

Ad gure 1 A proof tree is called a visualization of proof for two reasons: (i) it is twodimensional and (ii) it mirrors abstract mathematical relations with visual symbols: the horizontal bar in gure 1 matches the ternary `resolution proof step'-relation: above the bar are the two clauses to be resolved, below the bar the resolvent. For similar examples, see ([24], 180). Visualization of (individual) formal proofs is a topic in itself, outside the scope of this paper.

Refutation tree The problem remains how to visualize the set of all derivations. Various (two-dimensional) visualizations have been in vogue in scienti c and educational texts on logic programming and Prolog. We discuss three of those by presenting their most typical proponents:   

Nilsson (see subsection 2.1) Apt (see subsection 2.2) Eisenstadt (see subsection 2.3)

Program execution Eisenstadt's aorta diagrams are, as we will see, somewhere in the

middle between a static representation of several derivations, as in a refutation tree, and a dynamic representation of (Prolog) program execution. Another dynamic feature of program execution is a (Prolog) program execution trace. The trace is a common one-dimensional 3

way of representing procedural information, originating in a proposal by L. Byrd, see [21] for a description and references. There is quite some variation among Prolog interpreters in trace facilities. An extensive study on the variety and use of trace facilities is [18]. We will not discuss the Prolog trace.

2.1 Nilsson

Our rst example is a refutation `tree' or more accurately: refutation graph, from Genesereth and Nilsson's Logical Foundations of Arti cial Intelligence ([14], 73). In gure 2 a clause is written as a set of positive or negative literals, instead of a disjunction. The empty clause, in the middle of the lower level, is denoted by fg. The ternary resolution step relation is not visualized by a horizontal bar, as in gure 1, but by two arcs linking a lower node with two higher level nodes. An initial set of four clauses is given on the upper level (0) of the tree. All possible Figure 2: Refutation graph resolvents appear at lower levels. This resolution graph contains one refutation. The corresponding proof is the subtree of this graph generated by the empty clause and the reverse of the resolution procedure. Do notice that we can extend the graph with yet another level, containing four more instances of the empty clause. This extended graph then represents the complete set of refutations given the initial clause set. It will be clear that using horizontal bars as in gure 1 we would have diculty visualizing more than one derivation, as in gure 2. Even gure 2 starts to become somewhat unreadable though, when extended with yet another level, as suggested above. A visual solution to this problem is the sld tree, that we will introduce next. Nilsson's visualization of resolution has not become widespread, apart from the textbooks [14] and [19].

2.2 Apt

Apt (e.g. [3], 850) originally introduced the sld tree, as a concise representation of all resolution derivations given a goal, a logic program and a computation rule. Figure 3 is an example ([1], 15). The corresponding program de nes a path as the re exive and transitive closure of an arc. Also an arc between two objects b and c is given: Path(x; z) ( Arc(x; y); Path(y;z) Path(x; x) ( Arc(b; c) (

1 2 3

The refutation tree computes the dierent paths from somewhere to c, i.e. resolves the goal ( Path(x; c). There are three dierent kinds of path: nite paths ending in the empty clause (2), that correspond to refutations, nite paths ending in a non-empty clause, that correspond to failed derivations (labeled `no descendant' in the gure), and in nite branches, that also correspond to failed derivations and visualize program loops. The resolution rule applies to a node and to the clause corresponding to the number label of a branch originating from that node, under the unifying substitution that is the other label of that branch, the resolvent being the daughter node along that branch. Subsequently (from top to bottom) matching clauses in the program do appear from left to right in the refutation tree. However, as a logic program is a set and not a sequence of clauses, the left-to-right order of the daughters of a node is informal. The two refutations compute the dierent solutions x = c and x = b. The computation rule is: select the last subgoal (in bold). 4

Figure 3: Sld tree Contrary to general resolution, as visualized in gure 2, in sld-resolution a goal and a program clause play a dierent role: the resolvent is always another goal or empty. This dierence has been visualized in the `Apt-style' representation by the distinction between nodes, which are goals, and labels on arcs, which are program clauses. Similar examples of refutation trees abound throughout the logic programming literature, e.g. ([16], 55-66), [13], ([22], 110{113).

2.3 Eisenstadt

Visualizing logic program execution has been an ongoing research eort at the British Open University since the 1980s. This resulted in the Transparent Prolog Machine (TPM), see [10] and [9], in which Prolog program execution can be visualized at various levels of detail. The most elaborate detail is called an aorta4 diagram. Figure 4 gives an example ([9], 298). Figure 4 has about every possible feature of an aorta diagram. We will not explain all of them in detail. The diagram depicts processing the question who's throwing a party, given that a party animal is either happy Figure 4: aorta diagram and having his birthday, or has a friend who is sad. And when the weather is hot and humid, a swim makes you happy. Also some facts are given. Suces that the goal nally succeeds (whence the tick-mark in the upper half of the box at the root of the tree) on the second clause of the party predicate (whence the number 2 in the lower half of that box, whence the small check mark in the right - second - handle below that box), instantiating tom for the variable Name (whence the lozenge inscribed tom). Cross means fail, `tick-cross' means fail on retry, the cloud and the scissors are to depict the procedural consequences of the cut (!) predicate (freezing older sisters, and 4

Aorta stands for and-or tree augmented

5

pruning aunts). The OU has also developed a higher level visualization of Prolog execution, called LDV (Long Distance View), which abstracts from the arguments of predicates. Both visualizations are very much tools for learning and practicing Prolog. Far from being just a concise way to visualize refutations, they intend to help programmers determine the next step in a resolution proof.5 An aorta diagram corresponds to a subtree of an sld tree resulting from depth- rst expansion of the root up to completion of a success branch (refutation). Dierent subgoals of a goal node in an sld tree are visualized as separate nodes in an aorta diagram. Therefore, an sld tree is an or tree, whereas an aorta diagram is an and-or tree. The left-to-right order of or branches in an aorta diagram precisely matches the top-to-bottom order of clauses in a Prolog program, contrary to a similar but informal order in sld trees. Separating subgoals over nodes has the advantage of transparency during Prolog program execution, but unfortunately calls for careful bookkeeping of variable bindings, as they now bind across sister nodes. We will refrain from an extensive discussion here.

2.4 Comparison

We have seen three dierent visualizations of a set of resolution derivations. Given are the logic (Prolog) program:

P (x) ( Q(x) Q(a) ( Q(b) (

i ii iii

and the goal ( P (x). The choice of computation rule is irrelevant here (one subgoal only). Two dierent refutations result. Figure 5 contains the three dierent visualizations of those two. Of course, we actually need two stages in aorta diagram construction, and a `forced' fail, in order to represent both refutations. ⇐ P(x) [x/x 1]

i

1

⇐ Q(x1) [x 1 /a]

p(X)

⇑

⇑

1

p(X1) a

~P(x)

P(x) ∨ ~Q(x)

p(X1) b

Q (a)

Q(b)

~Q(x1)

[x 1 /b] ii

⇐

p(X)

iii

⇑

⇐

⇑

q(X1) 1

NIL

NIL

q(X1)

⇑

2

q(a)

⇑ q(b)

Figure 5: computing P (x) A comparison between the three dierent visualizations seems unfair, as they serve dierent goals. Of course Nilsson's refutation graph is not as ecient a visualization for sld refutations as sld trees, that were especially invented for that purpose! On the other hand, sld trees are often used for the visualization of Prolog program execution, as are aorta 5 The British Open University course Intensive Prolog [11] uses aorta diagrams as a didactic tool. The author co-authored the adaptation of that course for the Open university of the Netherlands, see [25].

6

diagrams. So a comparison is de nitely in place there. We prefer `Apt-style' visualization because: 

 

more than the alternatives, it is t for simultaneous representation of many derivations (Nilsson's refutation trees quickly become overloaded with links because of program clauses being nodes; aorta diagrams are not t to represent several successful refutations at the same time: refutations are dynamically generated (see gure ??); contrary to aorta diagrams, it is easy to interpret because it visualizes only one structural feature of resolution; contrary to aorta diagrams, computations (i.e. uni cations) are propagate upwards and thus can be read o a single branch.

Other arguments relevant for comparison relate to teaching. See section 4. The second and third reason suggest that diagrammatic reasoning with sld trees is more ecient than with aorta diagrams. This will be discussed in section 5.

3 Abstract refutation trees We de ne refutation trees in `Apt-style', with minor modi cations. Further, in this section we introduce a new visualization, called `abstract refutation tree' (art). We assume `derivation' and `computation rule' to be de ned (see section 2).

3.1 Refutation trees

De nition 1 (Refutation tree)

The refutation tree for a logic program  and a goal ( G via computation rule R is the following tree constructed from all derivations of  [ f( Gg via R:  the root of the tree is labeled ( G  every node labeled ( G1 ; :::; Gn with selected atom Gi has exactly one daughter node (below it) for every clause C whose head uni es with Gi . The daughter node is labeled with the resolvent of C and Gi . The arc from the node to that daughter is labeled with (a reference to) the most general uni er of C and Gi , and with (a reference to) C  the top-to-bottom order of the clauses in the logic program matches the left-to-right order of the daughters of a node. Order Dierent from Apt's de nition of sld trees is, that we specify some visual requirements of the resulting tree, and that we assume the clauses in a logic program (sequentially) ordered. There is a reason for that assumption. The horizontal order in the refutation tree has no formal meaning if a logic program is regarded as a set. In our case however it matches the sequential order in the program. A logic program remains `set-like' in that we do not allow duplicates of clauses. We will need this restriction later. Further, because we regard a logic program as a sequence, the de nition of refutation tree is directly applicable to Prolog programs. We could have de ned refution trees more declaratively as the result of identifying starting sequences of all derivations given a goal, a logic program and a computation rule. Observe that (parts of) derivations are considered identical if they only dier in variable names other than in the goal. Applying this de nition to the program: 7

Plus(0; x; x) ( Plus(Sx; y; Sz ) ( Plus(x; y; z )

i ii

specifying addition, to the goal (query) ( Plus(x; y; SS 0) corresponding to the addition x + y = 2, and via the computation rule `select rst subgoal' we get gure 6. ⇐ Plus(x, y, SS0) [x/0, x1/SS0, y/SS0]

[x/Sx1, y/y1, z1/S0]

i

ii

⇐

⇐ Plus(x1, y1, S0) [x1/0, x2/S0, y1/S0]

[x1/Sx2, y1/y2, z2/0] i

ii

⇐

⇐ Plus(x2, y2, 0) [x2/0, x3/0, y2/0]

i

⇐

Figure 6: Refutation tree computing x + y = 2 This example will by now need no further explanation. The notation is as in gure 1 and the corresponding derivation (page 3). In the refutation tree, we prefer to use a reference to a clause (`i', `ii') instead of the clause itself.6

3.2 Abstract refutation trees

An abstract refutation tree, art, is a refutation tree without arc and node labels, except for the leaf node labels. The leaf node labels are replaced with succeed or fail, to point out their role in derivations. So `abstract' means `containing less information'. A branch terminating in succeed corresponds to a refutation. A branch terminating in fail and an in nite branch correspond to a failed derivations. By deleting most arc and node labels, the tree no longer corresponds to a goal, a program and a computation rule. Thus we cannot de ne art procedurally, relative to those logic programming concepts.

De nition 2 (Abstract refutation tree) An abstract refutation tree, or art, is a nitely branching, rooted, ordered tree with branches of nite or in nite length and fail or succeed leaves. As the empty clause is not a goal, the one-node tree labeled succeed does not correspond to a refutation tree and therefore must be (hereby) excepted from the de nition of art. Procedure 1 (Refutation tree to art)    

remove the labels of the non-terminal nodes (i.e. replace all node labels by dots: ) replace the labels of the non empty-clause leaves by fail replace the labels of the empty-clause leaves by succeed remove the labels of the arcs

We can reconstruct the matching clause from a goal, the uni cation and the resolvent. So we do not even need to know the referent! 6

8

Figure 7 is the art corresponding to gure 6. • •

SUCCEED

SUCCEED

• SUCCEED

Figure 7: Art from computing x + y = 2 In nite subtrees of art always have a recurring pattern, because they correspond to looping recursive calls on program clauses, and because we have abstracted from the structure of the current goal. The current goal possibly consists of more subgoals at a next call.

3.3 Art to refutation trees

Naturally, many refutation trees have the same art. Can we reverse this procedure, in other words: can we construct a program and goal and a computation rule corresponding to a given art? For nite trees this turns out to be rather trivial, though quite instructive. Figure 8 gives some examples. Without loss of generality, we can assume the Prolog computation rule `choose leftmost subgoal'. Further, if possible we construct a propositional program, in order to avoid the complication of uni cation.

•

•

SUCCEED

FAIL

• SUCCEED

•

SUCCEED

•

Figure 8: Examples of art

The left tree Assume a goal ( p. We are supposed to derive the empty clause from this goal in one resolution step. So we need a fact p ( in the program to match the goal. As we also are supposed to derive only the empty clause, this is therefore the only clause the program consists of. The middle tree We proceed analogously, assuming a goal consisting of the single rule p ( q.

(

p, and derive a program

The right tree Trying to proceed from the experience gained in the previous examples, we again assume a goal ( p. The only way to derive the empty clause twice, is by repeating fact p ( in the corresponding program. Duplication of clauses is ruled out (see page 7), as it does not make sense for a logic program. So we essentially need to use some variable in our goal. Therefore, change the goal to ( P (x). Introduce two (and just two) facts P (a) ( and P (b) (. In order to model the in nite branch, we need a nonterminating recursive call. Adding P (x) ( P (x) does not work, because the branching of the root is not repeated on the next level. Instead, the following logic program does the job:

P (a) ( P (x) ( Q(x) Q(x) ( Q(x) P (b) ( 9

A simple procedure emerges to label an art, and thus reconstruct a corresponding program and a goal: start with a goal consisting of a single subgoal, preferably propositional, and add facts or rules to the program as needed. Art nodes expanding into more than one empty-clause leaf can only be matched with programs containing variables. New clauses should contain fresh predicates or propositions. For in nite branches we have to make an identi cation `somewhere'. The procedure for nite arts:

Procedure 2 (Art to refutation tree) 1. assign the value ( P1 (x) to the root of the tree and set the queue of goals to [( P1 (x)]; 2. for all goals in the queue do the following (assume a current goal ( Pi (x) that labels a current node): 3. if the current goal labels a terminal node do nothing (i.e.: proceed to the next goal in the queue of goals); 4. else for all the children of the current node, from left to right: 5. if the child is succeed, replace that child by the empty clause ( and add a fact Pi (aj ) ( to the program for a constant aj not yet appearing in the program, and label the connecting arc with that fact and with uni cation [x=ai ] 6. else add a rule Pi (x) ( Pj (x) to the program for a predicate Pj not yet appearing in the program, label the connecting arc with that rule and with the empty uni cation id, label the child node with ( Pj (x), and paste ( Pj (x) to the queue of goals. As ( is no goal and thus the one-node tree labeled succeed no art, in step 1 we can safely assume a goal ( P1 (x). Instead of labeling arcs with clauses, in steps 5 and 6 of the procedure, we could could have labeled them as well with reference markers and added the referent clause with that reference to the program instead. We continue to use references instead of clauses in refutation trees. If we end up with just one constant aj per introduced predicate Pi in the resulting refution tree, we might as well replace occurrences of Pi (aj ) throughout the refutation tree and the program (i.e. occurrences in goals as well as clauses) by propositions pi , and remove the corresponding uni cations. Figure 9 gives an example. We apply the procedure to the abstract refutation tree resulting from the x + y = 2 query ( gure 6). The resulting program is: p1 (, p1 ( p2 , p2 (, p2 ( p3 , p3 (. The clause order corresponds to the arc labels.

⇐ p1 ii

i

⇐

⇐ p2 iii

⇐

iv

⇐ p3 v

⇐

The procedure does not handle in nite art in a proper way, because it constructs in nite programs from them. It has to be extended in order to handle that. Arts corresponding to actual refutation trees aren't just in nite but always contain recurrent nite patterns. The extended procedure should be based on those patterns, and thus construct nite programs.

Figure 9: Procedural art Further, the challenge is not to construct just any program, but an as simple as possible program, preferably because it's purely propositional and/or having recursive calls. The current procedure does not nd simple programs. Notice that the original addition program is simpler than the program corresponding to gure 9). 10

Of course the reconstructed programs are all nonsensical programs. One might ask indeed what sense it makes to construct them. Making programs from arts helps learning logic programming concepts, as will be explained in the next section.

4 Refutation trees in teaching The presentation in this paper is topdown: starting with a comparison of diagrams in logic programming, we confront the reader with our own variety, and now nally come to discuss its use in teaching and its formal diagrammatic aspects. In reality, we `invented' arts while teaching logic programming, partly based on dissatisfaction with aorta diagrams. Only recently we started to wonder whether they really help and what their formal properties are. Using art helps learning logic programming concepts, because:  

art training helps interpreting refutation trees;

refutation trees are useful for understanding logic programming concepts.

Art training helps interpreting refutation trees A logic programming student is likely to know standard proof formats, learnt in previous courses. Therefore, how to understand the notation for a single resolution derivation will present no problem. A refutation tree however, used to represent a set of proofs, is a more complex visualization and also a new visualization (even though we may assume trees in general to be familiar). This representation must therefore be learnt. There are two ways to approach learning the interpretation of a visualization: to visualize a given interpretation (1), or to interpret a given visualization (2). For refutation trees (1) is standard. We suggest that it might be worthwhile to use (2) as well, and that art might help there. See also the next section.

Understanding logic programming concepts Even if art helps the students to inter-

pret refutation trees, it remains to be seen whether refutation trees help to understand logic programming concepts. We suggest they do, because:  



compared to the set of refutations a refutation tree is an ecient representation A refutation tree is an ecient representation, as dierent branches share formulas and proof steps of dierent proofs. some understanding is visually oriented That some understanding is visually oriented, as opposed to language (`sententially') oriented, is a well-known fact in mathematics education, and for logical reasoning in particular has e.g. been investigated in [23].

exibly changing between dierent representations is conducive to understanding The use of dierent representations in teaching is related to educational research on viewpoints (see [17] for an overview) but also more generally related to the issue of heterogeneous representations and reasoning (see [5]).

We may summarize these arguments by saying that refutations are diagrams, that eciently visualize formal concepts. Students either use them directly, in order to understand logic programming concepts, or perform visual manipulations on them that can be reinterpreted as proof steps or program reconstruction. This will be investigated in the next section.

11

5 Diagrammatic reasoning in logic programming We tend to distinguish between heterogeneous representation, heterogeneous reasoning, and diagrammatic reasoning in the following way. Heterogeneous representation is about the combination of various representational formalisms in one representation. An example is combining text and graphics in topographical maps. Heterogeneous or multimodal reasoning is about using dierent representations, or `modes', not necessarily combined, in reasoning. An example is road planning by using a map and a distance table. Diagrammatic reasoning is reasoning in a visual formalism. An example is interpreting a mirror image. All three are intricately joined. If one of the heterogeneous reasoning modes is visual, we call it diagrammatic reasoning. A refutation trees is a heterogeneous representation. When we use refutation trees together with corresponding programs and program traces in order to answer program queries, this is an example of heterogeneous reasoning. Visual manipulations on refutation trees, and interpreting their counterparts in formal resolution proofs, is more purely diagrammatic reasoning. Logic program a⇐b a⇐c b⇐d c⇐

i ii iii iv

⇐ a i

ii

⇐b

⇐c iv

iii

⇐d Goal

Heterogeneous representation

Refutation tree

⇐

Computation rule

⇐ a

Refutation

Prolog execution trace ?- trace, a. CALL a CALL b CALL d FAIL d RETRY b FAIL b RETRY a CALL c EXIT c EXIT a

1 2 3 4 5

⇐a a⇐c ⇐c c⇐ ⇐

goal ii resolution, 1, 2 iv resolution, 3, 4

Herbrand model

YES; ?-

TΠ↑1

TΠ↑2 TΠ↑ω

Logic c, c → a

a

c

a

Figure 10: Heterogeneous reasoning

A refutation tree is a heterogeneous representation combining textual goals with visual features that represent abstract mathematical relations. In terms of Hammer ([15], 10{11), it is an example of a diagram with an isomorphy between an arc and the derivability relation, between `left-toright' and the sequential order of a logic program, etc. Of the generally distinguished four dierent attribute types in two-dimensional visualizations (for general features of data visualization see [8], [12]), a refutation tree has nominal as well as ordinal attributes: reference labels refer nominally to clauses in logic programs, whereas the `left-toright'-order in trees re ects the sequential order in logic programs. A formalization of the refutation tree visualization in terms of visual grammar seems (partially) super uous, as it is (partially) a visualization of formal proof and therefore needs no additional rigor or description, apart from an interpretation.

Heterogeneous reasoning in logic programming

An example of heterogeneous reasoning in logic programming, is to combine programs with refutation trees or other logic programming constructs, in order to compute answer substitutions. To make students understand resolution, uni cation and backtracking, we consider it helpful to switch back and forth between predicate logic, programs, program execution traces, refutation trees and art, as gure 10 illustrates. We do not present a formal analysis of this interaction here. A side-issue in this paper, is whether this kind of switching enhances or inhibits learning. We present some prima facie arguments in favour of enhancement, without having any experimental support for the logic programming case apart from some (as yet) uncontrolled classroom experiences: { That graphical as well as sentential understanding plays a part in teaching logic, and that 12

exibly changing between graphical abstractions on dierent levels is conducive to understanding, has been demonstrated for the Hyperproof case by Stenning's group at HCRC Edinburgh (see e.g. [23] and [20]). { In a less clear way the issue of heterogeneous reasoning is related to the viewpoint discussion taking place among educationalists, see the several viewpoint discussions in Moyse's Knowledge Negotiation [17].

Criticism of AORTA diagrams from a heterogeneous reasoning viewpoint

One dierence between the use of abstract refutation trees in logic programming (and Prolog) and the much more elaborate use of aorta diagrams seems somewhat in contradiction with presentations in the viewpoints discussion. It is the author's opinion that the combination of art and refutation trees and programs etc. as summarily depicted in gure 10 is opposed to the use of aorta diagrams, where most information available is compressed into one representation, i.e. one viewpoint. Although an aorta diagram as opposed to an LDV diagram (see section 3) can also be interpreted as a dierent viewpoint, this way of distinguishing viewpoints by abstraction level seems less interesting for heterogeneous reasoning than the viewpoints resulting from more functional decompositions: execution viewpoint (trace), database viewpoint (program), logical proof viewpoint (refutation tree), etc. Of course, a long-term many-person eort as the Transparent Prolog Machine does not compare to the simple proposal of a dierent use of sld trees in section 3. Still, considering that aorta diagrams have not seen the widespread attention of e.g. Prolog program traces, the author wonders whether this is not partly because TPM attempts to put all information at the same time in one representation, the alternative being to use dierent (simpler but more intelligible) representations simultaneously.

5.1 Aspects of diagrammatic reasoning on refutation trees

Finally, we pay some attention to visual manipulations on refutation trees that are parallelled by procedural aspects of resolution: 

mirror image



pruning



If we reverse the order of the clauses in the program, we get the (vertical) mirror image of the refutation tree.

For logic programming in general, pruning is an issue for special loop-detection techniques, such as strati cation. For executable logic programming languages, such as Prolog, pruning plays an essential role in visualizing the eects of the cut (!) operator. In section 3 we have summarily described its eect on aorta diagrams: as pruning older sisters and future aunts. In refutation trees the visual eect of a cut is not entirely satisfactory, see ([21], 123) and ([9], 298{300): it consists of pruning all descendants except younger sisters of the (fore)father of the cut's original conception. Nevertheless, inspired visualization of pruning refutation trees can be found in [13]: Flach's use of shading for pruning corresponds to the use of clouds in aorta diagrams. An alternative for representing cuts in sld trees, dierent from Flach, can be found in [7]: Bezem translates a cut-goal into an arc label instead of into a subgoal of a goal, i.e. a node label.

dierent tree

A dierent computation rule (selection rule) creates an essentially dierently shaped refutation tree. A classic and exciting example is ([1], 15). (An unessential dierence is swapping a node's children, such as the mirror image. Unordered trees are indistinguishable under this operation, and logic programs `essentially' correspond to unordered trees, see before.) 13



depth- rst tree search



all leaves labeled FAIL



The search rule of Prolog amounts to depth- rst search with backtracking in a goal's refutation tree. For dierent search rules sometimes dierent visual parallels can be formulated: or-parallel logic programming corresponds to breadth- rst search, preferring facts over rules corresponds to checking leaves rst, etc. A tree with all branches nite and failing corresponds to a failed goal ( nite failure). Negation in Prolog corresponds to a nitely failed tree for a (successfully negated) goal.

in nite branch

A loop in the program's execution corresponds to an in nite branch. Because a logic program is nite, all in nite subtrees consist of recurring patterns (given identi cation of goals by renaming of non-root variables, and given similar subgoal sequences in the next occurrence of a pattern).



single branch tree



foliage

A tree consisting of a single successful branch parallels an ecient (and deterministic) program and/or a precise question (query). A tree with all empty leaves on the left side corresponds to facts preceding rules in the program (as is not uncommon in Prolog).

Apart from these diagrammatic aspects of refutation trees, the introduction of arts introduces new questions about diagrams in logic programming:   

What is an ecient visual representation of in nite trees containing recurring patterns? How does a recurring pattern relate to program structure in general? How `alike' are programs having the same art? Is an equivalence class of programs sharing the same art a fruitful concept?

For the moment, we leave these questions unanswered.

6 Conclusions and plans We have studied the use of refutation trees in logic programming from a viewpoint of diagrammatic reasoning. Also, we have introduced a new use of refutation trees in teaching logic programming: reconstructing programs and goals from abstract refutation trees, art. An abstract refutation tree is a refutation tree with all the labels of nodes and arcs removed, except when the leaves are empty nodes, when they are replaced by succeed, or not-empty, when they are replaced by fail. Several logic programming concepts do have visual counterparts in refutation trees. Arts present some new questions about refutation trees as diagrams. Ordinary as well as abstract refutation trees compare favourably to Eisenstadt's aorta diagrams from a heterogeneous reasoning point of view.

Plans A program translating Prolog programs to refutation trees and vice versa, and ditto for art, will be developed. A study guide in English introducing logic programming concepts by way of refutation trees and arts, as an add-on to a logic programming course at the University of Groningen, will be further developed. Also `slide shows' for particular examples will be developed. A web-accessible tool for students to construct programs and refutations trees is a further goal, presently too ambitious.

14

References

[1] K.R. Apt, Introduction to logic programming (revised and extended version). Report CS-R8826. Centre for Mathematics and Computer Science, Amsterdam 1988. [2] K.R. Apt, From Logic Programming to Prolog. Prentice Hall, London 1997. [3] K.R. Apt & M.H. van Emden, Contributions to the Theory of Logic Programming. In: Journal of the ACM (29) no. 3, 841 { 862. 1982. [4] D. Barker-Plummer & M. Greaves, Architectures for heterogeneous reasoning on interlinguae. CSLI, unpublished manuscript. [5] J. Barwise & J. Etchemendy, Heterogeneous Logic, in: J. Glasgow (et al.), Diagrammatic Reasoning. MIT press, Cambridge Mass. 1995. [6] J.F.A.K. van Benthem, H.P. van Ditmarsch, J. Ketting & W. Meyer-Viol, Logic for computer science (Logica voor informatici), 2nd edition. Addison-Wesley 1993. [7] M. Bezem, Logic programming and Prolog. CWI Quarterly 1 (3). Centre for Mathematics and Computer Science, Amsterdam 1988. [8] M. Dastani, An Algebraic Approach to Data Visualization. In: J. Engelfriet & T. Spaan, Proceedings of Accoladef96, 53{64. Dutch Graduate School in Logic, 1996. [9] M. Eisenstadt & M. Brayshaw, The Transparent Prolog Machine (TPM): an execution model and graphical debugger for logic programming. In: Journal of Logic Programming (5) 277{342. Elsevier 1988. [10] M. Eisenstadt & M. Brayshaw & J. Paine, The Transparent Prolog Machine: visualizing logic programs. Intellect, Oxford 1991. [11] M. Eisenstadt (et al.), Intensive Prolog. The Open University Press. Milton Keynes 1988. [12] Y. Engelhardt, Towards a design theory for visualization. In: J. Engelfriet & T. Spaan, Proceedings of Accoladef96, 65{77. Dutch Graduate School in Logic, 1996. [13] P. Flach, Simply Logical. Wiley, Chichester 1994. [14] M.R. Genesereth & N.J. Nilsson, Logical Foundations of Arti cial Intelligence. Morgan Kaufmann, Los Altos Cal. 1987. [15] E.M. Hammer, Logic and Visual Information. CSLI/FoLLI 1995. [16] J.W. Lloyd, Foundations of Logic Programming, 2nd edition. Springer, Berlin 1987. [17] R. Moyse & M.T. Elsom-Cook, Knowledge Negotiation. Academic Press, London 1992. [18] P. Mulholland, A framework for describing and evaluating software visualization systems: a case-study in Prolog, PhD thesis. Open University, Milton Keynes 1995. [19] N.J. Nilsson, Principles of Arti cial Intelligence. Morgan Kaufmann, Los Altos CA 1980. [20] J. Oberlander (et al.), Individual dierences in proof structures following multimodal teaching. HCRC Edinburgh 1996. [21] H. Pain & A. Bundy, What stories should we tell novice Prolog programmers? In: R. Hawley (ed.), Arti cial intelligence programming environments 119{130. Ellis Horwood, Chichester 1987. [22] L. Sterling & E. Shapiro, The Art of Prolog, 2nd edition. MIT Press, Cambridge Mass. 1994. [23] K. Stenning & R. Cox & J. Oberlander, Contrasting the cognitive eects of graphical and sentential logic teaching: reasoning, representation and individual dierences. In: Language and cognitive processes (10) 333{354. 1995. [24] A.S. Troelstra & H. Schwichtenberg, Basic Proof Theory. CUP, Cambridge 1996. [25] F.J. Wester (et al.), Study guide Logic programming. Open university of the Netherlands. Heerlen, 1993.

15