Presentation of Classical Propositional Tableaux on Program Design - - PDF document

Presentation of Classical Propositional Tableaux

• n Program Design Premises∗

Juan Michelini and Álvaro Tasistro

Universidad ORT Uruguay michelini@ort.edu.uy, tasistro@ort.edu.uy

Abstract

We propose a presentation of classical propositional tableaux elaborated by application of some principles that are noteworthy in program design, namely program derivation with separation

• f concerns. We start by deriving from a straightforward specification an algorithm given as a

set of recursive equations for computing all models of a finite set of formulae. Thereafter we discuss the employment of data structures, mainly with regard to a manual execution of the

• algorithm. A requirement of natural traceability and verification leads us to the trees of sets
• f formulae presented in [Hintikka?] and [Ben-Ari], the correctness of which is immediate after

their derivation as traces of the employment of the original equations. A further improvement avoids repetition of unmodified formulae giving rise to the trees presented in [Smullyan], whose correctness is in turn guaranteed by showing that they carry the same information as the former

• trees. The whole development strives at avoiding gaps, both of logical and motivational nature.

1 Introduction

The context in which this work presents itself is as follows. We are in the course of developing an approach based on Functional Programming to teaching Mathematics and Programming from scratch. Such approach founds itself primarily on the construction of the mathematical

• bjects within the conceptual and notational framework of a core of the programming lan-

guage Haskell1. As usual in Mathematics, we consider properties and relations defined on such objects and then proceed to the illative development leading to the results of interest, all of which is accomplished in natural language2 enhanced by further convenient notation. As we see it, the approach serves the following educational purposes: To begin with, it provides a way for learning Programming in which programs are encountered from the beginning as subjects of mathematical definitions and scrutiny, which is to our mind a funda- mental and most usually neglected conception thereof 3. On the other hand, it proposes the study of Mathematics as based on types and functions. Besides introducing an alternative interesting in itself, this prompts teachers and students to develop a fresh approach to the most fundamental mathematical mechanisms which is generally quite useful and illuminat- ing —for all of them. As a third consequence, the mathematical results and methods are, if not directly so, readily conceived as opportunities for the development of interesting pieces

• f software.

∗ This work was partially supported by ANII–Agencia Nacional de Investigación e Innovación, Uruguay. 1 Specifically, a λ-calculus with a system of simple types in Curry’s style plus inductive definitions, i.e.

types defined by enumeration of their constructors. We refer to this language as λh when convenient.

2 I.e. Spanish in our case. Specifically, we do not use a formal system like e.g. Constructive Type Theory

for considering such option far too demanding for novice students.

3 It also conducts to introducing Programming via the principles and techniques of the functional

• paradigm. We do claim that this too is a feature of our method, but the corresponding discussion

is far beyond the scope of this paper.

licensed under Creative Commons License CC-BY Leibniz International Proceedings in Informatics Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl Publishing, Germany

2 Presentation of Classical Propositional Tableaux on Program Design Premises We have put the preceding ideas in practice within a Software Engineering programme

• f studies.

We begin with a course called Foundations of Computing, which introduces polymorphic, higher-order functions, and inductive types with the fundamental methods of induction and recursion in their various forms. Subsequent to Foundations of Computing there is Logic for Computing, which concerns itself essentially with the notion of formal proof —while keeping up with the general approach to Programming and Mathematics set out at the beginning. The consideration of formal proof and of formal languages of Logic serves several purposes: Firstly, it strives to further enhance the mathematical skills of the students not only by continued practice but also through theoretical reflection. Specifically, this reflection leads to the design of artificial, formal languages intended to model the natural or spontaneous mathematical practice, which provide a first bench on which to start studying issues related to formal language treatment. Prominent among these are the design of the language of First-Order Logic for capturing mathematical propositions as well as of any of the formal systems of deduction for capturing mathematical proof. On the purely syntactic side, this problem leads to considering phenomena such as name binding and the existence of multiple syntactic categories. On the semantic side, there is e.g. the fundamental question of the correctness (i.e. soundness and completeness) of the formal systems of proof. Further, there is the problem of syntactic verification and manipulation and, specifically concerning the formal systems of proof, the ultimate question is whether proofs can be developed automatically. In the case of Propositional Logic, several complete solutions to this can be studied and implemented, whereas at least a first insight can be conveyed of the undecidability of the question for First-Order Logic, which subsequently leads to the possibility of experimenting with semi-automatic methods. A further outcome

• f studying Formal Logic is that it allows to introduce, and experiment at least a glimpse
• f the ideas of programming logic, verifying compiler and generally of formal method of

software construction. We insist on the practical usefulness of the language of First-Order Logic as a specification language, not only in the context of formal methods but generally in system modeling. It follows from the foregoing that we should be very much interested in making explicit methods of proof. By this we mean both general strategies for developing and fully under- standing solutions to problems, as well as manners of presenting the corresponding proofs which convey natural, concise and complete justifications of their design. Now, as it turns

• ut, we have observed that some methods that have arisen within what could be called the

science of Programming can be employed for obtaining or conveniently presenting mathem- atical results. This is to our mind a fact to be most welcome, for it exposes a unity of method between Programming and Mathematics that cannot but bring about positive outcomes for both sides, at least in as much the learning and teaching aspects are concerned. In this paper we present an example of the latter, concerning the presentation of the method of tableaux. This is a proof procedure for both propositional and predicate logic dating back to [?] and [?], and whose ultimate variant (termed analytic tableaux) has been introduced in [?]. It is primarily presented as directed towards deriving logically valid formulae of the language in question, but it can more generally be used to establish that given sets of formulae are unsatisfiable. Indeed, in the particular case in which such set consists of only one formula, the opposite to this is derived as logically valid. We shall presently develop the method for the propositional case. Specifically, what we do is:

• 1. We derive the method as a set of equations —to be used as rewriting rules— from a

straightforward specification, namely the one demanding the computation of the set of all models of the given set of formulas.

• J. Michelini and Á. Tasistro

3

• 2. We discuss the design of data structures for actually effecting and keeping trace of the

execution of the method, which leads to the sorts of trees that are called “the tableaux" in textbooks. The first part yields a compact proof of the correctness of the method. The proof is much simpler than the usual ones in textbooks and, specifically, it builds upon the purpose to compute all the models of the given set of formulas, which is a property of the method seldom pointed out despite being quite noticeable as soon as one understands how the method works. The second part introduces the convenient and classical notation as one device for actually using the method. Thus the correctness of the notation is a result that relates it to the set of equations originally given, and is proven by an inductive argument. As a whole, the process is one in which we repeatedly employ simple techniques of program derivation and separation of concerns to obtain a presentation and justification both modular and simpler

• f the method of tableaux.

The rest of the paper consists of just two sections !!CAMBIAR: In the next one we expose the presentation in question, after which we finish up with a general discussion. The presentation is to be read basically as a course handout, although sometimes it becomes too concise (e.g. exercises are missing) and sometimes too extended (e.g. by making explicit considerations of logical or didactic nature). We freely use set theory in this presentation, essentially for reasons of space. The basic definitions can be implemented in λh (type theory) in a manner to be discussed elsewhere.

2 Background

• Syntax. It is enough to consider the set of connectives {¬ , ∧}. Then the set of formulæ is

defined as usual, starting out from a denumerable set V of propositional letters p: α, β ::= p | ¬α | α ∧ β. We use signed formulae σ ::= Sα where S ::= F | T, as the forms of assertion or judgement4.

• Semantics. Interpretations belong in I= V → Bool. The semantic value of each formula

is defined as follows — let A be the set of formulae and (!) and (&&) denote respectively Boolean negation and conjunction: [ [_] ]_ :: A → I → Bool [ [p] ]i = i p [ [¬α] ]i = ! [ [α] ]i [ [α ∧ β] ]i = [ [α] ]i && [ [β] ]i . Using the former we now define validity of an assertion (signed formula) in an interpret-

• ation. Call ˆ

S the boolean value corresponding to sign S. Then i | = Sα ≡ [ [α] ]i = ˆ S, which reads: i is a model of Sα, and also: i satisfies S α or S α is valid in i. We shall consider finite sets Γ of signed formulae and define models thereof (i.e. i | = Γ) as the interpretations satisfying every formula of Γ. Validity check. It is generally interesting to develop a method for checking validity of signed formulae. If we start with the propositional letters, we get: i | = Sp ≡ (model of signed formula) [ [p] ]i = ˆ S ≡ (semantic function) i p = ˆ S.

4 I.e. we take the view that classical logic is about both affirming and denying propositions, on equal

footing.

4 Presentation of Classical Propositional Tableaux on Program Design Premises For the other cases we wish to obtain (structurally) recursive equations. As to negation, writing S the sign opposite to S, we obtain: i | = S(¬α) ≡ (model of signed formula) [ [¬α] ]i = ˆ S ≡ (semantic function) ! [ [α] ]i = ˆ S ≡ (negating both sides to isolate [

[α] ]i)

[ [α] ]i =! ˆ S ≡ (opposite sign) [ [α] ]i = ˆ S ≡ (model of signed formula) i | = S α. Finally, turning to conjunction: i | = S(α ∧ β) ≡ (model of signed formula) [ [α ∧ β] ]i = ˆ S ≡ (semantic function) [ [α] ]i && [ [β] ]i = ˆ S, where we seem to get stuck. Indeed, to rewrite the left hand side requires to consider the definition of (&&) and this is not uniform with respect to truth and falsity. Therefore we are led to try instead distinguishing the cases of S: Case T: i | = T(α ∧ β) ≡ (calculation above) [ [α] ]i && [ [β] ]i = True ≡ (definition of &&) [ [α] ]i= True ∧5 [ [β] ]i = True ≡ (satisfaction) i | = T α ∧ i | = T β. Case F: i | = F(α ∧ β) ≡ (calculation above) [ [α] ]i && [ [β] ]i = False ≡ (property of &&) [ [α] ]i= False ∨ [ [β] ]i = False ≡ (satisfaction) i | = F α ∨ i | = F β. Ultimately, we arrive at the following characterisation of the satisfaction relation: Signed letter : i | = Sp ≡ i p = ˆ S Signed negation : i | = S (¬α) ≡ i | = S α True conjunction : i | = T(α ∧ β) ≡ i | = Tα ∧ i | = Tβ False conjunction : i | = F(α ∧ β) ≡ i | = Fα ∨ i | = Fβ.

3 The Set of All Models

We now set ourselves the problem of computing all models of any given finite set of signed

• formulae. This is accomplished by the function

M :: Pfin(Σ) → P(I) M(Γ) = {i ∈ I | i | = Γ}, where Σ is the set of signed formulae, P is the power set operator yielding the set of subsets of given set, and Pfin does the latter for the finite subsets6. Now this straightforward definition presents the inconvenience that, as a method of computation, it obliges to construct all the interpretations and check each of them against the formulae in Γ. We are rather in the

5 We overload ∧ across object and meta-language, which shouldn’t bring about any problem. 6 Our use of “computing” seems at first generous indeed, since we are setting ourselves to generating

in general infinite sets of infinite objects. Consider for that matter the case Γ = {p}. Then any interpretation assigning True to p is a member of the answer set. We shall see later how to settle this issue in detail —the general idea is to give a finite sufficient characterisation of infinite sets of interpretations.

• J. Michelini and Á. Tasistro

5 search of a syntactic procedure, i.e. one that applied exclusively to the formulae in Γ ends up arriving at the desired set of models. Let us then examine Γ. First of all, Γ could be empty, which is indeed a plainly uninteresting case. Indeed, every interpretation trivially satisfies the empty set of formulae and so the result in such case is

• I. So let us assume Γ = ∅. If this is the case, then we can pick any one of the formulae σ

in Γ and write the latter in the form ∆|σ, which means that Γ = ∆ ∪ σ and σ ∈ ∆7. Given the former, we can now write: M(Γ) = (split Γ) M (∆|σ) = (definition of M) {i ∈ I | i | = ∆|σ} = (satisfaction of a set of formulae) {i ∈ I | i | = ∆ ∧ i | = σ}. The only source of information in the latter expression is the analysis of the form of σ, and so we are led to an examination of cases, i.e. to considering: M (∆|S p) = {i ∈ I | i | = ∆ ∧ i | = S p}. M (∆|S (¬α)) = {i ∈ I | i | = ∆ ∧ i | = S (¬α)}, M (∆|S (α ∧ β)) = {i ∈ I | i | = ∆ ∧ i | = S (α ∧ β)}. We can make profit of this analysis by using the results obtained at the end of the preceding section for checking the validity of signed formulae in given interpretation. As it happens, the first case is a bit discouranging, for the satisfiability condition i | = S p takes us to consider the value of p in the given interpretation, i.e. a semantic rather than a syntactic

• move. But it pays off to insist. Negation gives the following:

M (∆|S (¬α))= (inferred above) {i ∈ I | i | = ∆ ∧ i | = S (¬α)}= (satisfaction of signed negation) {i ∈ I | i | = ∆ ∧ i | = S α}= (satisfaction of a set of formulae) {i ∈ I | i | = ∆, S α}= (definition of M) M (∆, S α), where we have used (, ) instead of (∪) for set union. Notice that it is indeed this operation and not the formerly used split (|) which is to be employed in this case, for we do not now know whether the formula S α belongs or not to ∆. The equation thus obtained, namely M (∆|S (¬α)) = M (∆, S α), is very convenient, for it rewrites the desired set of all models into an expression in which the overall complexity of the formulae has been strictly decreased. The same works for conjunction, whose results with respect to satisfiability can be used by distinguishing the two cases of the sign affecting it: M (∆|T(α ∧ β)) = (inferred above) {i ∈ I | i | = ∆ ∧ i | = T(α ∧ β)} = (truth of conjunction) {i ∈ I | i | = ∆ ∧ i | = T α ∧ i | = T β} = (satisfaction of a set of formulae) {i ∈ I | i | = ∆, T α, T β} = (definition of M) M (∆, T α, T β). On the other hand: M (∆|F(α ∧ β)) = (inferred above) {i ∈ I | i | = ∆ ∧ i | = F(α ∧ β)} = (falsity of conjunction) {i ∈ I | i | = ∆ ∧ (i | = F α ∨ i | = F β}) = (distributing ∧ over ∨) {i ∈ I | (i | = ∆ ∧ i | = F α) ∨ (i | = ∆ ∧ i | = F α)} = (trading ∨ for ∪ out of set comprehension) {i ∈ I | i | = ∆ ∧ i | = F α} ∪ {i ∈ I | i | = ∆ ∧ i | = F β} = (satisfaction of a set of formulae)

7 Since Γ is finite, no appeal to the axiom of choice is made here.

6 Presentation of Classical Propositional Tableaux on Program Design Premises {i ∈ I | i | = ∆, F α} ∪ {i ∈ I | i | = ∆, F β} = (definition of M) M (∆, F α) ∪ M (∆, F β). As a result we have so far obtained: M (∆|S (¬α)) = M (∆, S α) M (∆|T(α ∧ β)) = M (∆, T α, T β) M (∆|F(α ∧ β)) = M (∆, F α) ∪ M (∆, F β), where the case of a signed letter, i.e. a literal, could not be included. Now taking a look at the preceding equations for M, we readily realize that the missing case is actually that of a set not containing any composite formulae, i.e. that of a set of literals. Such is the base case of our recursion, since this proceeds by decreasing the size of the formulae of the set being treated —and not indeed the size of the set itself. Therefore it is natural to wonder whether the solution of such base case could actually be just immediate. This is indeed the case, because there is a straightforward manner of converting a set Γ of literals into the set

• f all its models. There are two cases:

⊲ Γ contains pairs of opposite literals. Then it is inconsistent and the set of its models is ∅. ⊲ Otherwise the models of Γ are the interpretations that coincide with Γ at the letters mentioned in it. Formally, call ˆ Γ the set of all models of the set Γ of literals. It is defined as follows: ˆ Γ = ∅ if {S p, S p} ⊆ Γ for some p, {i ∈ I | (∀S p ∈ Γ) i p = ˆ S}

• therwise.

Notice that the alternative is decidable and that in the second case the result is sufficiently characterised by the set Γ of literals and so we get a finite representation of it. We can then put together equations for actually computing M: M (∆|T(α ∧ β)) = M (∆, T α, T β) M (∆|F(α ∧ β)) = M (∆, F α) ∪ M (∆, F β) M (∆|S (¬α)) = M (∆, S α) M(Γ) = ˆ Γ if Γ is a set of literals. We claim that M captures the essence of the method of tableaux, and the derivation carried out above gives actually a quite simple proof of its correctness. Nevertheless, its actual execution needs to employ some kind of data structure to record the successive trans- formations leading to the final result. That is what we turn now to examining.

4 Data Structures for the Tableaux

List of lists. If we ignored the second equation above we would be in presence of a tail- recursive algorithm, i.e. one whose execution could consist merely in successively rewriting the finite set of formulae at hand. We would then do simply with a list of formulae from which we would choose the next formula to be transformed. Now, consideration of the second equation does not in principle introduce any dramatic modification of this situation: it is enough that each application of the equation produces a split of the list from which the formula F(α∧β) is taken into two lists, each of it containing exactly one of the two formulae Fα and Fβ in place of the original one, without any further change. We illustrate the working by means of an example. Suppose we consider Γ = [T(p ∧ ¬q), F(p ∧ q)], which we already make into a list of formulae (as indicated by the use of the [. . .] notation). Then we may choose say the second formula to proceed, which leads us to employ M’s second equation and therefore to split the original list into two, yielding [T(p ∧ ¬q), Fp], [T(p ∧ ¬q), Fq].

• J. Michelini and Á. Tasistro

7 In the next step we may choose any one of the two occurrences of the only composite (i.e. non-literal) formula. Say we take the left one. The equation to employ is M’s first, yielding [Tp, T(¬q), Fp], [T(p ∧ ¬q), Fq]. Of course we may do the same with the right occurrence of the formula just considered, arriving at [Tp, T(¬q), Fp], [Tp, T(¬q), Fq]. We now are left only with the two occurrences of T(¬q) to treat, which we must do in two steps using the third equation of M. We write the final result at once: [Tp, Fq, Fp], [Tp, Fq, Fq]. Clearly the first set of literals is unsatisfiable which, by the way, we could have noticed some steps earlier, thereby obtaining a less expensive development. The second set is just {Tp, Fq}. and characterizes all the models of the original Γ. There seem to be three inconveniences as to this execution. The first is that we have treated one and the same formula twice, and that on two different occasions. One readily realizes that the issue is avoidable if the use of the branching equation corresponding to a false conjunction is always subsequent to the use of every other (non-branching) equation formerly applicable. The second inconvenience is that we have rewritten many a formula that was without change. And, finally, the execution is awkwardly traceable —we have namely indicated the successive steps taken by means of narrative text interspersed in the successive rewritings. The latter is of importance when we consider executions by hand — then a more formal and easily checkable notation would be most welcome by both students and teachers. We shall consider these two remaining issues in the next two subsections, beginning with the latter about an easily traceable notation. Tree of lists. The straightforward manner of making executions like the former traceable and easily verifiable is just to record the application of each rule, including mention to the formula used. We should therefore begin by naming the equations of the algorithm, say T∧, F∧, ¬ and l in the order in which they are written above. The procedure leads to the deployment of a tree structure whose nodes are lists of formulae as in the preceding section, and whose internal nodes (not leaves) are decorated by labels as explained presently:

• 0. To begin with, we have only one item, namely the original list of formula. This is of

course a tree with only one terminal node (leaf).

• 1. At each step we choose a composite formula within a leaf (call this leaf L) and apply the

corresponding rule as already explained. As a result one or two new lists of formulae are

• btained, which are linked to L, becoming successors of L in the tree. At the same time

we label L with the name of the equation and the formula used. The leaves of these trees coincide with the lists of formulae obtained by the procedure explained in the preceding paragraph —we have only added a tree structure on top of them for tracing their computation. Therefore, the set of models of the root of the tree

• btains as the union of the sets of models of the leaves. Formally, this much becomes clear

after the consideration that the union of the sets of models of the leaves, and therefore the invariant just mentioned, are indeed preserved by each application of one equation as described above. Therefore the correctness of the computation procedure using these trees follows by straightforward mathematical induction. The right formulation and proof of this result is left as exercise. For a more formal presentation, consider the following inductive definition of the trees, i.e. a definition by enumeration of their constructors: We define the family of sets T (Γ) for

8 Presentation of Classical Propositional Tableaux on Program Design Premises each finite list of signed formulae Γ, with each tree of type T (Γ) having a root containing the list of formulae Γ. Constructors are to be interpreted simply as manners of forming trees

• f the mentioned kind, generally using other trees. Consider to begin with the constructor

corresponding to the use of the first equation above, i.e. the one of a true conjunction: T ∧ : T ((∆, T α, T β)) → T ((∆|T(α ∧ β))). We are saying that a tree for ∆|T(α∧β) is obtained by constructing one for ∆, T α, T β. This corresponds, in terms of the procedure explained above for executing the algorithm M, to choosing T(α ∧ β) in the given set of formulae, marking it, and proceeding to its

• decomposition. It is clear that we can also interpret the declaration above as a mere rewrite
• f the first equation of the algorithm M, and therefore as: The models of ∆ |T(α ∧ β) are

those of T(α ∧ β). The same goes for the second constructor, F∧ : T ((∆, F α)) × T ((∆, F β)) → T ((∆|F(α ∧ β))), where set union has to be made correspond to the pair former. The case of the constructor corresponding to the third equation is straightforward: ¬ : T ((∆, S α)) → T ((∆|S (¬α))). Finally, the leaf case corresponds to a yet not processed list of formulae: l : (Γ ∈ PfinΣ) → T (Γ). Tree of formulae. The repetition of possibly large lists of formulae along the trees as in- troduced in the preceding section can be avoided, e.g. by employing the procedure described in [?]. We describe these less expensive trees as follows: The general idea is to write at each node of the tree different from its root only the formulae originated by the use (decomposition) of another formula. The root of the tree will contain the originally given set (list) of formulae. With this information it is possible to compute the full trees of the preceding section provided the used formulae are recorded at each step, i.e. at each node. Therefore, the correctness of the present method with improved trees will follow from the correctness of the prior method. Specifically, we define the improved trees as follows:

• 1. Each node will have associated an explicit set E and an implicit set Γ of formulae. E is

to be written down explicitly, whereas Γ is to be computed when necessary.

• 2. For the root of the tree, both E and Γ coincide with the originally given set of formulae.
• 3. For the other nodes, E will consist of one or two formulae.
• 4. All internal (i.e. non-leaf) nodes will also have associated one formula, to be called the
• ne used at the node.

We now indicate how to extend the tree down from a leaf:

• 1. A formula in Γ is chosen and written down at the node as its used formula.
• 2. Then one proceeds according to the form of the chosen formula:
• a. In case it is of the form T (α ∧ β) then the tree is extended with one child node. For

this new node, E = {T α, T β}.

• b. In case it is of the form F (α ∧ β) then the tree is extended with two children nodes.

One of them will have E = {F α} , whereas the other one will have E = {F β}.

• c. Finally, in case the chosen formula is of the form S (¬α) then the tree is extended

with one child node having E = {S α}. For every case of newly created node, the set Γ is computed as follows: If Γ0 is the implicit set of the parent node, then Γ = (Γ0 − σ) ∪ E, where − denotes deletion of a member in a set. Now, to each improved tree t with a non-leaf root which has associated explicit set E and implicit set Γ of formulae, as well as used formula σ, a full tree of type T (Γ) can be associated, whose constructor is the one corresponding to the form of σ, i.e. T∧, F∧ or ¬,

• J. Michelini and Á. Tasistro

9 and its children trees are the ones (recursively) corresponding to the children trees of t. If

• therwise t is just a leaf, then its corresponding full tree is l(Γ), where Γ is the implicit set of

formulae of the leaf in question. This correspondence gives already a method for using the improved trees in order to compute all the models of any given set of formulae. Nevertheless, the following result makes such process easier: The implicit set at each leaf is the union of the explicit sets at the branch ending up at the leaf in question, minus those formulae that have been used on that branch. Thereby one can determine when a branch is completed, which happens when the implicit set at the corresponding leaf is a set Γ of literals. Further, then ˆ Γ is the corresponding set of models, and one can then compute the set of models of the whole tree (i.e. of the originally given set of formulae) by taking the union of the sets at each leaf, just as with the full trees.

5 Conclusions

We have put forward a presentation of classical propositional tableaux elaborated by ap- plication of some principles that are noteworthy in program design. Foremost among those principles is the one of separation of concerns: We have namely started by deriving from a straightforward specification an algorithm given as a set of recursive equations for com- puting all models of a finite set of formulae. The correctness of the algorithm is brought about hand-in-hand with its derivation by means of a basic inductive argument whose cases are each solved by calculational reasoning yielding identities between sets of interpretations that need not the usual “ping-pong” (or direct-and-converse) argument. Thereafter we discussed the employment of data structures, mainly with regard to a manual execution of the algorithm. A requirement of natural traceability and verification led us to the trees of sets or lists of formulae presented in [Hintikka?] and [Ben-Ari], the correctness of which is immediate after their derivation as traces of the employment of the

• riginal equations. A further improvement avoids repetition of unmodified formulae giving

rise to the trees presented in [Smullyan], whose correctness is in turn guaranteed by showing that they carry the same information as the former trees. Smullyan’s classical presentation [?] introduces instead the method as a proof procedure for establishing unsatisfiability of (finite) sets of (signed) formulae. The tableaux are given directly in the form of our improved trees of formulae. The proof of correctness is then as usual composed by two arguments, one of soundness and one of completeness, to the effect that unsatisfiable sets give rise to closed tableaux, i.e. one in which every branch contains a contradiction and thus has no model. The proof of soundness is by a quite direct tree induction, whereas the proof of completeness involves showing that an open completed branch, i.e. one in which every formula has been fully decomposed, is a Hintikka set. Besides, Hintikka’s lemma is proven, to the effect that every Hintikka set has a model. In our experience, the use of the method as in the classical presentation leads students to the realisation that they either prove the given set of formulae inconsistent or can compute every counter-example (i.e. a sufficient characterisation thereof). Subsequently they tend to ask why we cannot establish such fact as a meta-theoretical result. Our presentation does precisely that —and the correctness of the method as a proof procedure follows as immediate corollary. The idea of computing all models of the given set of formula has led us to give an abstract formulation of the procedure. We have striven to derive this in a fully detailed manner, thereby providing motivation and plain explicit justification to the rules

• f the method. We then treat as a separate matter the question of the concrete trace of the

manual execution of the method. As we have been able to check, this treatment provides

10 Presentation of Classical Propositional Tableaux on Program Design Premises the students with improved command over the method, i.e. they exercise a more sound domain over what they are doing and also over the various possible notations or manners of justification they can give thereof. It could be argued that Smullyan’s presentation and proof is scalable to infinite sets of formulae and first-order-logic, and therefore ask about such feature regarding our present- ation. Concerning infinite sets of formulae, the first thing to say is that the validity of

• ur equations is certainly not affected. Nevertheless, they cannot of course be interpreted

anymore as an algorithm. Even if we assume as usual a principle of omniscience concern- ing the infinite sets, the method of choice of the formulae to be succesively decomposed by application of the equations is essential for getting the right result. But, as is the case also with the classical presentation, there exist method of orderly choice that guarantee (under the ominiscience principle) the computation of all models and thus the correctness of the

• method. Generalisation to first-order logic, on the other hand, requires to abandon the idea
• f “computing all models”, replacing it by e.g. “determining whether the set of formulae is
• r not (un)satisfiable”.

We conclude that our presentation contributes in a better way to the achievement of profficiency with understanding, which is our main learning objective. Also it emphasizes design methodology, which we strive to do along and across the whole of the program of

• studies. It also could be argued that the method is tailored to just students of Computing

Science or Software Engineering. We however believe that it can be taught also without much difficulty to Mathematics or Philosophy students and that the advantages we claim to obtain can also be appreciated in such cases. This, however, is yet to be checked out. Finally, we should like to think of this work as one interpretation and case of the disclosing

• f the “doing” of Mathematics as advocated by Dijkstra [?]. We have tried to avoid all gaps
• f both mathematical and motivational nature. To our mind, this case is yet another sample
• f the unity of structure and method that mathematics and programming share8. Exploiting

such unity should be fruitful for improving understanding and thus better helping learning.

8 And that at a deeper level shows up in the propositions-as-types principle.