Dynamic Tableaux for Dynamic Modal Logics ◆ Thesis submitted in fulfillment of the requirements for the degree of Doctor of Philosophy at Vrije Universiteit Brussel by Jonas De Vuyst Supervised by Prof. Dr. Jean Paul Van Bendegem & Dr. Patrick Allo November 2013 (Minor Revision, January 2014)

◆ Acknowledgements First and foremost I want to thank my supervisors Jean Paul Van Bendegem and Patrick Allo. This dissertation would not have been written without their guidance and advice. Their input was invaluable during the writing of a first and second thesis proposal, over the changes in research focus over the years, and to the creation of the concrete dissertation that you are now reading. I want to thank Benedikt Löwe and Fenrong Liu for giving me the opportunity to spend a semester at the Institute for Logic, Language and Information in Amsterdam and at Tsinghua University in Beijing. I really learned a lot in Amsterdam, and in Beijing I made some of the fundamental breakthroughs that led to this dissertation. I want to thank Lorenz Demey, Davide Grosse, Peter van Ormondt, Sonja Smets, Hans van Ditmarsch, Andreas Herzig, Giuseppe Primiero, Yanjing Wang, and Jens Ulrik Hansen for various discussions about logic that have benefitted me. This list is by no means exhaustive-I want to extend my gratitude to everyone else in the logic community that I have had the pleasure of meeting and to everyone at the Center for Logic and Philosophy of Science. More generally, I want to thank my friends and family for their moral support over the years. I am especially indebted to my mother and my grandmother for having always encouraged and believed in my education. Finally, I want to thank the Fund for Scientific Research – Flanders for funding my research the past four years and the Research Council at the Vrije Universiteit Brussel for funding my first year as a PhD student. iii

◆ Contents Contents v 1 Introduction 1 1.1 Syntax, semantics, and deduction . . . . . . . . . . . . . . . . . . 1 1.2 The semantics–proof system gap . . . . . . . . . . . . . . . . . . 3 1.3 What's in a proof? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Modal Logics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2 Notation and Structures 7 2.1 Tuples and sets of tuples . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Labeled graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3 Graphs and relational structures . . . . . . . . . . . . . . . . . . . 11 2.4 Embeddings and bisimulations . . . . . . . . . . . . . . . . . . . . 12 2.5 Notation for formal syntax . . . . . . . . . . . . . . . . . . . . . . 14 3 Modal Logic 16 3.1 Syntax and semantics of LU◻ . . . . . . . . . . . . . . . . . . . . . 18 3.2 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3 A tableau proof system for LU◻ . . . . . . . . . . . . . . . . . . . 24 3.4 Decidability of LU◻-tableaux . . . . . . . . . . . . . . . . . . . . . 35 3.5 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4 Public Announcement Logic 46 4.1 L◻! and its dynamic semantics . . . . . . . . . . . . . . . . . . . . 46 v 4.2 Dynamic tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.3 Tableau cascades and decidability . . . . . . . . . . . . . . . . . . 55 4.4 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5 Dynamic Epistemic Logic with Action Models 63 5.1 Syntax and semantics of L◻⊗ . . . . . . . . . . . . . . . . . . . . 63 5.2 Dynamic Tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.3 Decidability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.4 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6 Dynamic Preorder Logics 76 6.1 Belief revision and preference change . . . . . . . . . . . . . . . 76 6.2 LU◻¡♯⇑ and its dynamic semantics . . . . . . . . . . . . . . . . . 77 6.3 Dynamic tableaux for dynamic preorder logics . . . . . . . . . . 82 6.4 Decidability of tableaux for LU◻¡♯⇑ . . . . . . . . . . . . . . . . . 87 6.5 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 7 Clojure Implementation 91 7.1 A brief overview of Clojure . . . . . . . . . . . . . . . . . . . . . . 92 7.2 Utility functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 7.3 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.4 Tuple bags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 7.5 Tableau system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 7.6 Tableau cascades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 7.7 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 7.8 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 8 Conclusion 132 Bibliography 135 Index of Definitions 139 CONTENTS vi 1 Introduction In this PhD thesis we present new proof systems for several modal logics. We also present an implementation of one of these proof systems in the Clojure programming language. The proof systems we present fall squarely in the category of tableau systems. Such systems have a long history. Many tableau systems have been developed for many different kinds of logic, including the logics found in this volume. Thus the contribution of our tableau systems is not to be found in their theoretical prowess. Rather, their intended benefits are conceptual simplicity, ease-of-use, modularity, and extensibility. To understand how we believe we can deliver on these promises, let us take a step back and reflect on three core concepts of logic-syntax, semantics, and deduction. 1.1 Syntax, semantics, and deduction Syntax can be understood as a delineation of the natural or formal language that we want to investigate. For example, we might be interested in sentences containing 'atomic' propositions, their negations, negations of these negations, and so on. Semantics refers to theories about the meaning of sentences and other terms of the language. Finally, deduction is a form of reasoning and refers to the deriviation of conclusions from premises. Both the premises and conclusions are here assumed to be expressible in the chosen language. 1 In formal logic the above three concepts are studied using tools from mathematics. We illustrate this using an example. Consider the following syntax: 1. p,q,r are atomic propositions. 2. Atomic propositions are well-formed formulas. 3. Recursively, if φ is a well-formed formula then so is not-φ. 4. Nothing else is a well-formed formula. Before we can give a semantics for this language, we need to define what constitutes a model. The job of the semantics is to tell us whether a given well-formed formula is true in a given model. Let S be a model if and only if it is a set of atomic propositions. Also, let a proposition p be true in a model S if and only if p ∈ S; a negation not-φ is true in S if and only if φ is not true in S. We now have a semantics and it unambiguously tells us that, for instance, not-not-not-p is true in the model {q,r}. In formal logic, the aspect of deduction is covered by proof systems. For instance, let's create a proof system that allows us to prove that ψ (the conclusion) follows from φ (the premise). The system is as follows: 1. Start with the set {φ,not-ψ}, called a tableau. 2. Recursively, if the tableau contains not-not-χ then add χ to the tableau. 3. If, for any atomic proposition p, the final tableau contains both p and not-p then ψ follows from φ; otherwise it does not follow. The above proof system is called a tableau system. Using this system we can demonstrate that p follows from or is 'entailed' by not-not-p. First of all, by step 1 we start with {not-not-p,not-p}. By step 2 this tableau is transformed into the tableau {not-not-p,not-p,p}. This tableau contains the atom p and its negation not-p, which concludes our proof by step 3. Similarly, we can prove that not-not-q follows from q since step 1 gives us {q,not-not-not-q} and step 2 leads to the tableau {q,not-not-not-q,not-q}. CHAPTER 1 2 Figure 1.1. In a sense, logic is a subfield of the study of languages. In formal logic, then, formal languages are studied. Once the language is circumscribed, a formal semantics and a proof system are sought out. Ideally, the proof system is sound and complete with respect to the semantics. Syntax Semantics Proof System Meaning Deduction Completeness Soundness The above proof system is sound. This means it allows us to prove that ψ follows from φ only if in all models in which φ is true, ψ is also true. It is also complete, meaning that if ψ is true in all models in which φ is true then we can prove this entailment. In languages that have an operator 'If ... then ...' it is sometimes possible to do away with premises. Instead of proving that ψ follows from φ we prove that 'If φ then ψ' always hold. For languages in which the deduction theorem holds these statements are equivalent. In such languages we can prove that ψ follows φ by starting with the tableau {notIf φ then ψ}. That is, we prove that 'If φ then ψ' without using premises. In other words, in many logics it suffices that a proof system is 'weakly complete', meaning that it can prove tautologies-well-formed formulas that are true in every model. 1.2 The semantics–proof system gap In formal logic the usual aim is to discover proof systems that are sound and complete with respect to a semantics. However, both historically and in much of contemporary literature, proof systems and semantics are developed CHAPTER 1 3 relatively independently. This is sometimes true in a temporal sense, such as when a proof system is devised long before a semantics is discovered (or vice versa). However, this gap also exists in a conceptual sense. Understanding many a proof system requires familiarity with a number of tautologies (technically, 'tautology schemas'), and it is often non-obvious why these tautologies hold simply by looking at the semantics. We conjecture that the gap between semantics and proof systems is rooted in the long, rich, and partially independent histories that both these areas boast. We want to take a break from this tradition. In the proof systems in this dissertation we attempt to reflect the semantics of our languages as closely as possible. We aspire to the following benefits. • Conceptual simplicity. Looking at the semantics, the proof system should be easy to understand. • Ease of use. For simple formulas, humans should be able to create proofs and verify proofs easily. The proof system should also allow missteps to be unwound without requiring unrelated results to be erased. • Modularity. There should be an injective mapping from the discrete elements of the semantics to the discrete elements of the proof system. • Extensibility. Semantics tend to be easy to extend: After adding one operator to the language it typically suffices to add but one clause to the semantics. Proof systems should aspire to such extensibility also. Ideally, extending the proof system should not require revising previous elements of the proof system and it should not affect modularity. 1.3 What's in a proof? There's one striking difference between tableau systems and most other formal proof systems that deserves a special mention. Direct proofs are the paradigm for most proofs systems. A proof might look as follows. 1. All people are mortal. Premise. CHAPTER 1 4 2. Philosophers are people. Premise. 3. Socrates is a philosopher. Premise. 4. Socrates is a person. Inference from (2) and (3). 5. Socrates is mortal. Inference from (1) and (4). Here we only make use of logically correct inferences. Therefore every step in this proof is either (i) itself a premise or (ii) entailed by the premises. Thus the line (1) to (5) comprise a proof that from "All people are mortal", "Philosophers are people", and "Socrates is a philosopher" it follows that "Socrates is mortal". In contrast, proofs by contradiction are the paradigm for tableau systems. Here is one example of such a proof. 1. All people are mortal. Premise. 2. Philosophers are people. Premise. 3. Socrates is a philosopher. Premise. 4. Socrates is not mortal. Negation of the intended conclusion. 5. Socrates is not a person. Inference from (1) and (4). 6. Socrates is not a philosopher. Inference from (2) and (5). This is a correct proof because lines (3) and (6) contradict each other. What happened is that we tried to construct a model in which the premises were true and the conclusion was false, but failed. Thus, constructing a proof in a tableau system corresponds to a trial-and-error method of learning. Opinions on this matter differ, but we personally feel trial-and-error methods are a more instructive paradigm of learning. CHAPTER 1 5 1.4 Modal Logics Modal logics are logics for reasoning about possibility, knowledge, beliefs, preferences, time, and other modalities. Their semantics are almost always based on Saul Kripke's possible world semantics. Kripke semantics provides an intuitive way to look at modalities. It is so intuitive that, from today's perspective, it is almost puzzling that for the first few decades after proof systems for modal logic were first invented, no one managed to develop semantics for them [21]. The intuitiveness of Kripke semantics suggests that tableaux for modal logic too should be easy to understand. This is indeed the case. Dynamic modal logics are modal logics with dynamic operators for public announcements, belief revision, preference upgrades, and so on. The dynamic modal logics that interest us here are those that use Kripke semantics as a starting point and define their dynamic operators via mathematical operations on those semantics. Thus, for example, a belief revision operator in the syntax would correspond to a belief revision operation on models. The 'dynamic' semantics of dynamic modal logics are a clever way of extending languages without compromising on intuitiveness. In this PhD thesis we present 'dynamic' tableau systems for these dynamic semantics, with the express aim to make them conceptually simple, easy to use, modular, and extensible. CHAPTER 1 6 2 Notation and Structures The research that this volume reports on is heavily grounded in basic set theory. As such, it should not come as a surprise that it contains a lot of mathematical notation. Mostly, that's a good thing! It's a feature of mathematical notation that set-theoretic notions (among others) can be described in a very precise and concise way. It's no exaggeration to say that half a line of mathematical notation can often express ideas that would take several plain English sentences to explain. This adds up quickly when several such notions need to be related. Such verbosity is especially problematic when the idea that is being communicated is complex enough that it warrants repeated scanning. Additionally, mathematical notation is highly structured, which further facilitates parsing (given some practice). Throughout this work it's assumed that the reader has a good grasp of basic set theory. This includes an understanding of functions and relations, graphs, and logical quantification. In this chapter we discuss pivotal mathematical structures and introduce succinct notation for them. Admittedly, some of this notation is unconventional; however, it will be used often enough for the brevity that it affords to pay off. 2.1 Tuples and sets of tuples The following general mathematical structures are used throughout this volume: sets, tuples, sets of tuples, and labeled graphs. We will not make any 7 special assumptions with respect to sets. As such, let us go through some tuple-related notions straight away. (Notice that new names and notations are enclosed in angle quotes.) Definition 2.1. A «tuple» t = ⟨e0 ...el⟩ is an ordered list of elements e0,... , el. A tuple with n elements is also called an «n-tuple». Moreover, a tuple with one element is called a «single», a 2-tuple is called a «pair», and a 3-tuple is called a «triple». We will assume that the number of elements in a tuple is unambiguous. With n ≠ m, no n-tuple is also an m-tuple. Finally, the notation «E0 ×...×El» is used to denote the set of all l-tuples ⟨e0 ...el⟩ such that e0 ∈ E0,... , el ∈ El. The above notation is somewhat unorthodox in that elements of tuples are not separated by commas. It is, however, in line with common notation for relationships-e.g. Rabc-and below we extend this convention even further. Sets of tuples will prove to be a crucially important mathematical structure. Thus, we define extra notation that is optimized for our intended interactions with such sets. Definition 2.2. With S a set of tuples, we use «Se0 ...el» as a shorthand for '⟨e0 ...el⟩ ∈ S'. The shorthand Se0 ...el allows us to treat sets of tuples as if they were relations. This is sensible because relations and sets of tuples are virtually the same thing. The only difference is that relations have explicit domains. Proposition 2.1. Let T ⊆ D0×...×Dl be a set of tuples. T corresponds to the relation R between the elements of D0,... ,Dl such that for all e0 ∈ D0,...el ∈ Dl it is the case that Te0 ...el ⟺ Re0 ...el. Given a sequence of elements e0,... , ei′,...el′ such that ei′ ∉ Di′ for at least one i′ (where 0 ≤ i′ ≤ l) it is the case that Te0 ...el′ is false whereas Re0 ...el′ is undefined. One important use case for sets of tuples is filtering elements that match a certain pattern. The following notation makes this more convenient. CHAPTER 2 8 Definition 2.3. Let «S[e0 ...?...el−1]» be the set {x ∣ Se0 ...x...el−1)}. Additionally, given a sequence ∗0,... ,∗l−1 of n objects and m = l − n ≥ 2 metasyntactic variables ?, let «S[∗0 ...∗l−1]» be the set of m-tuples such that ⟨e0 ...em−1⟩ ∈ S[∗0 ...∗l−1] if and only if S contains the tuple that results from substituting the elements e0,... , em−1 for the ?-placeholders in ∗0,... ,∗l−1, preserving their order. When we know that the result of a query S[∗0 ...∗l−1] is a singleton we sometimes write «S(∗0 ...∗l−1)» to denote its unique element. Take notice that when a query S[∗0 ...∗l−1] contains exactly one ?, the result is a set of objects that are not necessarily tuples. In contrast, when such a query contains m ≥ 2 variables then the result is a set of m-tuples. Example. Given a set S = {⟨a⟩, ⟨abc⟩, ⟨abd⟩}, it is the case that • S[ab?] = {c,d} • S[a??] = {⟨bc⟩, ⟨bd⟩} • S[??c] = {⟨ab⟩} • S(??c) = ⟨ab⟩ Given the correspondence of relations to sets of tuples we will sometimes also use this notation to query relations. 2.2 Labeled graphs Many definitions of labeled graphs start by stating that a graph is a triple of the following three sets: a set of vertices, a set of vertex-label pairs, and a set of (labeled) edges. We opt for a slightly different notational approach and instead define graphs as sets that contain three kinds of tuples: singles that contain vertices, vertex-label pairs, and triples that represent the labeled edges. Definition 2.4. G = {⟨n⟩ ∣ n ∈ N}∪ L∪ E is an «lgraph» if and only if CHAPTER 2 9 Figure 2.1. Diagram of the lgraph {⟨n⟩, ⟨m⟩, ⟨anm⟩, ⟨nα⟩, ⟨nβ⟩, ⟨mγ⟩}. n α,β m γ a • N is a set of objects. Every n ∈ N is called a «node» or «vertex» (plural: vertices) of G. • L is a set of pairs. We say that l is a «label» (of G) for n if and only if Lnl. The «label-set» of a node n (of G) is the set G[n?]. We also say that the node n contains l if and only if l ∈ G[n?]. For every ⟨nl⟩ ∈ L it is the case that n is a node of G. • E is a set of triples. We say that n′ is «accessible» from n over a if and only if Eann′. Every ⟨ann′⟩ ∈ E is called a (labeled) «edge» or «link» (of G) from n to n′ indexed by a. Sometimes ⟨ann′⟩ is also described as the «a-edge» from n to n′. Finally, ⟨ann′⟩ ∈ E is called an «outgoing» a-link of n (in G) and an «incoming» a-link of n′ (in G). For every ⟨ann′⟩ ∈ E it is the case that n and n′ are nodes of G. A «path» or «chain» in an lgraph G is a sequence n0,... ,ni, ni+1,... ,nl such that for every natural number i < l it is the case that G[?nini+1] ≠ ∅. If, moreover, Ganini+1 for all natural numbers i < l then the sequence is called an «a-path» or «a-chain». Given an lgraph G, let «root(G)» be any n ∈ G[?] such that there is a path from n to any other node of G (or undefined if no such node exists). One convenient feature of our notation is that its nodes, labels, and edges can be accessed as elements of G in a fairly straightforward way. Example. For any lgraph G it is the case that • Gn ⟺ n ∈ G[?] • Gnl ⟺ ⟨nl⟩ ∈ G[??] CHAPTER 2 10 • Gann′ ⟺ ⟨ann′⟩ ∈ G[???] Sometimes we will want to talk about graphs in combination with one specially designated node. Other times we will be interested in the vertices and edges of a graph, but not in its labels. Hence we introduce the following terminology. Definition 2.5. With G an lgraph and n one of its nodes, the pair ⟨Gn⟩ is called a «pointed graph». Here, n is called the «current node» (of G). The «frame» of an lgraph G is the lgraph F ≔ {⟨n⟩ ∣ n ∈ G[?]} ∪G[???]. We will investigate many different kinds of operations on graphs, many of which are monotone-that is, they only ever extend graphs. The following definition gives us a rough notion of what part of the graph was modified. Definition 2.6. Given a monotone unary operation f on graphs and a graph G, we say that the nodes «affected» by applying f to G are the elements of the following set: Δ[?] ∪ {n ∣ Δ[n?] ≠ ∅,Δ[?n?] ≠ ∅, or Δ[??n] ≠ ∅}, where Δ = G′ −G. That is to say, the nodes affected by f are (i) the nodes that are added, (ii) the nodes to or from which edges are added, and (iii) the nodes to which new labels are added. 2.3 Graphs and relational structures In the following chapters we will define Kripke models and action models as lgraphs. This is unusual. Normally these models are defined as relational structures. As mentioned above, however, sets of tuples and relations are practically the same thing. Therefore it is not surprising that lgraphs can easily be converted to relational structures (and vice versa). CHAPTER 2 11 Definition 2.7. A «relational Kripke structure» is a triple ⟨WRV⟩ such that W is a set of nodes, R is a function from indices to binary relations on W, and V is a function from worlds to sets of labels. Proposition 2.2. A relational Kripke structure ⟨WRV⟩ is equivalent to an lgraph G if and only if • W = G[?]. • For all indices a and all {w,v} ⊆ W, R(a)wv ⟺ Gawv. • For all w ∈ W it is the case that V(w) = G[w?]. The reason why we will define Kripke models as lgraphs rather than as relational structures is that throughout this thesis will often want to compare models to (other) lgraphs. Directly representing models as lgraphs makes this much more straightforward. 2.4 Embeddings and bisimulations Embeddings and bisimulations are two general mechanisms for comparing lgraphs and other structures. Embeddings map structure and contents of one lgraph onto a second lgraph. Definition 2.8. Given two lgraphs G and G′, we say that the function h ∶ G[?] → G′[?] is an «embedding» from G in G′ if and only if • Gn ⟹ G′h(n) • Gnl ⟹ G′h(n)l • Gann′ ⟹ G′ah(n)h(n′) The above definition maps labels and indices in G onto themselves (in G′). This leaves room for further generalization. The present definition is sufficiently abstract for our needs, however. CHAPTER 2 12 Figure 2.2. The lgraph on the left is embedded in the lgraph on the right (but not vice versa). The embedding is the function that maps n and n′ onto m. n α n′ α m α m′ β a ba Figure 2.3. Two bisimilar lgraphs. One bisimulation is the relation that holds between the two β-nodes and between all α-nodes. In fact, this particular bisimulation also happens to be the union of all bisimulations between these graphs. β α α α α β a b a a a,b a It is instructive to reflect on the following question: When are two lgraphs or nodes 'equivalent'? One answer would be to say that two lgraphs G and G′ are equivalent if and only if there's an embedding h from G to G′ such that its inverse function h−1 is an embedding from G′ to G. This property is called isomorphism. Isomorphism is but one notion of equivalence, however. Bisimulations represent a more flexible kind of equivalence of two nodes. The underlying idea is, metaphorically speaking, that we embark on two journeys starting at n and n′ and are allowed only (i) to travel over the outgoing edges and (ii) to compare the labels of the current nodes. If after no such journey we can tell n and n′ apart then both nodes are deemed bisimilar. CHAPTER 2 13 Definition 2.9. A «bisimulation» between (the nodes of) two lgraphs G and G′ is a relation Z between G[?] and G′[?] such that Znn′ if and only if the following conditions are met: • G[n?] = G′[n′?]. • For every ⟨am⟩ ∈ G[?n?] there is an m′ ∈ G′[an′?] such that Zmm′. • For every ⟨am′⟩ ∈ G′[?n′?] there is an m ∈ G[an?] such that Zmm′. Two pointed lgraphs ⟨Gn⟩ and ⟨G′n′⟩ are «bisimilar» if and only if there is a bisimulation Z between them such that Znn′. We also write «⟨Gn⟩ ↔ ⟨G′n′⟩» if and only if ⟨Gn⟩ is bisimilar to ⟨G′n′⟩. 2.5 Notation for formal syntax In the introduction we explained that formal logic encompasses the study of formal languages. This means we need meta-syntax for describing said languages-specifically, we need conventions (i) for specifying their syntax or grammar and (ii) for denoting subsets of these languages that match certain patterns. We specify the syntax of formal languages using a variant of Backus-Naur Form (BNF) that is commonplace in literature on formal logic. Let's start with an example. Example. Let language L be the set of all formulas that are recursively defined as follows: φ ::= p ∣ ¬φ ∣ (φ∧φ), where p ∈ Prop. This notation raises many questions. For instance, what kind of elements are in L and in Prop? The elements of Prop are 'symbols' by virtue of their use in the definition of L. It may help to think of Prop as consisting of letters of the Latin alphabet CHAPTER 2 14 or as Unicode 'codepoints', although from a formal point of view they can be anything. The elements of L are concatenations, sequences, or 'strings' of the elements of Prop and the symbols '¬', '(', ')', and '∧'. Of course it is not the case that every string consisting of those symbols is an element of L. Only elements that fit our recursive definition are. It might help some readers if we recast our previous definition in a BNF commonly used in computer science. Suppose that Prop contains the symbols 'p', 'q', 'r', and nothing else. L then contains exactly those symbols that can be derived as ⟨expr⟩ using the following rules. ⟨atom⟩ ::= 'p' ∣ 'q' ∣ 'r' ⟨expr⟩ ::= ⟨atom⟩ ∣ '¬' ⟨expr⟩ ∣ '(' ⟨expr⟩ '∧' ⟨expr⟩ ')'. That is to say, L is the smallest set that meets the following criteria: • The elements of Prop are in L. • The concatenation of '¬' and any element of L is an element of L. • The concatenation of '(', any element of L, '∧', any element of L, and ')' is an element of L. We use the notation |φ| to denote the length of the string φ. Throughout this thesis we use φ,ψ,χ, or ξ to refer to strings of symbols. We use lowercase italic letters p,q,r to refer to single symbols from the set Prop and a,b, c to refer to symbols from the set Ind. Finally, we sometimes combine all of these, as well as the symbols (, ), [, ], ¬, ∧, !, and so on to refer to strings that match certain patterns. Thus, outside of syntax specifications, (φ∧ψ) refers to any string of the pattern '(' ⟨string⟩ '∧' ⟨string⟩ ')'. Moreover, if (φ∧ψ) = (χ∧ p) then φ = χ and ψ = p. Therefore, outside the scope of BNF rules, (φ∧φ) may refer to the string (p ∧ p) but not to (p ∧ q). CHAPTER 2 15 3 Modal Logic Logic is often defined as the study of (correct) reasoning. In formal logic-also known as symbolic logic-this study is approached in a mathematical way. From here on, when we say 'logic' we mean 'formal logic'. Propositions are represented by sentences that are either true or false. For instance, the sentences "Snow is white" and "Cats meow and dogs bark" express propositions; contrariwise "Is it raining?" and "moon" are expressions that are neither true nor false. Propositions should not be confused with the sentences that represent them; rather, on one account propositions are the metaphysical entities which those sentences refer to [29]. Propositional logics are logics for reasoning about propositions. In one popular way of doing propositional logic the following steps can be distinguished: 1. A language is defined in a formal way by inductively defining a «syntax» or «grammar». The language is the set of all sentences that adhere to this syntax. Propositional languages consist of atomic propositions p,q,r,... that can be combined with a unary negation operator ('not', ¬) and binary operators for conjunction ('and',∧), disjunction ('or',∨), and implication ('if ... then', →). 2. Each sentence of the formal language is given a meaning or «semantics» in set-theoretic terms. This makes it possible to unambiguously decide for each sentence if it is true or false in a given «model» (or possibly at a certain 'point' in a model). 3. The semantics for the language may sometimes allow models to be constructed that, upon reflection, may not be germane to the language. For instance, suppose the semantics allow for a model in which a sentence A is true. By appealing to intuition A might in fact seem incoherent- meaning it should always be false. The logician's job is then to identify the set-theoretic property P that singles out such subversive models. He or she then stipulates that P-models are not models for the logic that is being developed. 4. A proof system is devised. This involves specifying what a proof looks like and specifying rules for checking whether or not a proof is «correct». The outcome of a correct proof-after discharging all assumptions-is a sentence of the formal language that is 'logically true'. That is, a proof serves to demonstrate that a certain sentence is true in every model (excluding the subversive ones). This property is called «soundness». Ideally, all sentences that are true in every model can also be proved in the proof system. This is called «completeness». The outcome of a proof is a sentence-a purely syntactic object-and not a proposition. This means that when we prove that (p → p), we put no restrictions on what p refers to. We would have proved that 'If Brussels is the capital of Belgium then Brussels is the capital of Belgium' and that 'If Prague is the capital of Columbia then Prague is the capital of Columbia'. In other words, logic concerns itself with the form of reasoning. In this chapter we discuss an extension of (a classical interpretation of) propositional logic that is called modal logic. In subsequent chapters we extend our investigations to dynamic modal logics. CHAPTER 3 17 3.1 Syntax and semantics of LU◻ Modal propositional logics extend (classical) propositional logic with modalities such as 'necessarily', 'knows that', 'believes that', or 'it ought to be the case that'. Definition 3.1. Let the language of multi-modal propositional logic LU◻ consist of all «well-formed formulas» (wffs) φ composed as follows: φ ::= p ∣ ¬φ ∣ (φ∧φ) ∣ Uφ ∣ ◻aφ, with p an element of a nonempty set of atomic propositions or atoms «Prop» and a an element of a set of indices «Ind». For convenience we also define the set of «literal propositions» or «literals»: Let «Lit » ≔ Prop∪{¬p ∣ p ∈ Prop}. The disjunction (φ∨ψ) can be defined as ¬(¬φ∧¬ψ). The implication (φ → ψ) is commonly regarded as equivalent to (¬φ∨ψ) and thus can also be defined in terms of ¬ and ∧. There are also two logic symbols that do not take any arguments: ⊤ ('top'), which means 'logically true', and its negation ⊥ ('bottom', contradiction). These symbols can be reduced in terms of ¬, ∧, and an arbitrary atomic proposition (on the assumption that Prop is nonempty). The symbol ⊤ will prove very useful in chapter 5. For the modal operators U ('universally') and ◻a ('box-a') a 'dual' operator can be defined. Thus ¬U¬ is often abbreviated as E ('somewhere') and ⋄a ('diamond-a') stands for ¬⋄a¬. In contexts where it's clear that Ind is a singleton, we sometimes omit the subscript from the box and diamond operators. It is commonplace to interpret modal logics in terms of Kripke semantics- to the extent that the terms 'modal logic' and 'Kripke semantics' are often treated as if they were synonymous. Where in non-modal propositional logic you might want to know if a wff holds in a model, in Kripke semantics you would want to know if a wff holds at a 'world' in a model. Definition 3.2. A «Kripke model» M is an lgraph such that CHAPTER 3 18 Figure 3.1. The Kripke model {⟨w⟩, ⟨w′⟩, ⟨aww⟩, ⟨aww′⟩, ⟨wp⟩, ⟨w′p⟩, ⟨w′q⟩}. Notice how ◻ap is true in w because p is a label for every world that is accessible from w over a. The formula ◻aq is false in w. Finally, ⋄a⊤ is true in w and its negation ◻a⊥ holds in w′. w p w′ p,q aa • M[???] ⊆ Ind×M[?] ×M[?] • M[??] ⊆ M[?] × Prop The nodes of a Kripke model are called «worlds», «states», or «points». The set of edges of a Kripke model is called its «accessibility relation». The «valuation» of an atomic proposition p ∈ Prop in a world w is 'true' if and only if Mwp; otherwise it is 'false'. Beware that our definition of Kripke models is slightly non-standard, as explained in section 2.3. We can now have a look at the formal semantics for the formulas in LU◻. Definition 3.3. Let the «forcing relation» «⊩» be a binary relation such that for all p ∈ Prop, a ∈ Ind, and pointed Kripke models ⟨Mw⟩ it is the case that ⟨Mw⟩ ⊩ p ⟺ Mwp ⟨Mw⟩ ⊩ ¬φ ⟺ not ⟨Mw⟩ ⊩ φ ⟨Mw⟩ ⊩ (φ∧ψ) ⟺ ⟨Mw⟩ ⊩ φ and ⟨Mw⟩ ⊩ ψ ⟨Mw⟩ ⊩ Uφ ⟺ ∀v ∈ M[?] ∶ ⟨Mv⟩ ⊩ φ ⟨Mw⟩ ⊩ ◻aφ ⟺ ∀v ∈ M[aw?] ∶ ⟨Mv⟩ ⊩ φ In a model M, a formula φ is said to be true in, hold in, or satisfied by a world w if and only if ⟨Mw⟩ ⊩ φ. The above semantics is compositional. That is to say, its truth schemas reduce the question whether or not a formula φ (in a world w) is true to CHAPTER 3 19 Table 3.1. Some of the more popular (well-behaved) frame conditions. The right-most column contains the characteristic logical truth that results when the condition holds. Name Predicate Schema Axiom Ka Always (◻a(φ → ψ) → (◻aφ → ◻aψ)) Ta Reflexive Gann (◻aφ → φ) Da Serial ∃n′ ∶ Gann′ (◻aφ → ⋄aφ) 4a Transitive Gann′ and Gan′n′′ ⟹ Gann′′ (◻aφ → ◻a◻aφ) Ba Symmetric Gann′ ⟹ Gan′n (φ → ◻a⋄aφ) 5a Euclidean Gann′ and Gann′′ ⟹ Gan′n′′ (⋄aφ → ◻a⋄aφ) the question of whether or not the 'subformulas' contained in φ are true (in worlds w′,w′′,... ). For instance, we evaluate the modal formula ◻aφ by quantifying over the worlds that are accessible from the current world over a. Specifically, ◻aφ is defined to be true if and only if φ evaluates to true in all the worlds accessible over a. The intuitive understanding of the accessibility relation depends on the application. For instance, epistemic logics are modal logics where ◻aφ is interpreted as 'agent a knows that φ'. It follows that ⋄aφ means 'for all a knows, φ is the case'. Consequently, a link ⟨aww′⟩ could be thought of as representing agent a as being unable to 'distinguish' w′ from w. In other words, as far as agent a in w can tell, she is situated in w′. We return to this issue in the next section. Depending on the application the accessibility relations are restricted in various ways (table 3.1). For instance, in epistemic logic reflexivity is imposed, which has the effect of ensuring that if ◻aφ is true in a world then so is φ. This corresponds to the notion that it is impossible to know false propositions. Of course it is possible to believe false propositions and hence in doxastic logic, in which ◻aφ is read as 'agent a believes that φ', the requirement that accessibility relations are reflexive is dropped. Instead seriality is substituted for reflexivity so that agents can believe false things but cannot believe conCHAPTER 3 20 Figure 3.2. A frame F of which the set of a-edges constitutes an equivalence relation. Every frame that is reflexive and Euclidean, or serial, symmetric, and transitive is an equivalence frame. F is also serial with respect to b. a a a,b a,b a b a tradictions. Restrictions on the accessibility relations are known as frame conditions. Definition 3.4. σ is a (universally defined) «frame condition» if and only if it is a function from indices to predicates on lgraphs and, with a any index, σ(a) is invariant under isomorphisms, changes in labeling, and changes in edges that are not a-edges. σ is a «well-behaved» frame condition if and only if any lgraph can be extended to make it σ(a)-compliant. Specifically, for any given lgraph G and index a there is an lgraph G′ ⊇ G for which σ(a) holds. Given two frame conditions σ and σ′, let σ⊔σ′ be the frame condition such that for all indices a, (σ⊔σ′)(a) holds for an lgraph if and only if σ(a) and σ′(a) hold for it. Similarly, we write σ ⊑ σ′ if and only if there is a frame condition σ′′ such that σ = σ′ ⊔σ′′. We use the notation Ka to indicate the absence of constraints on index a. Thus KaG is true for every index a and every lgraph G. Despite the abuse of terminology, we say that the frame condition σ contains no frame conditions if and only if σ(a) = Ka for every index a. In addition to the predicates in table 3.1, we will also use the predicates 'equivalence' and 'preorder'. An accessibility relation with index a is equivalent if and only if it meets Ta ⊔ 5a or Ta ⊔ 4a ⊔ Ba (which amounts to the same thing). It is a preorder relation if and only if it equals Ta ⊔4a. CHAPTER 3 21 Finally, we say that a Kripke model M is a σ-model if and only if for all a ∈ Ind it is the case that σ(a) holds for M. 3.2 Applications Modal logics have many applications. The following overview is not exhaustive. Alethic logics are logics for reasoning about logical or metaphysical possibility. Such logics have a single box operator. To put things differently, in alethic logics there is one index that represents possibility. What is true in all (accessible) possible worlds is considered necessary. Therefore ◻φ is read as 'It is necessarily so that φ' and its dual ⋄φ is read as 'It is possible that φ'. Metaphysical possibility is sometimes taken to be an equivalence relation. This means it's assumed that possibility is a reflexive, transitive, and symmetric relation. Epistemic logics allow us to reason about knowledge of one or more agents. Here, ◻aφ is read as 'Agent a knows that φ. There is much disagreement about what frame conditions are appropriate for knowledge. Sometimes equivalence is assumed, but many logicians and philosophers would argue that this assumption is too strong. The symmetry axiom (φ → ◻a¬◻a¬φ) seems particularly untenable for it implies that if φ is true then you know that you don't know ¬φ. Reading the literature it would appear thatmany logicians think knowledge is at least reflexive and transitive. Philosophers, on the other hand, sometimes argue that knowledge is not transitive. They argue that it is not the case that if you know that φ then you know that you know that φ, a principle that is also known as 'positive introspection'. A historically important defence of positive introspection can be found in [24] (chapter 5). See [39] for one powerful philosophical defense of knowledge as a modality that is not transitive. In conclusion, we want to point out that this issue is closely aligned with the internalism/externalism debate in epistemology. Doxastic logics are logics of beliefs. The most notable difference between knowledge and belief is that knowledge is factual-if it is known that φ then CHAPTER 3 22 φ must in fact be true. Belief, on the other had, allows for mistakes. It is perfectly possible to believe something that turns out to be false. Deontic logics deal with ethics, law, norms, and obligations. They encourage a reading of ◻φ as 'φ ought to be the case', 'One is obliged to do φ', 'φ is required by law', and so on. In terms of Kripke semantics it can also be read as 'φ is the case in all perfect worlds'. Temporal logics are logics for reasoning about time. Commonly two accessibility relations are used to represent time. The first one is a transitive relation that orders instances in time from old to new. On this modality ◻φ is read as 'It will always be the case that φ' and ⋄φ is read as 'φ is the case at some point in the future'. The second relation is the inverse of the first and orders instances in time from new to old. It affords statements about the past such as 'It was always the case that φ' or 'φ was true at some point'. Temporal logics often also feature more advanced expressions, such as 'φ holds until ψ becomes true'. Because a plethora of incompatible views exist on the nature of time it should not come as a surprise that logicians disagree on how to model it. For instance, is time deterministic or is it open ended? Is time continuous or is it discrete? Dynamic propositional logics (DPL) are logics for reasoning about state transitions. Thus they can be used for reasoning about computer programs, computer chips, and other state systems. In DPL ◻aφ is written as [a]φ and the index a represents a state transition. Additionally, DPL provides several operations for creating complex indices out of simple ones. Thus, for instance [a ∪ b]φ could stand for 'φ is the case after state transition a or b'. There are usually also operators for expressing sequential operation, iteration, and testing. Modal logic has also been suggested as a type system for programming languages. Type systems analyse programs for correctness and can prevent programs from running if they have type errors. Programming languages with type systems based on modal logic have been proposed. For instance, [11] presents a language for staged computing and [31] describes a programming language for safe computing with distributed resources. CHAPTER 3 23 3.3 A tableau proof system for LU◻ On encountering a well-formed formula φ, a formal logician will immediately want to know two things: • Is φ valid? • Is φ satisfiable? Definition 3.5. A well-formed formula φ is «σ-valid» if and only if for every pointedσ-model ⟨Mw⟩ it is the case that ⟨Mw⟩ ⊩ φ. The notation⊨σ φ also indicates that φ is σ-valid. σ-valid formulas are also called «σ-theorems». A wff that is not σ-valid is called «σ-invalid». Well-formed formulas that hold in at least one pointed σ-model are called «σ-satisfiable». Formulas that are not σ-satisfiable are «σ-unsatisfiable» and are also called «σ-contradictions». A wff φ is «σ-contingent» if and only if it is true in at least one pointed σ-model and false in at least one pointed model. We sometimes simply write that a formula φ is valid, invalid, satisfiable, unsatisfiable, or contingent when σ contains no frame conditions. The following proposition is the fundamental insight behind tableau proof systems. Proposition 3.1. A well-formed formula φ is σ-valid if and only if ¬φ is not σ-satisfiable. This gives rise to the following general strategy: Systematically try to construct a (pointed) model for a formula φ. If successful and if the modelconstructing system used is sound then this results in a pointed model for φ. If unsuccessful and if the model-constructing system is complete then this means that its negation is valid. Tableau systems are one way to implement this general strategy. The tableau systems we will use are based on graph-rewriting. CHAPTER 3 24 Definition 3.6. An «L-tableau» T is an lgraph with edges that are indexed by elements of Ind and with well-formed formulas of the language L for labels. When it is unambiguous what L is, we drop it as a prefix. Tableau systems are based on rules which look for patterns in a tableau and, based on the patterns they encounter, add new nodes, edges, or labels to it. We also allow rules to transform tableaux into tableaux that embed them. We can now formally define what a tableau rule is. Definition 3.7. A «tableau rule» R is a «non-destructive» relation between tableaux, meaning that with T and T ′ tableaux, if RT T ′ then T is embedded in T ′. Let Rules be the collection of tableau rules defined in table 3.2 and let Rulesσ be the largest subcollection of Rules that contains a frame condition rule RaX only if Xa ⊑ σ (where Xa is a frame condition as defined in table 3.1). In later chapters we will add further constraints to Rules. However, those rules will concern formulas outside LU◻, and as such will not affect the results in this chapter. As for R⋆, it is important to understand that it can be used to merge nodes, add nodes and edges, add literals to nodes, and rename nodes. One purpose of R⋆ is to help us turn those situations where the tableau rules conspire to create acyclic never-ending paths around by transforming these paths into loops. We will find additional uses for R⋆ in later chapters. One interesting property of the mandatory rules of Rules-where R⋆ is the only optional or non-mandatory rule-is that they are non-destructive in a strong sense. Proposition 3.2. If R is a mandatory rule of Rules then, with T and T ′ tableaux, if RT T ′ then T ⊆ T ′. The mandatory rules also have the property that they add at most three elements to the tableau. Proposition 3.3. If R is a mandatory rule of Rules then, with T and T ′ tableaux, if RT T ′ then the cardinality of T ′ − T is at most 3. CHAPTER 3 25 T able 3.2.The tableau rules in schem atic form .Form ulas R ¬ to R ⋄ acton the presence ofform ulas in the tableau.The rules R aT to R a5 dealw ith fram e conditions. These schem as should be interpreted as follow s: W ith T and T ′tableaux and R one of the rules below ,R T T ′ifand only if T m eets the precondition and T ′is a m inim alextension of T thatm eets the postcondition. N am e Precondition Postcondition R ¬ T n ¬ ¬ φ T ′n φ R ∧ T n (φ ∧ ψ ) T ′n φ and T ′n ψ R ∨ T n ¬ (φ ∧ ψ ) T ′n ¬ φ or T ′n ¬ ψ R U T n U φ and T n ′ T ′n ′φ R E T n ¬ U φ and T [?¬ φ ] = ∅ T ′n ′and T ′n ′¬ φ for som e new n ′∈ N R ◻ T an n ′and T n ◻ a φ T ′n ′φ R ⋄ T n ¬ ◻ a φ and T [an ?]∩ T [?¬ φ ] = ∅ T n ′,T ′an n ′, and T ′n ′¬ φ for som e new n ′∈ N R aT T n T ′an n R aD T n and T [an ?] = ∅ T ′n ′and T ′an n ′for som e new n ′∈ N R a4 T an n ′and T an ′n ′′ T ′an n ′′ R aB T an n ′ T ′an ′n R a5 T an n ′and T an n ′′ T ′an ′n ′′ R ⋆ A nytim e / O ptional A ny non-destructive transform ation Moreover, whenever a mandatory rule of Rules is triggered to add a formula φ to the tableau, φ is shorter than the formula that triggered the rule. Definition 3.8. A tableau rule R is «reductive» if and only if, given any two tableaux T and T ′, if RT T ′ then for all ⟨nφ⟩ ∈ T ′ − T it is the case that there is a node-label pair ⟨n′ψ⟩ ∈ T such that |φ| ≤ |ψ|. Proposition 3.4. All mandatory rules of Rules are reductive. To further aid our understanding of the tableau rules it may be instructive to reflect on the following situations. Example. Given a tableau T and a tableau rule R, we make a distinction between the following cases: • R[T ?] = ∅. For the rules in table 3.2 this occurs when the precondition does not match a pattern in T . • RT T . If R is a rule of table 3.2 then this means R has already been applied to T . • R[T ?]−{T } ≠ ∅. This indicates that R can be applied to T to produce a new tableau. • {T ′,T ′′} ⊆ R[T ?] − {T } and T ′ ≠ T ′′. Here T ′ and T ′′ are two branches. In other words, they represent two possible outcomes of applying R to T . It is important to realize that the cases R[T ?] = ∅ and R[T ?] = {T } have the same effect: R cannot be used to transform T into a new tableau. Tableaux represent (partial) attempts at constructing a model that satisfies a certain formula. We now define terminology for describing this process. Definition 3.9. A tableau T ′ is a «σ-development» of a tableau T if and only if it is either an element of or the limit of a sequence T ,... ,T i,T i+1,... such CHAPTER 3 27 that for every T i+1 in the sequence there is an R ∈ Rulesσ such that RT iT i+1 and T i ≠ T i+1. A tableau T is a σ-tableau «for» ⟨nφ⟩ if and only if (i) T nφ and (ii) T is a σ-development of a tableau T 0 ≔ {⟨n′⟩, ⟨n′φ⟩} (for some n′). We sometimes also say that a tableau T is a σ-tableau for φ if and only if there is an n such that T is a σ-tableau for ⟨nφ⟩. Proposition 3.5. If T is a σ-tableau for φ then any σ-development of T is a σ-tableau for φ. We now introduce the notion of saturation to indicate that all mandatory rules have been applied to a tableau. In other words, saturated tableaux are tableaux that cannot be changed further by mandatory rules. Definition 3.10. A tableauT is said to be «R-saturated» if and only ifR[T ?]− {T } = ∅. With σ a frame condition, a tableau is said to be «σ-saturated» if and only if it is R-saturated for all mandatory rules R ∈ Rulesσ. Finally, a tableau is said to be «saturated» if and only if it is R-saturated for all mandatory rules R ∈ Rules that act on the presence of formulas. To be clear, saying that a tableau is saturated is synonymous with saying it is Ka-saturated. For every tableau there is a σ-saturated extension. Proposition 3.6. If S = T 0,... ,T i,T i+1,... is a sequence of tableaux such that for every T i+1 in the sequence there is a mandatory rule R ∈ Rulesσ such that RT iT i+1 then there is a σ-saturated tableau T that S converges to (in the limit). Proof. By propositions 3.2 and 3.3, S is a countable sequence of sets ordered by the subset relation. Therefore the limit of S equals ⋃S. This proves that T exists. By construction of S it also follows that T is σ-saturated. When we want to (try to) construct a σ-model for a formula φ, we will first construct a tableau {⟨n⟩, ⟨nφ⟩} (for some n). Next, we apply the mandatory rules from Rulesσ until we arrive at a σ-saturated tableau T ′. Finally we check if the tableau we found can be transformed into a model. CHAPTER 3 28 Definition 3.11. A tableau T contains a «literal contradiction» if and only if there is a node n and an an atom p ∈ Prop such that T np and T n¬p. Otherwise T is free of literal contradictions. Rather than speak of tableaux free of literal contradictions, it is customary to instead say that we are looking for 'open' saturated tableaux. Definition 3.12. An LU◻-tableau is «open» if and only if it doesn't contain literal contradictions. If a tableau is not open then it is «closed». For now no distinction is made between tableaux free of literal contradictions and open tableaux. Nevertheless, such a distinction exists for the tableaux for dynamic modal logics that we will discuss in subsequent chapters. We now turn to proving soundness. We want it to be the case that if all σ-saturated tableaux for φ are closed then no σ-model exists in which φ is true (at some world). We will prove the contrapositive-if there's a σ-model for φ then there's an open σ-saturated tableau for φ. First, we define what models a tableau can be said to represent. Definition 3.13. A model M «satisfies» a tableau T up to φ via a function f ∶ T [?] → M[?] if and only if 1. T nψ ⟹ ⟨Mf(n)⟩ ⊩ ψ 2. T ann′ ⟹ Maf(n)f(n′) for all ψ such that |ψ| ≤ φ. We simply say that M satisfies T (via f) if and only if M satisfies T (via f) up to arbitrary formulas. Finally, we say that M «natively satisfies» T if and only if M satisfies T via the identity function. Suppose there is a σ-model M such that ⟨Mw⟩ ⊩ φ. It is easy to see that the tableau {⟨n⟩, ⟨nφ⟩} is satisfied by M via the function that maps n onto w. Let this be the base step. Next, let T be any tableau that is satisfied by CHAPTER 3 29 Figure 3.3. Proof that (p → ◻a⋄ap) is Ba-valid. As a preliminary, we eliminate the operators → and ⋄a since they are not primitives of LU◻. This yields the formula ¬(p∧¬◻a¬◻a¬p). Next, we attempt to construct an open Ba-saturated tableau for its negation (for ease of presentation we remove the sequence ¬¬). However, we discover that we inevitably run into a literal contradiction. This proves that (p → ◻a⋄ap) is Ba-valid. (p ∧¬◻a¬◻a¬p) p ¬◻a¬◻a¬p Apply R∧ (p ∧¬◻a¬◻a¬p) p ¬◻a¬◻a¬p ¬¬◻a¬p a Apply R⋄ (p ∧¬◻a¬◻a¬p) p ¬◻a¬◻a¬p ¬¬◻a¬p ◻a¬p a Apply RaB and R¬ (p ∧¬◻a¬◻a¬p) p ¬◻a¬◻a¬p ¬p ¬¬◻a¬p ◻a¬p a Apply R◻ M. We want to show that, for any mandatory rule R ∈ Rulesσ, if there is an R-development of T then there is an R-development of T that is satisfied by M. Lemma 3.7 (Basic Lemma to Soundness). Let T be a tableau that is satisfied by a σ-model M via a function f. For every R ∈ Rulesσ such that T is not R-saturated it is then the case that there is a tableau T ′ ∈ R[T ] − {T } and a function f′ such that M satisfies T ′ via f′. Proof. Suppose a rule is triggered by T nφ. CHAPTER 3 30 • If φ is ¬¬ψ or (ψ∧χ) then T ′ is uniquely determined and T ′ has the same frame as T . Let f′ ≔ f. • Suppose φ is ¬(ψ∧χ). By definition of ∧ and ¬ either ⟨Mf(n)⟩ ⊩ ¬ψ or ⟨Mf(n)⟩ ⊩ ¬χ. Let T ′ = T ∪ {⟨n¬ψ⟩} or T ′ = T ∪ {⟨n¬χ⟩} accordingly and let f′ ≔ f. • If φ equals Uψ then T ′ = T ∪ {⟨n′ψ⟩} for some n′ ∈ T [?]. By definition of U, however, ⟨Mf(n′)⟩ ⊩ ψ. Thus, let f′ ≔ f. • If φ equals ¬Uψ then it is the case that T ′ = T ∪ {⟨n′⟩, ⟨n′¬ψ⟩} for some n′ ∉ T [?]. Since ⟨Mf(n)⟩ ⊩ ¬Uψ it follows that there is a w such that Mw and ⟨Mw⟩ ⊩ ¬ψ. Hence, let f′ be the smallest extension of f such that f′(n′) = w. • Suppose φ is ◻aψ. This could yield a tableau T ′ ≔ T ∪ {⟨n′ψ⟩}, for some n′ ∈ T [an?]. By definition of ◻a it is so that ⟨Mn′′⟩ ⊩ φ for every n′′ ∈ M[af(n)?]. Since for every n′′′ ∈ T [an?] it is the case that Maf(n)f(n′′′) it follows that M satisfies T via f; thus let f′ ≔ f. • Suppose φ is ¬◻aψ. This means T ′ = T ∪ {⟨n′⟩, ⟨ann′⟩, ⟨n′¬ψ⟩} for some n′ ∉ T [?]. Since ⟨Mf(n)⟩ ⊩ ¬◻aψ there is a w such that Maf(n)w and ⟨Mw⟩ ⊩ ¬ψ. Thus let f′ be the smallest extension of f such that f′(n′) = w. Suppose a tableau T ′ is the result of applying a rule R for enforcing frame conditions. • If R is an instance of RaT, Ra4, RaB, or Ra5 then let f′ ≔ f. • If R is an instance of RaD then it is assumed that the model M is serial. This implies that there is a a w such that Maf(n)w. Thus, let T ′ ≔ T ∪ ⟨ann′⟩ (with n′ ∉ T [?]) and let f′ be the smallest extension of f such that f′(n) = w. Theorem 3.8 (Soundness). Given some φ ∈ LU◻, if all σ-saturated tableaux for φ are closed then ⊨σ ¬φ. CHAPTER 3 31 Proof. We prove the contrapositive-viz. that if there is a pointed σ-model ⟨Mw⟩ such that ⟨Mw⟩ ⊩ φ then there is an open saturated σ-tableau T for ⟨wφ⟩. Evidently, the pointed model ⟨Mw⟩ natively satisfies the tableau {⟨w⟩, ⟨wφ⟩}. By repeatedly applying lemma 3.7 it follows, by proposition 3.6, that there is a saturated open σ-tableau for ⟨wφ⟩ that is satisfied by M via some function. Because it is satisfied by a model it also follows that the tableau is free of literal contradictions and that it is open since an atom cannot be both true and false in a single point in a model. Our next task is to prove that our tableau method is complete. We would like it to be the case that if a tableau T for φ is σ-saturated and open then we can transform T into a σ-model for φ. Here's what we will treat as the orthodox transformation of a tableau into a model. Definition 3.14. A model M is the «stock model» of a tableau T if and only if • M[?] = T [?] • M[???] = T [???] • M[??] = T [??] ∩ (T [?] × Prop) We now prove that if M is the stock model of an open saturated tableau T then M satisfies T . Lemma 3.9 (Basic Lemma to Completeness). Let T be any open saturated tableau. If T nφ then, with M the stock model of T , ⟨Mn⟩ ⊩ φ. Proof. Proof by induction. By induction hypothesis (IH) it is assumed that the lemma holds for all ψ shorter than φ. • Suppose φ is an atom. It is then the case that T nφ. Because M is the stock model of T it follows that ⟨Mn⟩ ⊩ φ. CHAPTER 3 32 Figure 3.4. We use the tableau system to contruct a pointed (Ta ⊔ 4a)-model for (¬◻a◻ap ∧ ◻aq). We start with a tableau that consists of a single node and a single label. Next, we repeatedly apply the mandatory tableau rules. Because the final, (Ta ⊔ 4a)-saturated, tableau is open we can convert it into a (Ta ⊔ 4a)-model M by deleting all labels that are not atoms. It can be verified that ⟨Mn⟩ ⊩ (¬◻a◻ap∧◻aq). n (¬◻a◻ap∧◻aq) ¬◻a◻ap ◻aq Apply R∧ n (¬◻a◻ap∧◻aq) ¬◻a◻ap ◻aq ¬◻ap a Apply R⋄ n (¬◻a◻ap∧◻aq) ¬◻a◻ap ◻aq ¬◻ap ¬p a a Apply R⋄ n (¬◻a◻ap∧◻aq) ¬◻a◻ap ◻aq ¬◻ap ¬p a a a a a a Apply RaT and Ra4 n (¬◻a◻ap∧◻aq) ¬◻a◻ap ◻aq q ¬◻ap q ¬p q a a a a a a Apply R◻ n q q q a a a a a a Stock model M • Suppose φ is ¬p (with p ∈ Prop). Since T is an open tableau it is then not the case that T np. Since M is the stock model of T it follows that not ⟨Mn⟩ ⊩ φ. • Suppose φ is ¬¬ψ. By R¬, since T is saturated, it is the case that T nψ. By IH it follows that ⟨Mn⟩ ⊩ ψ. By definition of ¬ it now also follows that ⟨Mn⟩ ⊩ ¬¬ψ. • Suppose φ is (ψ ∧ χ). By R∧ it is the case that T nψ and T nχ. By induction hypothesis it follows that ⟨Mn⟩ ⊩ ψ and ⟨Mn⟩ ⊩ χ. By definition of ∧ this entails that ⟨Mn⟩ ⊩ (ψ∧χ). • Suppose φ is ¬(ψ∧χ). By R∨ either T n¬ψ or T n¬χ. In the first case, by IH, ⟨Mn⟩ ⊩ ¬ψ. In the second case ⟨Mn⟩ ⊩ ¬χ for the same reason. By definition of ∧ and ¬ it follows that ⟨Mn⟩ ⊩ ¬(ψ∧χ). • Suppose φ is Uψ. It is then the case that T n′ψ for all n′ ∈ T [?]. By IH it follows that ⟨Mn′⟩ ⊩ ψ for all n′ ∈ T [?]. By definition of U it now follows that ⟨Mn⟩ ⊩ Uψ. • Suppose φ is ¬Uψ. There is then an n′ ∈ T [?] such that T n′¬ψ. By IH it is also the case that ⟨Mn′⟩ ⊩ ¬ψ. Finally, by definition of ¬ and U it follows that ⟨Mn′⟩ ⊩ ¬ψ. • Suppose φ is ◻aψ. For all n′ such that T ann′ it is the case that (i) T n′ψ (by R◻), (ii) ⟨Mn′⟩ ⊩ ψ (by IH), and (iii) Mann′ (since M is the stock model of T ). By definition of ◻a it follows that ⟨Mn⟩ ⊩ ◻aψ. • Suppose φ is ¬◻aψ. By R⋄ it is the case that T n ′¬ψ and T ann′ for some n′. By IH it follows that ⟨Mn′⟩ ⊩ ¬ψ. Finally, it is a consequence of the definition of ¬ and ◻a that ⟨Mn⟩ ⊩ ¬◻aψ. Theorem 3.10 (Completeness). If ⊨σ ¬φ (with φ ∈ LU◻) then all saturated σ-tableaux T for φ are closed. Proof. Again we prove the contrapositive: If there is an open σ-saturated tableau T for ⟨nφ⟩ then there's a σ-model M such that ⟨Mn⟩ ⊩ φ. CHAPTER 3 34 Let M be the stock model of T . By lemma 3.9 it immediately follows that ⟨Mn⟩ ⊩ φ. That M is a σ-model follows from the definitions of the frame condition rules. 3.4 Decidability of LU◻-tableaux The above soundness and completeness results entail that if we possessed infinite computing power, our tableau system could tell us if a formula was valid, unsatisfiable, or contingent. We now build on these results and show that even with finite computing time we can decide whether or not a formula is satisfiable. This is all we need because if a formula is unsatisfiable then by extension its negation is valid. Additionally, if a formula and its negation are satisfiable then it is contingent. To make the search for a saturated open tableau terminate after a finite number of steps we need to keep an eye out for redundant copies of nodes and replace them by loops. First, we devise a formal method for summing up the constraints that are imposed on a tableau node n by ◻a-formulas. Definition 3.15. Given a tableau T and a node n ∈ T [?], define «◻Ta (n)» ≔ {φ ∣ ∃n′ ∈ T [a?n] ∶ T n′◻aφ}. We can now specify what makes for a virtual loop and a redundant copy. Definition 3.16. Given a tableau T , a «virtual a-loop» (in T ) from n0 to nl is a sequence S = n0,... ,ni, ni+1,...nl such that • For every ni+1 in the sequence it is the case that T anini+1. • All links between nodes in the sequence are a-links. • There is a set of formulas F such that for every ni in the sequence, ◻Ta (ni) = F. • nl has no outgoing links. CHAPTER 3 35 Figure 3.5. If we were to iteratively 4a-develop the tableau T on the left in a naive way, we would be constructing a countably infinite tableau. However, notice that S ≔ n,n′ is a virtual a-loop and that T is in fact ⌊4a⌋-saturated. Thus, given that S is the only virtual loop in T , we can construct a 4a-saturated tableau by folding S in T . n ¬p ¬◻ap ◻a¬◻ap n′ ¬p ¬◻ap a n ¬p ¬◻ap ◻a¬◻ap a • All labels of nl are labels of n0 (i.e. T [nl?] ⊆ T [n0?]). A node n′ is called a «copy» of a node n (in T ) if and only if there is a virtual a-loop (for some a) from n to n′ (in T ). Notice that the fact that nl has no outgoing links implies that n0 ≠ nl. As we will see shortly, in certain unsaturated tableaux it is necessary to replace the virtual loops by actual loops in order to ensure that the further development of these tableaux eventually terminates. To this end our general strategy is to block rules from adding outgoing links to copies. When the only rules that remain to be applied are those that would add outgoing links to copies, we transform the virtual loops into actual loops. We now revise some notions relating to rule application such that rules do not add outgoing links to copies. Definition 3.17. Given a tableau rule R, let «⌊R⌋» be such that for any two tableaux T and T ′ it is the case that ⌊R⌋T T ′ if and only if • RT T ′. • There is no edge ⟨ann′⟩ ∈ T ′[???] − T [???] where n is a copy of another node in T (based on any b-loop). A tableau T ′ is a «⌊σ⌋-development» of a tableau T if and only if it is either an element of or the limit of a sequence T ,... ,T i,T i+1,... such that for every T i+1 in the sequence there is a rule R ∈ Rulesσ such that ⌊R⌋T iT i+1 and T i ≠ T i+1. CHAPTER 3 36 Figure 3.6. The tableau T below is but one edge away from being (4a ⊔ 5a)-saturated (although some labels have been omitted). Nonetheless, it's instructive to check if S = n,n′ is a virtual a-loop. The answer is no. S is not a virtual a-loop because ◻Ta (n) ≠ ◻Ta (n′). Indeed, suppose that S was folded. The resulting tableau would no longer have a node n′ and the a-edge from m to n′ would have been replaced by an a-edge from m to n. Thus, by Ra4 an a-link from m to m would have to be added. Subsequently, by R◻, the label ¬p would have to be added to m. This, however, introduces a literal contradiction. n ¬◻ap ¬p ¬◻a¬(p∧◻a¬p) n′ ¬p m p ◻a¬p a a a A tableau T is «⌊σ⌋-saturated» if and only if for all mandatory rules R ∈ Rulesσ it is the case that T is ⌊R⌋-saturated. Finally, we define the embedding that transforms virtual a-loops into actual loops. Definition 3.18. T ′ is the result of «folding» a virtual a-loop S from n to n′ in a tableau T if and only if, with h ∶ T [?] → T [?]−{n′} such that h(n′) = n and h(x) = x for all x ≠ n′, it is the case that • T ′[?] = T [?] − {n′} • T ′[???] = {⟨ah(m)h(m′)⟩ ∣ T amm′} ∪ ({a} × I ×O), where – I ≔ {h(m) ∣ ∃ni ∈ S ∶ T amni} – O ≔ {h(m) ∣ ∃ni ∈ S ∶ T anim} CHAPTER 3 37 Figure 3.7. The tableau T on the left is a 4a-developed tableau. Notice that T has an a-loop S = n,n′, n′′. The tableau T ′ on the right is the folding of S in T . T ′ has four new edges. The edges from n and n′ to n are straightforward to explain: They are a result of remapping n′′ onto n. The edges from n′ to n′ and to m are more interesting. They were added because (i) in T there was an a-edge from n′ to a node of S (viz. n′′) and (ii) in T there was an a-edge from a node of S to n′ and from a node of S to n′′ (in both cases this node was n). Without these new edges T ′ would no longer have been closed under transitivity. n¬p ¬◻a◻ap ¬◻aq n′ ¬◻ap n′′ ¬p m ¬q a a a a n¬p ¬◻a◻ap ¬◻aq n′ ¬◻ap m ¬q a a a a a • T ′[??] = {⟨h(m)φ⟩ ∣ T mφ} It is particularly important to notice that an a-edge is created between (i) every node mI that has an outgoing a-edge to a node of S and (ii) every node mO that has an incoming a-edge that originates from a node of S. Figure 3.7 illustrates how this works. The following insight is crucial, for it entails that by repeatedly applying folding, a ⌊σ⌋-saturated tableau can be turned into a σ-saturated tableau. Lemma 3.11 (Folding Lemma). If T ′ is the result of folding a virtual a-loop S in a ⌊σ⌋-saturated tableau T then T ′ is ⌊σ⌋-saturated. Proof. We need to show that for every mandatory rule R ∈ Rulesσ it is the case that T ′ is ⌊R⌋-saturated. • If R is R¬, R∧, R∨, RU, or RE then T ′ is ⌊R⌋-saturated since no labels were added or removed, and no nodes were added. CHAPTER 3 38 • Suppose R equals R◻ and is applied to the tuples ⟨bnn′⟩ and ⟨n◻bφ⟩ in T ′. We distinguish two cases. – If T bnn′ then it must already have been the case that T n′φ since T is ⌊R◻⌋-saturated. This also deals with all cases where b ≠ a since only a-edges where added or moved. – Suppose b = a and not T ann′. It follows that n has an a-link to an element of S in T and that there is an element of S that has an a-link to n′ in T . This, however, implies that ◻Ta (n) ∪ {φ ∣ T n◻aφ} ⊆ ◻Ta (n′). Consequently, there is nothing for ⌊R◻⌋ to do since T is already ⌊R◻⌋-saturated. • Suppose R is R⋄ and is applied to the node-label pair ⟨n⋄bφ⟩ in T ′. We distinguish three cases. – Suppose n is not a copy in T . Since T is ⌊σ⌋-saturated this means that there is an n′ such that T bnn′ and T n′φ. This edge and label would then also be in T ′ and hence there is nothing for ⌊R⋄⌋ to do. – Suppose n is not in the sequence S but n is a copy of another node. In this case n must be part of a virtual c-loop S′. It is possible that a new link was created from a node n′′ of S to an element n′ of S′. However, in this case ◻Ta (n′′) ⊆ ◻Ta (n′) since there must already have been a link from an element of S to n′. Hence n is still a copy in T ′. – Suppose n is the last element of S and thereby is a copy. n is then remapped to the first element of S. This case is thereby analogous to the first case, where n is not a copy. Notice that no other element of S can be a copy. • Suppose R is RbT. Trivially, because T is ⌊σ⌋-saturated so is T ′. • Suppose R is RbD. This is similar to the case R⋄. CHAPTER 3 39 • Suppose R is Rb4 . If T ′bnn′ and T ′bn′n′′ then we need to prove that T ′bnn′′. – Suppose both T bnn′ and T bn′n′′. It is then already the case that T bnn′′ since T is ⌊Rb4⌋-saturated and n is not a copy. Notice that this case subsumes the case where b ≠ a. – Suppose neither T ann′ nor T an′n′′. By construction of T ′ it must then be the case that n′ ∈ S and that there is an a-link in T from n to a node in S and an a-link from a node in S to n′′. By construction of T ′ it follows that T ′ann′′. – Suppose T ann′ but not T an′n′′. It follows that there is an a-link from n′ to an element of S and that there is an a-link in T from an element in S to n′′. By ⌊Ra4⌋ it follows that there is an a-link in T from n to an element of S. By construction of T ′ it now follows that T ′nn′′. – Suppose not T ann′ but T an′n′′. It follows that there's an a-link from n to an element of S and that there is an a-link from an element of S to n′. By ⌊Ra4⌋ it follows that there are a-links from elements of S to n′′ in T . By construction of T ′ it now follows that T ′nn′′. • Suppose R is RbB. We need to demonstrate that if T ′bnn′ then T ′bn′n. Suppose T bnn′. In this case T bn′n by ⌊RbB⌋. Hence T ′bn′n by construction of T ′. This also covers the case where b ≠ a. If not T ann′ then there must be {m,m′} ⊆ S such that T anm and T am′n′. By ⌊RaB⌋ it is then also the case that T amn and T an′m′. It follows by construction of T ′ that T ′an′n. • Suppose R is Rb5 . We have to show that if T ′bnn′ and T ′bnn′′ then T ′bn′n′′. CHAPTER 3 40 – Suppose T bnn′ and T bnn′′. By ⌊Rb5⌋ it is then the case that T bn′n′′. Hence T ′bn′n′′ by construction of T ′. This also covers all cases where b ≠ a. – Suppose neither T ann′ nor T ann′′. By construction of T ′ it follows that there are m′ and m′′ in S such that T am′n′ and T am′′n′′. Moreover m′ (like m′′) is not the last element of S since it has outgoing links. This also implies that m′ has an a-link to an element of m⋆ of S. By ⌊Ra5⌋ it follows that T an′m⋆. Finally, since there are a-links in T from n′ to an element of S and from an element of S to n′′ it follows that T ′an′n′′. – Suppose T ann′ but not T ann′′. By construction of T ′ it follows that there are m and m′′ in S such that T anm and T am′′n′′. By ⌊Ra5⌋ it also follows that T an′m. It can now be seen that T ′n′n′′ by construction of T ′. – The case where T ann′′ but not T ann′ is entirely analogous to the previous one. The tableau method described in this chapter-including folding-is decidable. To understand why let us partition the mandatory tableau rules in two parts. The first kind of rules are those rules that add new formulas. These rules only propagate formulas that are shorter than the formulas that are already present in the tableau, however, and this places a bound on the number of distinct formulas in a tableau. The second kind of rules are rules that create new links and do not add new formulas. These rules only allow limited interaction between nodes that are connected over different indices, as is illustrated in figure 3.8. This implies that as formulas are propagated over differently indexed links, they decrease in length. This imposes a bound on the number of alternating indices in a chain of nodes. These insights lead to the following theorem. Theorem 3.12. If there is a pointed σ-model ⟨Mw⟩ such that ⟨Mw⟩ ⊩ φ (where φ ∈ LU◻) then an open saturated σ-tableau T for ⟨wφ⟩ can be found in a finite number of steps. CHAPTER 3 41 Figure 3.8. Tableaux produced by the mandatory rules lead to clusters of nodes connected by the same index. Any two clusters can interact only to a limited extend via a single node that connects those two clusters. This is the case because every tableau rule contains at most one index. In the diagram below no new links (ignoring reflexive links) can be added using mandatory rules. a a a b b b b b b a c Proof. The procedure for finding the tableau is as follows. Start with the tableau T = {⟨w⟩, ⟨wφ⟩}. Fairly apply the mandatory rules of Rulesσ until an open ⌊σ⌋-saturated tableau T ′ is found. Fair application means that all rules must be used (insofar they are applicable) and that it's not allowed to use a limited selection of rules to the exclusion of others. Next, repeatedly apply folding until there are no more virtual loops. Notice that for all ⟨nψ⟩ ∈ T ′ it is the case that |ψ| ≤ |φ|. Hence there's only a finite number of possible label-sets. Because there are only a finite number of possible label-sets, R⋄ can only attach a finite number of new links to any existing node n. The rule RaD is similarly conservative. Consequently, the only way to indefinitely expand a tableau using the mandatory rules of Rulesσ, is to create longer and longer chains of nodes. However, the mandatory rules are such that for any two indices a and b such that a ≠ b, if you take a set of nodes A that are connected by a-edges and another set of nodes B that are connected by b-edges then there is at most one node n ∈ A such that there are b-edges between n and nodes of B (in either direction). In other words, differently indexed modalities do not interact. Moreover, if such ann ∈ A exists then there are no a-edges between nodes CHAPTER 3 42 of A and nodes of B. In fact, for any c ≠ b it is the case that there are no c-edges between nodes of A and B. It follows that either • For all labels φ of nodes in B there is a label ψ of a node in A such that |ψ| > |φ|. This happens when a node of A was added before any of the nodes of B were added. • The same is true when substituting A for B and B for A. Thus there is a finite limit to the number of index alternations in a path. It only remains to be shown that, for any index a, there is an upper bound to the length of a-paths before there are no more mandatory rules to apply or before a virtual a-loop is encountered. It is easy enough to see that only a combination of R⋄ or R a D, R◻, and Ra4 or Ra5 could lead to problematic paths. However, notice that the possible extensions for ◻T ′a (n) are restricted by φ similar to how the possible label-sets are restricted by φ. Moreover, if σ includes Ra4 or Ra5 then ◻T ′ a (n) ⊆ ◻T ′ a (n′) if there's an a-path from n to n′. Consequently, any sufficiently long a-path is repetitive in a way that can be dealt with by the process of folding. 3.5 Related work Saul Kripke introduced tableau systems for modal logic alongside Kripke semantics in [26,27]. In these papers he presents three approaches for dealing with modal languages that do not have an operator U and are not multiply indexed. Kripke sometimes uses different terminology than we are using now. For instance, what we call a 'tableau' roughly corresponds to what Kripke calls an 'alternative set of tableaux'. In turn, the tableau nodes of our system correspond to Kripke's 'tableaux'. In our sketch of Kripke's tableau systems we use the same terminology used throughout this chapter and ignore Kripke's usage of the term 'tableau'. CHAPTER 3 43 Kripke's first approach is limited to models with equivalence frames. Due to this restriction all nodes in a tableau can be thought of as being implicitly linked, and thus there is no need for edges in tableau structures. The second approach is similar to the path taken in this chapter. Kripke adds an accessibility relation R to his tableau structures. The rules for ◻-formulas (and their negation) are similar to the rules in definition 3.7. There are no explicit rules for closing tableau frames under the desired frame conditions σ. Instead, Kripke merely stipulates that R is closed under σ. The effect is almost the same. However, recall that our notions of ⌊⌋-development and ⌊⌋-saturation required blocking the creation of new links under certain conditions. This is not possible in Kripke's system. Tellingly, Kripke gives no decidable proof procedure for this tableau system. Instead he describes a third approach. On Kripke's third approach there is again a relation R but it is not closed under any relational properties. Hence R is always a tree structure, which makes it easier to create a decidable proof procedure. Indeed, on this approach a loop is simply a sequence of two nodes n,n′ such that Rnn′ and such that every label of n′ is also a label of n. The downside of this approach is that the rule R◻ needs to be modified in accordance with the chosen frame conditions. For example, this is the rule for serial and transitive tableaux: If n has a label ◻φ then the label φ is added to n and ◻φ is added to all nodes accessible from n. Finally, on this approach a stock model's frame is obtained by closing the tableau's frame under the desired frame conditions. In the literature Kripke's third approach has perhaps won out over his second approach. There are other approaches but they widen the gap between Kripke models and tableau structures even further. See [10] for a general overview of tableau systems. An interesting development occurs in [9,15]. In these papers tableau structures are represented by labeled graphs that are rooted and acyclic but not necessarily tree structures. This enables the authors to use a mixture of Kripke's second and third approach. They still use the third approach where convenient, but use rules of the second kind for seriality, denseness, and confluence. Using this approach they construct an extensible tableau system CHAPTER 3 44 that can handle many combinations of frame conditions for modal languages without the operator U. In [14,19] a software application named Lotrec is presented that builds on these results. Lotrec implements an extensible tableau system and is able to automatically construct models and prove theorems. This dissertation may be understood as a continuation of Kripke's second approach, using techniques from [9, 15]. With respect to the usability and ease of understanding of tableau systems, we believe this to be a superior approach. Finally, the reader interested in learning more about modal logic might find it useful to start with [7,25]. To learn about the history of modal logic, consult [21]. See [16] to learn more about proof systems for modal logic. CHAPTER 3 45 4 Public Announcement Logic In the previous chapter we saw that modal logic can be interpreted in a variety of ways. In this chapter we discuss an extension of modal logic where the modal operators are interpreted in epistemic terms. Public announcement logic (PAL) can be classified as a dynamic modal logic. It is 'dynamic' in two ways. First, it has an operator for representing events-public announcements-where all agents become aware of a certain fact. Thus the knowledge of agents in PAL is not static but dynamic-agents can learn. Second, the language of PAL L◻! has a dynamic semantics. As before, static formulas of L◻! are interpreted on Kripke models. Dynamic formulas, however, are reduced to simpler formulas which are then evaluated in models updated with the information that was publicly announced. These updated models are a function of the original model and the dynamic formula. When discussing PAL it is customary to assume the frame conditionsσ are such thatσ(a) (where a ∈ Ind) holds for a modelM if and only if the a-frame of M is an equivalence frame. That is, it is assumed that σ(a) = Ta ⊔5a or σ(a) = Ta ⊔4a ⊔Ba. There is, however, no technical requirement for this to be the case. 4.1 L◻! and its dynamic semantics Definition 4.1. The language of public announcements L◻! is the set of formulas φ recursively defined as follows: φ ::= p ∣ ¬φ ∣ (φ∧φ) ∣ ◻aφ ∣ [!φ]φ, Figure 4.1. The model M (left) and the updated model M|!(p∨q) (right). The updated model contains exactly those worlds x such that ⟨Mx⟩ ⊩ (p∨ q). All model diagrams in this section should be interpreted as having transitive and reflexive a-edges. w p,q w′p w′′ q w′′′ a a a w p,q w′p w′′ q a a with p any element of the set of atomic proposition Prop and a a member of the set of agents Ind. Read ◻aφ as 'agent a knows that φ' and read [!φ]ψ as 'ψ is true after it is truthfully and publicly announced that φ is the case'. Implicitly, we defined a forcing relation in definition 3.3 not only for LU◻, but for any language that has compositional semantics that fit in the following schema: φ ::= p ∣ ¬p ∣ (φ∧φ) ∣ Uφ ∣ ◻aφ ∣ ... , where p ∈ Prop and a ∈ Ind. In other words, our definition for ⊩ was open ended. As such, we now define the semantics for L◻! by retroactively adding one more constraint to this relation. Definition 4.2. The forcing relation «⊩» is a relation that meets the stipulations of definition 3.3 in addition to the following constraint: ⟨Mw⟩ ⊩ [!φ]ψ ⟺ if ⟨Mw⟩ ⊩ φ then ⟨M|!φw⟩ ⊩ ψ, where M|!φ ≔ M∩ ({⟨w′⟩ ∣ w′ ∈ W′} ∪ (W′ × Prop) ∪ (Ind×W′ ×W′)) , CHAPTER 4 47 Figure 4.2. The very act of announcing a formula φ can sometimes make φ false. For instance, the Moore sentence 'p, but you don't know that p' is false after it is truthfully announced. To wit, after I inform you that, even though you don't know it, it is raining outside, you will in fact know that it is raining outside. This phenomenon can be expressed in L◻!. Let M be the model on the left. It is the case that ⟨Mw⟩ ⊩ (p∧¬◻ap). However, it is not the case that ⟨Mw⟩ ⊩ [! (p ∧¬◻ap)](p∧¬◻ap) since ⟨M|!(p∧¬◻ap)w⟩ ⊩ ◻ap. w p w′ a w p and W′ ≔ {w′ ∈ M[?] ∣ ⟨Mw′⟩ ⊩ φ}. Intuitively, M|!φ is the model that results from deleting all worlds in which φ does not hold. 4.2 Dynamic tableaux We now extend the tableau system of LU◻ in three steps. First, we add a tableau rule for public announcements. Definition 4.3. Let Rules and Rulesσ be as in definition 3.7, except they also contain the tableau rule R! from table 4.1. Second, we define the relation !φ −→ between tableaux. This relation serves as a counterpart of |!φ in the sense that T !φ −→ T ′ signifies that T ′ is the result of updating T with the fact that φ was publicly revealed. Definition 4.4. Given a wff φ and two tableau T and T ′, let «T !φ −→ T ′» if and only if • T ′[?] = T [?φ] • T ′[???] = T ∩ (Ind×T [?φ] × T [?φ]) CHAPTER 4 48 Table 4.1. Public announcement logic necessitates one new tableau rule. Upon encountering a formula [!φ]ψ or ¬[!φ]ψ anywhere in the tableau, the rule R! forces every other node to declare that φ or ¬φ should be true. Name Precondition Postcondition R! T n and T n′[!φ]ψ T nφ or T n¬φ T n and T n′¬[!φ]ψ T nφ or T n¬φ • T ′[??] ∩ (T [?φ] × Prop) = T [??] ∩ (T [?φ] × Prop) The last line states that the atoms of the two tableaux must match in the nodes that survive the announcement. Third, we extend the definition of 'open tableau' to cover cases where tableaux have dynamic formulas. Definition 4.5. An L◻!-tableau T is «open» if and only if • T is free of literal contradictions. • If T n[!φ]ψ and T nφ then there are no open saturated tableaux T ′ for ⟨n¬ψ⟩ such that T !φ −→ T ′. • If T n¬[!φ]ψ then T nφ and there is an open saturated tableau T ′ for ⟨n¬ψ⟩ such that T !φ −→ T ′. Having just specified the tableau system for L◻!, let us reflect on the relation !φ −→. A casual glance tells us this construction is remarkably similar to the operation |!φ. In order to better understand exactly how they relate, we first isolate tableaux in which every node contains either φ or its negation. Definition 4.6. A tableau T is «φ-declarative» if and only for every n ∈ T [?] it is the case that T nφ or T n¬φ. CHAPTER 4 49 Figure 4.3. The diagrams on the left represent a saturated open tableau T for ⟨n¬[!p]◻aq⟩ and its stock model M. The diagrams on the right depict a saturated open tableau T ′ for ⟨n¬◻aq⟩ and its stock model M′. Notice that T !p −→ T and M′ = M|!p. n p¬[!p]◻aq n′ p n′ ¬p n p n′ p n′ n′ p¬q n p¬◻aq n′ p n p a a a a a a The following lemma goes a long way to prove that !φ −→ holds between any two φ-declarative tableaux if and only if the stock model of the second tableau is the result of applying the operation |!φ to the stock model of the first tableau. There is one minor caveat: We require a warrant that the first tableau is natively satisfied by its stock model. We need this guarantee because we have not yet demonstrated completeness for L◻!-tableaux (insofar they contain dynamic formulas). On the contrary, we will use this lemma to prove soundness and completeness. Lemma 4.1. If M is a stock model of a φ-declarative tableau T such that M natively satisfies T up to ¬φ then it holds that M|!φ is the stock model for T ′ if and only if T !φ −→ T ′. Proof. Since T is φ-declarative either T nφ or T n¬φ for every n ∈ T [?]. If T nφ then ⟨Mn⟩ ⊩ φ since M natively satisfies T up to ¬φ; if T n¬φ then ⟨Mn⟩ ⊩ ¬φ by the same reasoning. Because by definition of ¬ it is not CHAPTER 4 50 possible for a formula and its negation to be true in a single world, it follows that ∀n ∈ T [?] ∶ T nφ ⟺ ⟨Mn⟩ ⊩ φ. On the left-to-right reading of the lemma it is assumed that M|!φ is a stock model of T ′. Hence T ′[?] = {w ∈ M[?] ∣ ⟨Mw⟩ ⊩ φ}. By the result in the previous paragraph it follows that T ′[?] = T [?φ]. Since M|!φ is the stock model of T ′ it also follows that T ′[???] = T [???] ∩ (Ind×T [?φ] × T [?φ]). Finally, for all n ∈ T [?φ] and all atoms p it is the case that T np ⟺ T ′np since M is the stock model of T . Consequently, T !φ −→ T ′. On the right-to-left reading of the lemma it is assumed that T !φ −→ T ′. It follows that T ′[?] = T [?φ], T ′[???] = T [??]∩(Ind×T [?φ]×T [?φ]), and T [??]∩ (T [?φ]× Prop) = T [??]∩ (T [?φ]× Prop). By the results from the first paragraph and the fact that M is the stock model of T it is also the case that T ′[?] = {w ∈ M[?] ∣ ⟨Mw⟩ ⊩ φ}, that T ′ has the same frame as M|!φ, and that for alln ∈ T ′[?] and p ∈ Prop it is the case that T ′np ⟺ M|!φnp. Thus M|!φ is the stock model of T ′. In the previous chapter, lemma 3.7 did the heavy lifting with respect to proving soundness. We now extend this result to cover R!. Lemma 4.2. If a σ-model M satisfies a tableau T via a function f then it is the case that, if T is not R!-saturated then there is a tableau T ′ ∈ R![T ]−{T } and a function f′ such that M satisfies T ′ via f′. Proof. Suppose R! is triggered by T n[!φ]ψ (or T n¬[!φ]ψ) and T n′. If ⟨Mf(n)⟩ ⊩ φ then let T ′ ≔ T ∪ ⟨n′φ⟩; otherwise let T ′ ≔ T ∪ ⟨n′¬φ⟩. Since R! does not add new nodes, let f′ ≔ f. Evidently, M satisfies T ′ via f. The above lemma plays a somewhat smaller role in the soundness proof for L◻!-tableaux, however. The reason for that is that in this chapter a tableau's status as 'open' no longer merely depends on it being void of literal contradictions; it also depends on the existence (or non-existence) of other tableaux. In a bit we will tackle these extended requirements as we round off the soundness and completeness proofs. We will address these requirements in tandem and use mutual induction to prove soundness and completeness of CHAPTER 4 51 the dynamic fragment of L◻!. First, however, we introduce a new concept that mirrors the notion of 'stock models' by mapping models onto tableaux. Definition 4.7. Given a pointed σ-model ⟨Mw⟩ such that ⟨Mw⟩ ⊩ φ we say that the tableau T is a «stock tableau» for ⟨Mwφ⟩ if and only if M is a stock model for T and T is a saturated σ-tableau for ⟨wφ⟩ such that M natively satisfies T . Proposition 4.3. If ⟨Mw⟩ is a pointed σ-model such that ⟨Mw⟩ ⊩ φ then there is a stock tableau for ⟨Mwφ⟩. Proof. First, let T ≔ {⟨w⟩, ⟨wφ⟩}. Trivially, T is natively satisfied by M. Second, develop T into a saturated tableau T ′ that is satisfied via a function f (as per lemma 4.2). Third, let T ′′ be the tableau {⟨f(n)⟩ ∣ n ∈ M[?]} ∪M[???] ∪ {⟨f(n)φ⟩ ∣ T ′nφ}. It is easy to see that M natively satisfies T ′′. Moreover, embeddings do not affect R-saturation for rules R that are triggered by the presence of formulas in a tableau. Finally, T ′′ is a σ-tableau and is R-saturated for the frame rules in Rulesσ because M is a σ-model. Everything is now in place to prove that the tableau system for L◻! is sound and complete. As mentioned above, the bulk of these proofs are based on mutual induction. Lemma 4.4 (Lemma to Soundness and Completeness). Let M be the stock model of a σ-saturated tableau T . 1. If M natively satisfies T and T is a tableau for φ ∈ L◻! then T is open. 2. If T is open and T nφ then ⟨Mn⟩ ⊩ φ. Proof. Proof by mutual induction on the length of φ. Assume that the lemma holds for all ψ that are shorter than φ. CHAPTER 4 52 Part 1. We address the requirements of the extended definition of 'open tableau' one by one: • In lemmas 3.7 and 4.2 it is shown that T is free of literal contradictions. These lemmas also handle the base cases where φ ∈ Lit. • For all ⟨n[!ψ]χ⟩ ∈ T it must be demonstrated that if T nψ then there is no open saturated tableau T ′ for ⟨n¬χ⟩ such that T !ψ −→ T ′. Suppose such a tableau T ′ did exist. By Part 2 of the IH it is then the case that, with M′ the stock model of T ′, ⟨M′n⟩ ⊩ ¬χ. By R!, since T is σ-saturated, it is the case that T is ψ-declarative. By lemma 4.1 it now follows that M′ = M|!ψ. However, since M natively satisfies T it is the case that ⟨Mn⟩ ⊩ ψ. This contradicts the assumption that ⟨Mn⟩ ⊩ [!ψ]χ. • For all ⟨n¬[!ψ]χ⟩ ∈ T it must be demonstrated that T nψ and that there is an open saturated tableau T ′ for ⟨n¬χ⟩ such that T !ψ −→ T ′. Because M natively satisfies T it is the case that ⟨Mn⟩ ⊩ ψ and that ⟨M|!ψn⟩ ⊩ ¬χ. By Part 1 of the IH it follows that any stock tableau T ′ for ⟨M|!ψn¬χ⟩ is open. Also notice that T is ψ-declarative because of R!. By lemma 4.1 it follows that T !ψ −→ T ′ and this concludes our proof. Part 2. Most of this proof has already been covered in lemma 3.9, which can be interpreted as proceeding by induction on Part 2 of the current IH. In what follows we only deal with the patterns that are new to L◻!. • Suppose φ is [!ψ]χ. It has to be demonstrated that if ⟨Mn⟩ ⊩ ψ then ⟨M|!ψn⟩ ⊩ χ. The proof proceeds by contradiction. Assume that ⟨Mn⟩ ⊩ ψ and ⟨M|!ψn⟩ ⊩ ¬χ. By Part 1 of the IH it follows that the stock tableau T ′ for ⟨M|!ψn¬χ⟩ is open. Because of R! it is the case that T is ψ-declarative and by Part 2 of the IH it follows that M natively satisfies T up to ¬ψ. By lemma 4.1 it now follows that T !ψ −→ T ′. CHAPTER 4 53 However, since T is an open tableau we know that there is no saturated open tableau T ′′ for ⟨n¬χ⟩ such that T !ψ −→ T ′′. This concludes the proof by contradiction. • Suppose φ is ¬[!ψ]χ. We need to show that ⟨Mn⟩ ⊩ ψ and ⟨M|!ψ⟩ ⊩ ¬χ. Since T is open it follows that T nψ and that there is an open saturated tableau T ′ for ⟨n¬χ⟩ such that T !ψ −→ T ′. Notice that T is ψ-declarative by R!. Additionally, by Part 2 of the IH it also follows that M natively satisfies T up to ¬ψ. By lemma 4.1 it is now the case that M|!ψ is a stock model of T ′. Finally, by Part 2 of the IH it is the case that ⟨Mn⟩ ⊩ ψ and ⟨M|!ψn⟩ ⊩ ¬χ. Notice that where Part 1 and Part 2 make use of lemma 4.1, they either use a combination of (i) induction on Part 1 and a left-to-right reading of lemma 4.1 or (ii) induction on Part 2 and a right-to-left reading of lemma 4.1. This means that lemma 4.1 could just as well be incorporated in the above lemma, although the resulting lemma would arguably be convoluted. This does, however, explain the surprising requirement of lemma 4.1 that the first tableau must have been demonstrated to be natively satisfied by its stock model. At this point proving soundness and completeness is a straightforward matter. Theorem 4.5 (Soundness). If all σ-saturated tableaux for φ ∈ L◻! are closed then ⊨σ ¬φ. Proof. As before, we prove the contrapositive-namely, that if there is a pointed σ-model ⟨Mw⟩ such that ⟨Mw⟩ ⊩ φ then there's an open saturated σ-tableau T for ⟨wφ⟩. By Part 1 of lemma 4.4 the stock tableau for ⟨Mwφ⟩ is open. This concludes our proof. CHAPTER 4 54 Theorem 4.6 (Completeness). If ⊨σ ¬φ (with φ ∈ L◻!) then all saturated σ-tableaux T for φ are closed. Proof. The contrapositive states that if there is an open σ-saturated tableau T for ⟨nφ⟩ then there's a σ-model M such that ⟨Mn⟩ ⊩ φ. By Part 2 of lemma 4.4 it indeed follows that φ holds in n in the stock model of T . 4.3 Tableau cascades and decidability How do we decide, for any given tableau T , if there's another tableau T ′ such that T !φ −→ T ′? This concern makes searching for tableaux for dynamic formulas quite the different enterprise from searching for LU◻-tableaux. Multiple approaches are conceivable. We discuss two approaches with different trade-offs. In both approaches, upon encountering a formula ¬[!φ]ψ in a node, we add φ to the node and create a new tableau for ¬ψ. We then try and see if this new tableau can be developed into a saturated open tableau that stands in the relation !φ −→ to the original tableau. Similarly, when we find formulas [!φ]ψ and φ in a node, we create a tableau for ψ and try to develop it into a saturated open tableau that stands in a !φ −→ relation to the original tableau. This works because |!φ always yields exactly one model; by lemma 4.1 this means we only need to find one open tableau. The question remains, however, how we can develop two tableaux such that they are saturated, open, and stand in a relation !φ −→ to one another. What's clear is that this will typically require the use of the tableau rule R⋆ (table 3.2), with the caveat that this makes finding a decidable proof procedure non-obvious. On the first approach we forgo the use of a rigid proof procedure. Instead we can let our intuition advise us on how to apply R⋆. Given two tableaux T 1 and T 2 it is sometimes quite easy to find tableaux T ′1 ⊃ T 1 and T ′2 ⊃ T 2 such that T ′1 !φ −→ T ′2. Using our intuition we might very well be able to prove that a formula is satisfiable. However, we cannot prove that a formula is CHAPTER 4 55 unsatisfiable-at best we can show that our intuition failed to find a tableau that satisfies it. In the remainder of this section we will discuss a second approach, which involves a more mechanical proof procedure. This procedure has the property that if a formula is satisfiable then we can find a saturated and demonstrably open tableau for it in a finite number of steps. That is to say, the procedure is decidable. To start, we define a tree structure for keeping track of the different tableaux we are developing. Definition 4.8. A «tableau cascade» C is an lgraph such that • Every node has exactly one label and this label is a tableau. • The indices of the edges are relations !φ −→ as defined in definition 4.4. An edge ⟨ !φ −→ tt′⟩ ∈ C signals the intent to transform C into a tableau cascade C ′ such that C ′(t?) !φ −→ C ′(t′?). We first encountered the notion that models satisfy certain other constructs in definition 3.3. We stipulated that a pointed model ⟨Mw⟩ satisfies a wff φ if and only if ⟨Mw⟩ ⊩ φ. In definition 3.13 we generalized this notion, saying that M satisfies a tableau T via a function f if for all ⟨nψ⟩ ∈ T it is the case that ⟨Mf(n)⟩ ⊩ ψ. We now abstract this concept even further by defining what it means for a model to satisfy a tableau cascade. Definition 4.9. A pointed tableau cascade ⟨Ct⟩ is «satisfied» by a model M via a function f if and only if • M satisfies C(t?) via f. • For every ⟨ !φ −→t′⟩ ∈ C[?t?] it is the case that M|!φ satisfies ⟨Ct′⟩ via f. We say that a tableau cascade C is satisfied by a model M via a function f if and only if ⟨C root(C)⟩ is satisfied by M via f. There are three kinds of operations that we want to perform on tableau cascades. The first kind of operation merely constitutes applying a tableau rule to a node in a tableau cascade. CHAPTER 4 56 Figure 4.4. The diagram below shows what happens when the tableau cascade that consists solely of the top tableau is primed-viz. the three bottom tableaux are added to the tableau cascade. The leftmost one is added as a result of φ1 and [!φ1]φ2 being labels for n in the top tableau. The label ¬[!ψ1]ψ2 for n gives rise to the middle tableau. The rightmost tableau is created because n′ contains χ1 and [! χ1]χ2. Finally, the label [! ξ1]ξ2 for n′ does not result in a new tableau because n′ does not contain ξ1. n φ1 [!φ1]φ2 ¬[!ψ1]ψ2 n′ χ1 [! χ1]χ2 [! ξ1]ξ2 a n ¬ψ2 n φ2 n′ χ2 !φ1 −−→ !ψ1 −−→ !χ1 −−→ Definition 4.10. C ′ is an outcome of «applying» a tableau rule R to t in a tableau cascade C if and only if RC(t?)C ′(t?) and C ′ − ⟨tC ′(t?)⟩ = C − ⟨tC(t?)⟩. Lemma 4.7. Given a tableau cascade C that is satisfied by a model M via a function f, if R is a tableau rule and the tableau C(t?) is not R-saturated then there is an outcome C ′ ≠ C of applying R to t in C such that C ′ is satisfied by M via some function f′. Proof. This is a direct result of lemmas 3.7 and 4.2. The second kind of operation looks for public announcements in the different tableaux in the cascade and adds new tableaux to the cascade as a result. Definition 4.11. C ′ is the result of «!-priming» a tableau cascade C if and only if C ′ is a minimal extension of C (and the tableaux therein) such that for all ⟨tT ⟩ ∈ C and ⟨nφ⟩ ∈ T , CHAPTER 4 57 • If φ = [!ψ]χ and T nψ then there is a node-tableau pair ⟨t′T ′⟩ ∈ C ′ such that T ′ is a tableau for ⟨nχ⟩ and ⟨ !ψ −→tt′⟩ ∈ C ′. • If φ = ¬[!ψ]χ then T nψ and there is a node-tableau pair ⟨t′T ′⟩ ∈ C ′ such that T ′ is a tableau for ⟨n¬χ⟩ and ⟨ !ψ −→tt′⟩ ∈ C ′. Lemma 4.8. Given a tableau cascade C that is satisfied by a model M⋆ via a function f, if C ′ is the result of !-priming C then C ′ is satisfied by M⋆ via f. Proof. We need to prove that for all new nodes t′ that are accessible from a node t over !φ −→ in C ′, if T ≔ C(t?) is satisfied by M via f then T ′ ≔ C ′(t′?) is satisfied by M|!φ via f. We distinguish the two cases that could have led to this situation: 1. T n[!φ]ψ, T nφ, and T ′ = {⟨n⟩, ⟨n,ψ⟩}. It is then the case that ⟨Mf(n)⟩ ⊩ φ and ⟨M|!φf(n)⟩ ⊩ ψ. Hence M|!φ satisfies T ′ via f. 2. T n¬[!φ]ψ and T ′ = {⟨n⟩, ⟨n,¬ψ⟩}. It is then the case that ⟨Mf(n)⟩ ⊩ φ and ⟨M|!φf(n)⟩ ⊩ ¬ψ by definition of ¬ and [!φ]. Hence M|!φ satisfies T ′ via f. The third and final type of operation ensures that the different tableaux in a tableau cascade can be properly compared by dynamic relations !φ −→. This means copying edges and atomic propositions between tableaux and ensuring that only φ-nodes 'survive' an update. Definition 4.12. C ′ is the result of «synchronizing» a tableau cascade C if and only if • C and C ′ have the same frame. • C ′ is an extension of C in the sense that ∀t ∈ C[?] ∶ C(t?) ⊆ C ′(t?). • The set {⟨tx⟩ ∣ t ∈ C[?] and x ∈ C ′(t?) − C(t?)} is a minimal set (ordered by the subset relation) such that for some edge ⟨ π −→t1t2⟩ ∈ C it is the case that C ′(t1?) π −→ C ′(t2?) but not C(t1?) π −→ C(t2?). CHAPTER 4 58 Figure 4.5. Forward propagation of nodes, edges, and atoms. Suppose p was added to n and n′ by R! in the tableau on the left. By synchronizing the tableau cascade, the node n is copied from the tableau on the left to the tableau on the right because it contains p. Atoms and edges are also copied from the left to the right insofar they concern surviving nodes. n ¬◻a[! p]q ¬◻bp p n′¬[!p]q p n′′¬p a b n p n′ ¬q p a !p −→ We also say that a tableau cascade is «fully synchronized» if and only if it cannot be synchronized. Proposition 4.9. A synchronization operation affects one or two tableau cascade nodes. The following lemma entails that the satisfiability of a tableau cascade is unaffected by synchronization. Lemma 4.10. Let C be a tableau cascade such that ⟨ !φ −→tt′⟩ ∈ C and such that C(t?) is satisfied by a model M via a function f and C(t′?) is satisfied by M|!φ via f. If C can be synchronized such that at most t and t′ are affected then there's an outcome C ′ of synchronizing C such that M satisfies C ′(t?) via f and M|!φ satisfies C ′(t′?) via f. Proof. We need to demonstrate that there are finite tableaux T ⊇ C(t?) and T ′ ⊇ C(t′?) (i) which are satisfied via M and M|!φ via f and (ii) such that T !φ −→ T ′. It then immediately follows that there are minimal tableaux that are supersets of C(t?) and C(t′?) and meet conditions (i) and (ii). CHAPTER 4 59 Figure 4.6. Backward propagation of nodes, edges, and atoms. By synchronizing the tableau cascade, all nodes, edges, and atoms from the right hand tableau are copied to the left. Moreover, the label ¬p is added to the tableau on the left for all nodes that also exist in the tableau on the right. n¬[!¬p]◻a¬q ¬p n′ q ¬p a n¬◻a¬q n′ ¬¬q q a !¬p −−→ First, let N be the known domain of f. That is, N ≔ C(t?)[?] ∪ C(t′?)[?]. Informally, N is the totality of nodes of the tableaux named t and t′. Next, let T be the following tableau: • T [?] = N • T [???] = {⟨ann′⟩ ∈ Ind×N×N ∣ ⟨af(n)f(n′) ∈ M⟩} • T [??] = C(t?)[??] ∪ {⟨np⟩ ∈ N × Prop ∣ Mf(n)p} ∪ {⟨nφ⟩ ∣ n ∈ N and ⟨Mf(n)⟩ ⊩ φ} T is a superset of C(t?). For consider that (i) N is a superset of C(t?)[?], (ii) for every edge ⟨ann′⟩ of C(t?) there is an edge ⟨af(n)f(n′)⟩ in M by definition 3.13, and (iii) the formulas of C(t?) are copied verbatim. Let T ′ be the following tableau: • T ′[?] = T [?φ] • T ′[???] = {⟨ann′⟩ ∈ Ind×T ′[?] × T ′[?] ∣ ⟨af(n)f(n′)⟩ ∈ M} • T ′[??] = C(t′?)[??] ∪ {⟨np⟩ ∈ T ′[?] × Prop ∣ Mf(n)p} Again, T ′ is a superset of C(t′?). For assume, to the contrary, that there was a node n of C(t′?) that was not in T ′. This would mean that not T nφ. But by construction this implies that not ⟨Mf(n)⟩ ⊩ φ. However, such a node cannot be in C(t′?) since C(t′?) is satisfied by M|!φ via f. That T !φ −→ T ′ holds is also clearly the case by construction. CHAPTER 4 60 Theorem 4.11. If there is a pointed σ-model ⟨Mw⟩ such that ⟨Mw⟩ ⊩ φ (where φ ∈ L◻!) then an open saturated σ-tableau T for ⟨wφ⟩ can be found in a finite number of steps. Proof. Start with the tableau cascade C0 = {⟨0⟩, ⟨0{⟨w⟩, ⟨wφ⟩}⟩}. Thus C0 contains a node 0 and the label for 0 is a tableau that consists of a node w with a label φ. Next, consider all series C1,... ,C i,C i+1,... such that for every natural number i, C i+1 is the result of applying a rule from Rules to any tableau in C i or a rule from Rulesσ to C i(0?) and such that 1. The mandatory rules that do not add new edges (or nodes) are applied first. 2. Fairly select zero or more of the mandatory rules that were skipped in the first step and apply them if the following condition is met: Do not add outgoing edges to a node n if and only if there is a node n′ such that in every tableau of C i, n either does not exist or n is a copy of n′. Informally speaking, fair selection means that given due time every rule is chosen (repeatedly). 3. !-prime the tableau cascade. 4. Synchronize the tableau cascade until it is fully synchronized. Repeat this process until there are no more rules to apply. At that point, fold all virtual a-loops. It's straightforward to see how the above steps will indeed result in saturated tableaux and how on some of the resulting branches all tableaux are free of literal contradictions. Moreover, the above steps always lead to saturation in a finite number of steps. The argument is the same as in theorem 3.12. Finally, let C be a tableau cascade derived from C0 as detailed above such that all tableaux in C are σ-saturated and free of literal contradictions. Because, moreover, C is fully synchronized it is clear that all tableaux in C are open. CHAPTER 4 61 4.4 Related work Public announcement logic was originally devised in [30] and, later but independently, in [20]. Two similar tableau systems for public announcement are described in [2, 12]. However, these tableau systems are unintuitive and difficult to use because of the non-trivial relation of the tableau rules to the semantics of PAL. A different approach is taken in [22]. In this system dynamic formulas with public announcements are rewritten to equivalent non-dynamic formulas using 'reduction rules'. Such rules are also used in axiomatic proof systems for PAL. Indeed, axiomatic systems for propositional logic can be extended to PAL by adding the following axiom schemas: [!φ]p ⟺ (φ → p) [!φ]¬ψ ⟺ (φ → ¬[!φ]ψ) [!φ](ψ∧ χ) ⟺ ([!φ]ψ∧ [!φ]χ) [!φ]◻aψ ⟺ (φ → ◻a(φ → [!φ]ψ)) [!φ][!ψ]χ ⟺ [! (φ∧ [!φ]ψ)]χ where p ∈ Prop and {φ,ψ,χ} ⊆ L◻! [38]. The relation of the reduction rules to the semantics of PAL might not be immediately obvious, however. Therefore the proof system in this chapter is arguably easier to understand and use. CHAPTER 4 62 5 Dynamic Epistemic Logic with Action Models In the previous chapter we discussed public announcement logic, which is a dynamic modal logic for reasoning about agents who discover facts in a public setting. In this chapter we will look at an extension of public announcement logic that allows us to reason about many more kinds of epistemic events. Using dynamic epistemic logic with action models (DEL) we can reason not only about public discovery of facts, but also about various forms of private and semi-private learning. DEL can be used to reason about card games and other knowledge games. Some of these games are relevant for cryptography and security protocols. The link between knowledge games and dynamic epistemic logic is treated extensively in [36,37]. 5.1 Syntax and semantics of L◻⊗ The language of dynamic epistemic logic L◻⊗ adds formulas of the form [⊗π]φ to the language of modal logic. Here π represents an epistemic event or action and φ is a formula of L◻⊗. Epistemic events, in turn, are described by lgraphs that have L◻⊗ sentences for labels. These lgraphs are called action models. The definitions for L◻⊗ and 'action models' are mutually recursive. 63 Figure 5.1. A basic action model A with one node. This action model represent the update where non-φ worlds are deleted; a-edges are kept as-is unless they originate from or point to a non-φ world. The update operation |⊗A is equivalent to the update operation |!φ. φ a Definition 5.1. The set «L◻⊗» is determined by the following grammar: φ ::= p ∣ ¬φ ∣ (φ∧φ) ∣ ◻aφ ∣ [⊗Ae]φ. As usual, p stands for any element of the set of atomic proposition Prop and a is any member of the set of agents Ind. Finally, let ⟨Ae⟩ be any pointed action model. Definition 5.2. An «action model» A is an lgraph such that • The nodes of A are called «actions» or «events». • The edges of A are edges indexed by elements of Ind. • Every node n has exactly one labelφ ∈ L◻⊗, called a «precondition». By abuse of terminology, if φ = ⊤ then we say that n has no preconditions. The notation A(n?) denotes the precondition of n. The mutual recursion is unproblematic if action models are thought of as syntactic structures. For instance, we could convert them to a string that describes their structure. It is then immediately apparent that action models are longer in 'length' than all of the labels they contain. Our conversion of action models to syntactic structures makes the issue salient that having semantic objects as part of a language is unusual. We admit that this is unusual but don't think it's a real problem. We think it's simply the case that the most convenient way to describe an epistemic event is to draw a diagram. Indeed, Hans van Ditmarsch argues that we can think CHAPTER 5 64 of action models as syntactic objects from the get-go [37, §6.1]. Johan van Benthem has a more poetic view: "If you are down-to-earth, you will find a syntax putting models in a language weird, and your life will be full of fears of inconsistency. If you are born to be wild, you will see DEL as a welcome flight of the imagination." [34, p. 86]. In the previous chapter we defined the forcing relation ⊩ by taking the definition for⊩ frommodal logic and adding an extra clause to it for sentences of the form [!φ]ψ. That is, in chapter 3 the behavior of the forcing relation was left undefined for wffs [!φ]ψ and in chapter 4 we retroactively defined how to interpret such formulas. We are again faced with a gap in the definition of ⊩. Hence we extend the definition of the forcing relation again. Definition 5.3. The forcing relation «⊩» is as before, but also meets the following constraint. ⟨Mw⟩ ⊩ [⊗Ae]φ ⟺ if ⟨Mw⟩ ⊩ A(e?) then ⟨M|⊗A⟨we⟩⟩ ⊩ φ where M|⊗A = {⟨n⟩ ∣ n ∈ N}∪ E∪ L such that • N ≔ {⟨w′e′⟩ ∈ M[?] ×A[?] ∣ ⟨Mw′⟩ ⊩ A(e′?)} • E ≔ {⟨a⟨w′e′⟩⟨w′′e′′⟩⟩ ∈ Ind×N×N ∣ Maw′w′′ and Aae′e′′} • L ≔ {⟨⟨w′e′⟩p⟩ ∈ N× Prop ∣ Mw′p} Thus the set of nodes of M|⊗A is a subset of the Cartesian product of the set of nodes of M and A. For any two nodes ⟨w′e′⟩ and ⟨w′′e′′⟩, there is an a-edge in M|⊗A if and only if there is an a-edge between w′ and w′′, and between e′ and e′′. Finally, the atoms for any node ⟨w′e′⟩ in M|⊗A are copied from w′ in M; non-atomic labels are not transferred. The above semantics also suggest an interpretation of action models as semantic objects. They can be thought of as relativizations of Kripke models (cf. [3, §1] and [37, §6.1]). CHAPTER 5 65 Figure 5.2. Below a Kripke model M, an action model A, and the updated Kripke model M|⊗A are depicted. In the original model M the agents a and b are ignorant about the truth value of the formula φ. That is, in both worlds it is the case that ¬◻aφ, ¬◻a¬φ, ¬◻bφ, and ¬◻b¬φ. The update model A represents an update where (i) all φ-worlds are copied once and (ii) all worlds are copied indescriminately. Thus the φ-worlds are copied twice. A also specifies that all b-links to the worlds of (i) are cut. The last figure shows the result of updating M with the action model A. In ⟨we⟩ agent a has come to learn that φ is true but b doesn't know that φ. Moreover, b doesn't know that a knows whether φ is true (¬◻b(◻aφ ∨ ◻a¬φ)) and a knows that b doesn't know this (◻a¬◻b(◻aφ∨◻a¬φ)). w φ ¬φ a,b a,b a,b It is not know if φ is true or not. e φ ⊤ ba a,b a learns that φ is true. ⟨we⟩ φ ¬φ φ b b a,b a a,b a,b a now knows that φ holds. 5.2 Dynamic Tableaux We now extend our tableau system to cover all formulas of L◻⊗. We accomplish this through three amendments that are entirely analogous to how we implemented the tableau system for PAL. First, we extend the tableau rules. CHAPTER 5 66 Table 5.1. For every [⊗Ae]φ and ¬[⊗Ae]φ in the tableau, the rule R⊗ forces every node to decide, for all preconditions of A, if the precondition or its negation should be true. Name Precondition Postcondition R⊗ T n[⊗Ae]φ,T n′, and Ae′ T n′A(e′?) or T n′¬A(e′?) T n¬[⊗Ae]φ,T n′, and Ae′ T n′A(e′?) or T n′¬A(e′?) Definition 5.4. Let the mandatory rules of Rules (and Rulesσ) include the additional rule in table 5.1. Second, we translate the operation |⊗A to a relation between tableaux. Definition 5.5. For any two tableaux T and T ′ the relationship «T ⊗A −−→ T ′» holds if and only if 1. T ′[?] = {⟨ne⟩ ∈ T [?] ×A[?] ∣ T nA(e?)}. 2. T ′[???] = {⟨a⟨ne⟩⟨n′e′⟩⟩ ∈ Ind×T ′[?] × T ′[?] ∣ T ann′ and Aaee′}. 3. T ′[??] ∩ (T ′[?] × Prop) = {⟨⟨ne⟩p⟩ ∈ T ′[?] × Prop ∣ T np}. Third and last, we redefine the notion of 'open tableau'. Definition 5.6. Let the predicate «open» be as before, except for two added conditions: 1. If T n[⊗Ae]φ and T nA(e?) then there are no open saturated tableaux T ′ for ⟨⟨ne⟩¬φ⟩ such that T ⊗A −−→ T ′. 2. If T n¬[⊗Ae]φ then T nA(e?) and there is an open saturated tableau T ′ for ⟨⟨ne⟩¬φ⟩ such that T ⊗A −−→ T ′. As in the previous chapter we define a declarativeness notion, and demonstrate a form of symmetry between |⊗A and ⊗A −−→ for 'A-declarative' tableaux and the models that natively satisfy them. Definition 5.7. A tableau T is A-declarative if and only for every n ∈ T [?] and every e ∈ A[?] it is the case that T nA(e?) or T n¬A(e?). CHAPTER 5 67 Figure 5.3. In this diagram two tableaux T (top left) and M′ (top right), two Kripke modelsM (bottom left) andM′ (bottom right), and an action modelA (center) are shown. M and M′ are stock models of T and T ′. Moreover, T ⊗A −−→ T ′ and M′ = M|⊗A . n ¬p,q n′ p,r e ¬p e′ ¬p ⟨ne⟩ q ⟨ne′⟩ ¬p,q n′ p,r n q ⟨ne⟩ q ⟨ne′⟩ q a a a a a a a a a Lemma 5.1. Let A be an action model and let M be the stock model of an A-declarative tableau T such that M natively satisfies T up to the negation of all formulas in A. It is then the case that M|⊗A is the stock model for T ′ if and only if T ⊗A −−→ T ′. Proof. First of all, observe that (i) M natively satisfies T (up to the negation of all preconditions in A) and (ii) T is A-declarative. Therefore it is the case that for all n ∈ T [?] and e ∈ A[?], T nA(e?) ⟺ ⟨Mn⟩ ⊩ A(e?). (5.1) Proof for the left-to-right part of the lemma. Assume that M|⊗A is the stock model of T ′. Thus, T ′[?] = {⟨we⟩ ∈ M[?] ×A[?] ∣ ⟨Mw⟩ ⊩ A(e?)}. By equation (5.1) it follows that T ′[?] = {⟨ne⟩ ∈ T [?] ×A[?] ∣ T nA(e?)}. CHAPTER 5 68 Because M|⊗A is the stock model of T ′ it also follows that T ′[???] = {⟨a⟨ne⟩⟨n′e′⟩ ∈ Ind×T ′[?] × T ′[?]⟩ ∣ T ann′ and Aaee′} and that for all nodes ⟨ne⟩ ∈ T ′[?] and atoms p it is the case that T np ⟺ T ′⟨ne⟩p. Finally, it follows that T ⊗A −−→ T ′. Proof from right to left. Assume that T ⊗A −−→ T ′. It follows that • T ′[?] = {⟨ne⟩ ∈ T [?] ×A[?] ∣ T nA(e?)} • T ′[???] = {⟨a⟨ne⟩⟨n′e′⟩ ∈ Ind×T ′[?] × T ′[?]⟩ ∣ T ann′ and Aaee′} • T ′[??] ∩ (T ′[?] × Prop) = {⟨⟨ne⟩p⟩ ∈ T ′[?] × Prop ∣ T np}. By the results from the first paragraph and the fact that M is the stock model of T it is also the case that T ′[?] = {⟨we⟩ ∈ M[?] ×A[?] ∣ ⟨Mw⟩ ⊩ A(e?)}, that T ′ has the same frame as M|⊗A , and that T ′np ⟺ M|⊗Anp for every atom p. Thus M|⊗A is the stock model of T ′. We extend lemma 3.7 once more and prove that R⊗ preserves satisfiability. Lemma 5.2. If aσ-modelM satisfies a tableau T via a functionf then it is the case that, if T is not R⊗-saturated then there is a tableau T ′ ∈ R⊗[T ]− {T } and a function f′ such that M satisfies T ′ via f′. Proof. Suppose R⊗ is triggered by T n[⊗Ae]φ (or T n¬[⊗Ae]φ), Ae′, and T n′. If ⟨Mf(n′)⟩ ⊩ A(e′?) then let T ′ ≔ T ∪ ⟨n′A(e′?)⟩; otherwise let T ′ ≔ T ∪ ⟨n′¬A(e′?)⟩. As M satisfies T ′ via f, let f′ ≔ f. CHAPTER 5 69 It is now time to prove soundness and completeness. As before we use mutual induction. Lemma 5.3 (Lemma to Soundness and Completeness). Given a stock model M for a saturated tableau T , 1. If M natively satisfies T and T is a tableau for φ then T is open. 2. If T is open and T nφ then ⟨Mn⟩ ⊩ φ. Proof. Proof by mutual induction on the length of φ. Assume that the lemma holds for all ψ shorter than φ. Part 1. • In lemmas 3.7 and 5.2 it is shown that T is free of literal contradictions. • For all ⟨n[⊗Ae]ψ⟩ ∈ T it must be demonstrated that if T nA(e?) then there is no open saturated tableau T ′ for ⟨⟨ne⟩¬ψ⟩ such that T ⊗A −−→ T ′. Proof by contradiction. Suppose such a tableau T ′ did exist and that T nA(e?). By Part 2 of the IH it is then the case that, with M′ the stock model of T ′, ⟨M′⟨ne⟩⟩ ⊩ ¬ψ. By lemma 5.1 it also follows that M′ = M|⊗A . Moreover, since M natively satisfies T it is the case that ⟨Mn⟩ ⊩ A(e?). These results, however, contradict the assumption that ⟨Mn⟩ ⊩ [⊗Ae]ψ. This ends the proof by contradiction. • For all ⟨n¬[⊗Ae]ψ⟩ ∈ T it must be demonstrated that T nA(e?) and that there is an open saturated tableau T ′ for ⟨⟨ne⟩¬ψ⟩ such that T ⊗A −−→ T ′. First of all, by R⊗ it is the case that T nA(e?) or T n¬A(e?). Because M natively satisfies T and because T n¬[⊗Ae]ψ, however, it follows that T nA(e?) and not T n¬A(e?). CHAPTER 5 70 Since M natively satisfies T it is also the case that ⟨M|⊗A⟨ne⟩⟩ ⊩ ¬ψ. By Part 1 of the IH it now follows that the stock tableau T ′ for ⟨M|⊗A⟨ne⟩¬ψ⟩ is open. Also notice that T is A-declarative because of R⊗. By lemma 5.1 it follows that T ⊗ψ −−→ T ′ and this concludes our proof. Part 2. The bulk of this proof has already been covered in lemma 3.9. We only provide the proofs for the patterns specific to L◻⊗. • Suppose φ is [⊗Ae]ψ. It has to be demonstrated that if ⟨Mn⟩ ⊩ A(e?) then ⟨M|⊗A⟨ne⟩⟩ ⊩ ψ. The proof proceeds by contradiction. Assume that ⟨Mn⟩ ⊩ A(e?) and ⟨M|⊗A⟨ne⟩⟩ ⊩ ¬ψ. By Part 1 of the induction hypothesis it follows that every stock tableau T ′ for ⟨M|⊗A⟨ne⟩¬ψ⟩ is open. Moreover, T is A-declarative by R⊗. By Part 2 of the IH it follows that M natively satisfies T up to the negation of all formulas in A. By lemma 5.1 it now follows that T ⊗A −−→ T ′. However, since T is an open tableau we know that there is no saturated open tableau T ′′ for ⟨n¬ψ⟩ such that T ⊗A −−→ T ′′. This concludes the proof by contradiction. • Suppose φ is ¬[⊗Ae]ψ. We need to demonstrate that ⟨Mn⟩ ⊩ A(e?) and that ⟨M|⊗A⟨ne⟩⟩ ⊩ ¬ψ. First, since T is open it follows that T nA(e?) and that there is an open saturated tableau T ′ for ⟨n¬ψ⟩ such that T ⊗A −−→ T ′. Second, T is A-declarative by R⊗. Hence, by Part 2 of the IH it also follows that M natively satisfies T up to the negation of all formulas in A. By lemma 5.1 it is now the case that M|⊗A is the stock model of T ′. Finally, again by Part 2 of the IH, it is the case that ⟨Mn⟩ ⊩ A(e?) and ⟨M|⊗A⟨ne⟩⟩ ⊩ ¬ψ. CHAPTER 5 71 5.3 Decidability In this section we demonstrate that tableaux for L◻⊗ are decidable. The proof extends the techniques used in the previous chapter. First we need to tweak the definition of satisfiability with respect to tableau cascades. Definition 5.8. A pointed tableau cascade ⟨Ct⟩ is «satisfied» by a model M via a function f if and only if • M satisfies the tableau C(t?) via f. • For every ⟨ ⊗A −−→t′⟩ ∈ C[?t?] it is the case that M|⊗φ satisfies ⟨Ct′⟩ via the function f′ ∶ ⟨xy⟩ ↦ ⟨f(x)y⟩. We say that a tableau cascade C is satisfied by a model M via a function f if and only if ⟨C root(C)⟩ is satisfied by M via f. Next, we expand the notion of priming to formulas of the form [⊗A]φ and ¬[⊗A]φ. Definition 5.9. C ′ is the result of «⊗-priming» a tableau cascade C if and only if C ′ is a minimal extension of C such that for every ⟨tT ⟩ ∈ C[??], • If T n[⊗Ae]φ and T nA(e?) then there is a tableau T ′ for ⟨⟨ne⟩φ⟩ such that in C there is a ⊗A −−→-link from t to C(?T ′). • If T n¬[⊗Ae]φ then there is a tableau T ′ for ⟨⟨ne⟩¬φ⟩ such that in C there is a ⊗A −−→-link from t to C(?T ′). As before, priming does not affect the satisfiability of a tableau cascade. Lemma 5.4. Given a tableau cascade C that is satisfied by a model M⋆ via a function f⋆, it is the case that any C ′ that is the result of ⊗-priming C is satisfied by M⋆ via f⋆. CHAPTER 5 72 Proof. Let t′ be a node that is new in C ′ and that is accessible from a node t over ⊗A −−→. Notice that t is a node of both C and C ′ by construction. Define T ≔ C(t?) and T ′ ≔ C ′(t′?). LetM and f be anymodel and function such that ⟨Ct⟩ is satisfied byM via f. We demonstrate that ⟨C ′t′⟩ is satisfied by M|⊗A via f′ ∶ ⟨xy⟩ → ⟨f(x)y⟩. The case where the precondition A(e?) is not in n is trivial. Suppose t′ was added because T n[⊗Ae]φ and T nA(e?). By definition of priming it is then the case that T ′ = {⟨ne⟩, ⟨⟨ne⟩φ⟩}. Because C is satisfied by M via f it is the case that ⟨Mf(n)⟩ ⊩ [⊗Ae]φ and ⟨Mf(n)⟩ ⊩ A(e?). This implies that the model M|⊗A is nonempty and contains a world ⟨f(n)e⟩. Moreover, ⟨M|⊗A⟨f(n)e⟩⟩ ⊩ φ. We can now conclude that M|⊗A satisfies T ′ via f′. Suppose t′ was added because T n¬[⊗Ae]φ. From the definition of priming it follows that T ′ = {⟨ne⟩, ⟨⟨ne⟩¬φ⟩}. Since C is satisfied by M via f it also follows that ⟨Mf(n)⟩ ⊩ ¬[⊗Ae]φ and that ⟨M|⊗A⟨f(n)e⟩⟩ ⊩ ¬ψ. Consequently, M|⊗A satisfies T ′ via f′. There's a small problem. The nodes created by R⋄ or R a D are elements of N. However, the satisfaction definition we use in this chapter stipulates that in a tableau cascade C , for any node t ≠ root(C) it is the case that the tableau nodes of C(t?) are not elements of N. Rather, with ⊗A1 −−−→,... , ⊗An −−−→ the edges from root(C) to t, the nodes of C(t?) are elements of N×A1 ×⋯×An. We introduce a simple operation to remedy this problem. Definition 5.10. C ′ is the result of «⊗-correcting» a tableau cascade C if and only if • C and C ′ have the same frame. • For every tableau cascade node t ∈ C[?] there is an embedding h from T ≔ C(t?) to T ′ ≔ C ′(t?) such that for all n ∈ T [?], – n ∈ N ⟹ h(n) ∈ {n}×A1[?] ×⋯×An[?] – h(n) = n otherwise where ⊗A1 −−−→,... , ⊗An −−−→ are the ⊗ −→-edges on the path from root(C) to t. CHAPTER 5 73 Figure 5.4. Below a tableau cascade is shown right after the rule R⋄ was applied and after a correcting operation is performed. The correcting operation renames the node n′ to ⟨n′e′⟩, which fits the tableau cascade's configuration. e φ e′ ¬φ aa a The action model A n ¬[⊗Ae]◻aφ ⟨ne⟩ ¬◻aφ n′ ¬φ a ⊗Ae −−−→ n′ was added by R⋄ n ¬[⊗Ae]◻aφ ⟨ne⟩ ¬◻aφ ⟨n′e′⟩ ¬φ a ⊗Ae −−−→ Correction We prefer to introduce the correcting operation over changing the tableau rules because this problem only surfaces after the soundness and completeness proofs for DEL. We feel this makes for insufficient justification for complicating the tableau rules. This is all the more true considering that we use the same tableau rules for the other logics in this dissertation, which are not affected by this issue. Notice that any tableau cascade can be corrected using only R⋆. By correcting tableau cascades after a tableau rule is applied, satisfiability-as defined in definition 5.8-can be restored. Lemma 5.5. Given a tableau cascade C that is satisfied by a model M via a function f, if R is a tableau rule and C(t?) is not R-saturated then there is a corrected outcome C ′ ≠ C of applying R to C that is satisfied by M via some function f′. Proof. By lemmas 3.7 and 5.2 it is the case that there is a tableau T ⋆ that is the result of applying R to C(t?) that is satisfied by some function f⋆. If T ⋆ contains no new nodes then C ′(t?) = T ⋆ and f′ = f⋆. If a new node was added then it merely has to be renamed in accordance with definition 5.8. CHAPTER 5 74 The notion of synchronization remains unchanged and so does the following property. Lemma 5.6. Let C be a tableau cascade such that ⟨ ⊗A −−→tt′⟩ ∈ C and such that C(t?) is satisfied by a model M via a function f and C(t′?) is satisfied by M|⊗A via f′ ∶ ⟨ne⟩ ↦ ⟨f(n)e⟩. If C can be synchronized such that at most t and t′ are affected then there's an outcome C ′ of synchronizing C such that M satisfies C ′(t?) via f and M|!φ satisfies C ′(t′?) via f′. Proof. The principles behind synchronization remain the same as before. Therefore we omit this proof. We now have all the scaffolding we need to demonstrate that L◻⊗-tableaux are decidable. Theorem 5.7. If there is a pointed model ⟨Mw⟩ such that ⟨Mw⟩ ⊩ φ (where φ ∈ L◻⊗) then an open saturated tableau T for φ can be found in a finite number of steps. Proof. We skip most of the proof because it is analogous to the proof for L◻!. The main exception is that ⊗-correction must be performed before synchronization. Because action models and tableau cascades are finite there are only a finite number of ways in which such ⊗-correction can be performed. Therefore this introduces no new issues. 5.4 Related work The roots of DEL can be found in [4, 20, 30]. The seminal work describing action models is [3]. We know of only one tableau system for dynamic epistemic logic with action models, namely the system described by Hansen in [22]. We already discussed this tableau system in section 4.4 and the same comments apply here. CHAPTER 5 75 6 Dynamic Preorder Logics In chapter 3 we saw that modal logic has a variety of applications. Up to this point, however, we only discussed dynamics for epistemic logics. In this chapter we focus on dynamic operators for changing preference and plausibility relations. Both of these are quintessential preorder relations-that is to say, they are reflexive and transitive. Sometimes they are also presumed to be connected relations but we will not make this assumption here. In this chapter we take operators from two existing logics and combine them in a new language and proof system. The first of these existing logics is a logic for reasoning about preferences and changes in preferences. The second logic interprets plausibility relations as belief strength. 6.1 Belief revision and preference change One particularly important work on belief revision is [1]. In this article the authors arrive at a series of postulates for belief revision. These postulates are generally known as the AGM postulates and are an important reference for assessing the coherence of belief change operations. That's not to say that they are perfect: The AGM postulates have problems with iterated belief revision [23] and only cover single-agent settings and beliefs about ontic facts. Dynamic doxastic logic is the dynamic modal logic take on [1], while also addressing some of its shortcomings. In this chapter we discuss the lexical upgrade operator from [6]. Edges from w to w′ are interpreted in [6] as meaning that w′ is at least as plausible as w. [6] contains another operator for belief change that has the moniker 'conservative upgrade'. Unfortunately we failed to model it in our tableau system. The culprit is that it implicitly refers to a belief operator [best]aφ which holds true in a world w if and only if φ is true in the most plausible worlds connected to w over a. It's an open problem whether the operator [best]a can be added in our tableau system without extending tableau structures. As extending tableau structures would go against the spirit of this thesis, we opted instead to ignore conservative upgrades in the rest of this chapter. We also discuss two dynamic operators for preference change-namely the update and upgrade operators from [35]. An edge from w to w′ is taken to mean that w′ is preferred at least as much as w. 6.2 LU◻¡♯⇑ and its dynamic semantics Definition 6.1. Let the dynamic doxastic and preference language LU◻¡♯⇑ be the set of all formulas that conform to the following specification. φ ::= p ∣ ¬φ ∣ (φ∧φ) ∣ Uφ ∣ ◻aφ ∣ [¡φ]φ ∣ [♯φ]φ ∣ [⇑φ]φ, where p ∈ Prop and a ∈ Ind. Moreover, let IndP ⊆ Ind be indices for preferences and let IndB ⊆ Ind be indices for doxastic plausibility relations. Where a ∈ IndP, read ◻aφ as 'a prefers φ to be the case'; where a ∈ IndB, read ◻aφ as 'a safely believes that φ is true'. When modeling a doxastic setting with preferences, every agent should usually be assigned one preference index and one doxastic index. Our preorder language has two new types of dynamic formulas. Read [¡φ]ψ as 'after the state is updated with φ, ψ is the case'; [♯φ]ψ stands for the statement 'after φ is upgraded in the state, ψ is the case'. Finally, read [⇑φ]ψ as 'after φ is lexically upgraded, ψ is the case'. We extend definition 3.3 once more. CHAPTER 6 77 Figure 6.1. The meaning of edges in doxastic and preference models is illustrated below. Substitute the specific notions 'more plausible than' or 'preferred over' for the general description 'better than' at will. w φ w′ ¬φ a aa w′ and ¬φ are better than w and φ. w φ w′ ¬φ a aa w, w′, φ, and ¬φ are equally good. Definition 6.2. Let the forcing relation «⊩» be as before, except for the following additional constraints: ⟨Mw⟩ ⊩ [¡φ]ψ ⟺ ⟨M|¡φw⟩ ⊩ ψ ⟨Mw⟩ ⊩ [♯φ]ψ ⟺ ⟨M|♯φw⟩ ⊩ ψ ⟨Mw⟩ ⊩ [⇑φ]ψ ⟺ ⟨M|⇑φw⟩ ⊩ ψ where M|¡φ ≔ M− {⟨aw′w′′⟩ ∈ M ∣ a ∈ IndP , and ⟨Mw′⟩ ⊩ φ xor ⟨Mw′′⟩ ⊩ φ}, M|♯φ ≔ M− {⟨aw′w′′⟩ ∈ M ∣ a ∈ IndP , ⟨Mw′⟩ ⊩ φ, and ⟨Mw′′⟩ ⊩ ¬φ}, and M|⇑φ ≔ {⟨aw′w′′⟩ ∣ a ∈ IndB,Maw′w′′ or Maw′′w′, ⟨Mw′⟩ ⊩ ¬φ, and ⟨Mw′′⟩ ⊩ φ} ∪ {⟨aw′w′′⟩ ∈ M ∣ a ∉ IndB or ⟨Mw′⟩ ⊩ φ ⟺ ⟨Mw′′⟩ ⊩ φ} CHAPTER 6 78 Fi gu re 6. 2. Ex am pl e of th e up da te op er at io n | ¡φ .I ti s as su m ed th at a ∈ In dP .T he re fle xi ve aed ge s ar e no td is pl ay ed . wφ w ′ ¬ φ w ′′φ w ′′′ ¬ φ w ′′′ ′ φ a a a a a a a a a a Th e or ig in al m od el M . w w ′ w ′′ w ′′′ w ′′′ ′ a a a a Th e up da te d m od el M | ¡φ . w w ′′ w ′′′ ′ w ′ w ′′′ a a a a A no th er lo ok at th e up da te d m od el M | ¡φ . Figure 6.3.Exam ple ofthe upgrade operation |♯ φ .Itis assum ed thata ∈ Ind P.Loops are om itted. w φ w ′ ¬ φ w ′′ φ w ′′′ ¬ φ w ′′′′ φ a a a a a a aa a a The originalm odelM . w w ′ w ′′ w ′′′ w ′′′′ a a a a a a a The upgraded m odelM |♯φ . w ′ w ′′′ w w ′′ w ′′′′ a a a a a a a The m odelM |♯φ once m ore. Fi gu re 6. 4. Ex am pl e of th e le xi ca lu pg ra de op er at io n | ⇑ φ .I ti s as su m ed th at a ∈ In dB .N ew ed ge s ar e dr aw n in re d. wφ w ′ ¬ φ w ′′φ w ′′′ ¬ φ w ′′′ ′ φ a a a a a a a a a a Th e m od el M . w w ′ w ′′ w ′′′ w ′′′ ′ a a a a a a a a a a Th e le xi ca lly up gr ad ed m od el M | ⇑ φ . w ′ w ′′′ w w ′′ w ′′′ ′ a a a a a a a a a a O nc e m or e th e m od el M | ⇑ φ . Table 6.1. For every [$φ]ψ and ¬[$φ]ψ] in the tableau (with $ a placeholder for ¡, ♯, and ⇑), we force every node to decide if φ or ¬φ should be true. Name Precondition Postcondition R¡ T n[¡φ]ψ and T n′ T n′φ or T n′¬φ T n¬[¡φ]ψ and T n′ T n′φ or T n′¬φ R♯ T n[♯φ]ψ and T n′ T n′φ or T n′¬φ T n¬[♯φ]ψ and T n′ T n′φ or T n′¬φ R⇑ T n[⇑φ]ψ and T n′ T n′φ or T n′¬φ T n¬[⇑φ]ψ and T n′ T n′φ or T n′¬φ In other words, the update operation |¡φ deletes all preference links between φ-worlds and ¬φ-worlds. The upgrade operation |♯φ, on the other hand, deletes only preference links from φ-worlds to ¬φ-worlds. Suppose an update operation |¡p (with p an atom) is performed. From the point of view of a p-world p then becomes preferable (as it would after a public announcement). Similarly,¬p becomes preferable for¬p-worlds. If an upgrade operation |♯p is performed, however, then p still becomes preferable for p-worlds but the preference of ¬p-worlds for p is not affected. The lexical upgrade operation |⇑φ changes doxastic plausibility orders. It makes φ-worlds more plausible than ¬φ-worlds. However, it only adds or removes a-edges between worlds that are connected over an a-edge to begin with. 6.3 Dynamic tableaux for dynamic preorder logics We will now construct a tableau system for LU◻¡♯⇑ along familiar lines. As usual, we start by adding rules for the dynamic operators. We add two rules for every dynamic modal operator. Definition 6.3. Let the mandatory rules of Rules (and Rulesσ) include the additional rules in table 6.1. CHAPTER 6 82 Adapting the operations |¡φ, |♯φ, and |⇑φ to a tableau setting is again straightforward. This results in the following definitions. Definition 6.4. For any two tableaux T and T ′ the relationship «T ¡φ −→ T ′» holds if and only if 1. T ′[?] = T [?]. 2. T ′[???] = T [???] − {⟨ann′⟩ ∣ a ∈ IndP , and T nφ xor T n′φ}. 3. T ′[??] ∩ (T ′[?] × Prop) = T [??] ∩ (T ′[?] × Prop). The relationship «T ♯φ −−→ T ′» holds if and only if 1. T ′[?] = T [?]. 2. T ′[???] = T [???] − {⟨ann′⟩ ∣ a ∈ IndP ,T nφ, and T n′¬φ}. 3. T ′[??] ∩ (T ′[?] × Prop) = T [??] ∩ (T ′[?] × Prop). The relationship «T ⇑φ −−→ T ′» holds if and only if 1. T ′[?] = T [?]. 2. T ′[???] = {⟨ann′⟩ ∣ a ∈ IndB,T ann′ or T an′n,T n¬φ, and T n′φ} ∪{⟨ann′⟩ ∈ T ∣ a ∉ IndB or T nφ ⟺ Tabn′φ} 3. T ′[??] ∩ (T ′[?] × Prop) = T [??] ∩ (T ′[?] × Prop). Again we ammend the notion of 'open tableau', akin to how we added truth schemas for our new operators to the semantics. Definition 6.5. Let the predicate «open» be as before, except for following added conditions: 1. If T n[¡φ]ψ then there are no open saturated tableaux T ′ for ⟨n¬ψ⟩ such that T ¡φ −→ T ′. 2. If T n¬[¡φ]ψ then there is an open saturated tableau T ′ for ⟨n¬ψ⟩ such that T ¡φ −→ T ′. CHAPTER 6 83 3. If T n[♯φ]ψ then there are no open saturated tableaux T ′ for ⟨n¬ψ⟩ such that T ♯φ −−→ T ′. 4. If T n¬[♯φ]ψ then there is an open saturated tableau T ′ for ⟨n¬ψ⟩ such that T ♯φ −−→ T ′. 5. If T n[⇑φ]ψ then there are no open saturated tableaux T ′ for ⟨n¬ψ⟩ such that T ⇑φ −−→ T ′. 6. If T n¬[⇑φ]ψ then there is an open saturated tableau T ′ for ⟨n¬ψ⟩ such that T ⇑φ −−→ T ′. As before we prove that |¡φ, |♯φ, and |⇑φ on the one hand and ¡φ −→, ♯φ −−→, and ⇑φ −−→ on the other hand are symmetric for φ-declarative tableaux and the models that natively satisfy them. Lemma 6.1. If M is the stock model of a φ-declarative tableau T such that M natively satisfies T up to ¬φ then it holds that 1. M|¡φ is the stock model for T ′ if and only if T ¡φ −→ T ′. 2. M|♯φ is the stock model for T ′ if and only if T ♯φ −−→ T ′. 3. M|⇑φ is the stock model for T ′ if and only if T ⇑φ −−→ T ′. Proof. The three cases are similar. Below we provide the proof for the first case. We leave the rest as an exercise for the reader Proof for the left-to-right part of the lemma. Assume that M|¡φ is the stock model of T ′. It follows that T ′[?] = T [?] and T ′[??] ∩ (T ′[?] × Prop) = T [??] ∩ (T ′[?] × Prop) since (i) the operation |¡φ doesn't delete worlds or labels, and (ii) M is the stock model of T . We also have that T ′[???] = M|¡φ[???]. From this it follows that T ′[???] = T [???]− {⟨ann′⟩ ∣ a ∈ IndP , and T nφ xor T n′φ} by definition of |¡φ and because M natively satisfies T up to ¬φ. This proves that T ¡φ −→ T ′. Proof from right to left. Assume that T ¡φ −→ T ′. It follows that T ′[?] = T [?] and T ′[??] ∩ (T ′[?] × Prop) = T [??] ∩ (T ′[?] × Prop) by definition CHAPTER 6 84 of ¡φ −→. Similarly, M|¡φ[?] = M[?] and M|¡φ[??] = M[??] by definition of |¡φ. Since M is the stock model of T it now follows that M|¡φ[?] = T ′[?] and M|¡φ[??] = T ′[??] ∩ (T ′[?] × Prop). Because M natively satisfies T up to ¬φ, we have T nφ ⟺ ⟨Mn⟩ ⊩ φ for all n ∈ T [?]. By definition of ¡φ −→ it now also follows that M|¡φ[???] = T [???]. This concludes the proof that M|¡φ is the stock model for T ′. We extend lemma 3.7 once more and prove that our new tableau rules preserve satisfiability. Lemma 6.2. If a σ-model M satisfies a tableau T via a function f then it is the case that 1. If T is not R¡-saturated then there is a tableau T ′ ∈ R¡[T ] − {T } and a function f′ such that M satisfies T ′ via f′. 2. If T is not R♯-saturated then there is a tableau T ′ ∈ R♯[T ] − {T } and a function f′ such that M satisfies T ′ via f′. 3. If T is not R⇑-saturated then there is a tableau T ′ ∈ R⇑[T ]− {T } and a function f′ such that M satisfies T ′ via f′. Proof. The four cases are similar. We only present the proof for the first one. Suppose R¡ is triggered by T n[¡φ]ψ and T n′. Because it is assumed that ⟨Mf(n)⟩ ⊩ [¡φ]ψ it follows that ⟨M|¡φf(n)⟩ ⊩ ψ. Thus, let f′ ≔ f. Similarly, if T n¬[¡φ]ψ and T n′ then not ⟨M|¡φf(n)⟩ ⊩ ψ. Again, let f′ ≔ f. It is now time to prove soundness and completeness. As before we use mutual induction. Lemma 6.3 (Lemma to Soundness and Completeness). Given a stock model M for a saturated tableau T , 1. If M natively satisfies T and T is a tableau for φ then T is open. CHAPTER 6 85 2. If T is open and T nφ then ⟨Mn⟩ ⊩ φ. Proof. Proof by mutual induction on the length of φ. Assume that the lemma holds for all ψ shorter than φ. Part 1. • In lemmas 3.7 and 6.2 it is proved that T is free of literal contradictions. • For all ⟨n[¡ψ]χ⟩ ∈ T it must be demonstrated that there is no open saturated tableau T ′ for ⟨n¬χ⟩ such that T ¡ψ −→ T ′. Proof by contradiction. Suppose such a tableau T ′ did exist. By Part 2 of the IH it is then the case that, with M′ the stock model of T ′, ⟨M′n⟩ ⊩ ¬χ. From R¡ and the premise that T is saturated it follows that T is ψ-declarative. By lemma 6.1 it now follows that M′ = M|¡ψ. However, since M natively satisfies T it is the case that ⟨Mn⟩ ⊩ [¡ψ]χ and ⟨M|¡ψn⟩ ⊩ χ. This ends the proof by contradiction. • For all ⟨n¬[¡ψ]χ⟩ ∈ T it must be demonstrated that there is an open saturated tableau T ′ for ⟨n¬ψ⟩ such that T ¡ψ −→ T ′. As M natively satisfies T it is the case that ⟨Mn⟩ ⊩ ¬[¡ψ]χ. By definition of [¡ψ] and ¬ it follows that ⟨M|¡φn⟩ ⊩ ¬χ. By Part 1 of the IH it follows that the stock tableau T ′ for ⟨M|¡φn¬ψ⟩ is open. Moreover, T is ψ-declarative because of R¡. By lemma 6.1 it now follows that T ¡ψ −→ T ′ and this concludes our proof. • The proof for other dynamic formulas of LU◻¡♯⇑ are entirely analogous to the proofs for formulas [¡ψ]χ and their negations. Part 2. The bulk of this proof has already been covered in lemma 3.9. We only provide the proofs for the patterns specific to LU◻¡♯⇑. • Suppose φ is [¡ψ]χ. It has to be demonstrated that ⟨M|¡ψn⟩ ⊩ χ. Proof by contradiction. Assume that ⟨M|¡ψn⟩ ⊩ ¬χ. CHAPTER 6 86 By Part 1 of the IH it follows that any stock tableau T ′ for ⟨M|¡ψn¬χ⟩ is open. Moreover, T is ψ-declarative by R¡. By Part 2 of the IH it follows that M natively satisfies T up to ¬ψ. By lemma 6.1 it now follows that T ¡ψ −→ T ′. However, since T is an open tableau we know that there is no saturated open tableau T ′′ for ⟨n¬χ⟩ such that T ¡ψ −→ T ′′. This concludes the proof by contradiction. • Suppose φ is ¬[¡ψ]χ. We need to demonstrate that ⟨M|¡ψn⟩ ⊩ ¬χ. First, since T is open it follows that there is an open saturated tableau T ′ for ⟨n¬χ⟩ such that T ¡ψ −→ T ′. Second, T is ψ-declarative by R¡. Hence, by Part 2 of the IH it also follows that M natively satisfies T up to ¬ψ. By lemma 6.1 it is now the case that M|¡ψ is the stock model of T ′. Finally, again by Part 2 of the IH, it is the case that ⟨M|¡ψn⟩ ⊩ ¬χ. • The proofs for [♯ψ]χ, [⇑ψ]χ, and their negations are similar to those of [¡ψ]χ and ¬[¡ψ]χ. 6.4 Decidability of tableaux for LU◻¡♯⇑ In this section we construct a decidable proof procedure for LU◻¡♯⇑. We proceed along familiar lines. That is, we define priming operations for the dynamic formulas of this language and we show that priming and synchronizing operations preserve satisfiability. But first we define what satisfaction means for tableau cascades in light of our new operators. Definition 6.6. A pointed tableau cascade ⟨Ct⟩ is «satisfied» by a model M via a function f if and only if • M satisfies C(t?) via f. • For every ⟨ ¡φ −→t′⟩ ∈ C[?t?] it is the case that M|¡φ satisfies ⟨Ct′⟩ via f. CHAPTER 6 87 • For every ⟨ ♯φ −−→t′⟩ ∈ C[?t?] it is the case that M|♯φ satisfies ⟨Ct′⟩ via f. • For every ⟨ ⇑φ −−→t′⟩ ∈ C[?t?] it is the case that M|⇑φ satisfies ⟨Ct′⟩ via f. We say that a tableau cascade C is satisfied by a model M via a function f if and only if ⟨C root(C)⟩ is satisfied by M via f. If desired the above definition could be made compatible with definitions 4.9 and 5.8. This would result in a decidable tableau system for the language that results from combining all previously defined operators. We now define a priming operation for our new operators. Definition 6.7. C ′ is the result of «¡♯⇑-priming» a tableau cascade C if and only if C ′ is a minimal extension of C (and the tableau therein) such that for all ⟨tT ⟩ ∈ C , • If φ = [¡φ]ψ then there is a node-tableau pair ⟨t′T ′⟩ ∈ C ′ such that T ′ is a tableau for ⟨nψ⟩ and ⟨ ¡φ −→tt′⟩ ∈ C ′. • If φ = ¬[¡φ]ψ then there is a node-tableau pair ⟨t′T ′⟩ ∈ C ′ such that T ′ is a tableau for ⟨n¬ψ⟩ and ⟨ ¡φ −→tt′⟩ ∈ C ′. • If φ = [♯φ]ψ then there is a node-tableau pair ⟨t′T ′⟩ ∈ C ′ such that T ′ is a tableau for ⟨nψ⟩ and ⟨ ♯φ −−→tt′⟩ ∈ C ′. • If φ = ¬[♯φ]ψ then there is a node-tableau pair ⟨t′T ′⟩ ∈ C ′ such that T ′ is a tableau for ⟨n¬ψ⟩ and ⟨ ♯φ −−→tt′⟩ ∈ C ′. • If φ = [⇑φ]ψ then there is a node-tableau pair ⟨t′T ′⟩ ∈ C ′ such that T ′ is a tableau for ⟨nψ⟩ and ⟨ ⇑φ −−→tt′⟩ ∈ C ′. • If φ = ¬[⇑φ]ψ then there is a node-tableau pair ⟨t′T ′⟩ ∈ C ′ such that T ′ is a tableau for ⟨n¬ψ⟩ and ⟨ ⇑φ −−→tt′⟩ ∈ C ′. The new priming operation preserves the property that if a tableau cascade C is satisfiable then so is any tableau cascade that results from priming C . CHAPTER 6 88 Lemma 6.4. Given a tableau cascade C that is satisfied by a model M⋆ via a function f, if C ′ is the result of ¡♯⇑-priming C then C ′ is satisfied by M⋆ via f. Proof. Suppose ⟨n[¡φ]ψ⟩ ∈ T , where T is a tableau in C , and suppose T ′ = {n, ⟨nφ⟩} is a tableau in C ′ but not C . LetM′ be anymodel andf′ any function such that ⟨M′f′(n)⟩ ⊩ [¡φ]ψ. Such a model exists by assumption and we want to prove that ⟨M′|¡φf′(n)⟩ ⊩ ψ. In fact, this immediately follows from the definition of [¡φ]. It also follows that M⋆ satisfies C ′ via f. The proofs for negated [¡φ] formulas and for the other operators are structurally identical to the above case and we omit them here. Synchronization also preserves satisfiability. Lemma 6.5. Where $ stands for ¡, ♯, or ⇑, let C be a tableau cascade such that ⟨ $φ −−→tt′⟩ ∈ C and such that C(t?) is satisfied by a model M via a function f and C(t′?) is satisfied by M|$φ via f. If C can be synchronized such that at most t and t′ are affected then there's an outcome C ′ of synchronizing C such that M satisfies C ′(t?) via f and M|$φ satisfies C ′(t′?) via f. Proof. The proofs are similar to the proof for lemma 4.10. We have now implemented the scaffolding for using dynamic tableaux in a completely automated fashion. Theorem 6.6. If there is a pointed σ-model ⟨Mw⟩ such that ⟨Mw⟩ ⊩ φ (where φ ∈ LU◻¡♯⇑) then an open saturated σ-tableau T for ⟨wφ⟩ can be found in a finite number of steps. Proof. Our dynamic tableaux for preorder logics introduce no difficulties that were not already covered in theorem 4.11. Therefore, we omit the decidability proof. CHAPTER 6 89 6.5 Related work To the best of our knowledge no tableau system exists for dynamic doxastic logic. We also don't know of a tableau system that directly implements dynamic preference logic. Indirectly, however, such tableau systems exist since the update and upgrade operations discussed in this chapter can be represented by action models. Lexical upgrades cannot be modeled by the operation |⊗φ. In [6] this limitation is explained and an alternative kind of action model update-named 'action-priority update'-is presented that can express lexical upgrades. Again, though, we know of no tableau system for action priority update logic. The lexical upgrade operator was first introduced in [33]. See [5, §1] for a discussion of how it relates to the formalisms in [6] and in this chapter. For a detailed discussion of dynamic preference logics, see [28]. CHAPTER 6 90 7 Clojure Implementation In this chapter we present a proof-of-concept computer implementation of our dynamic tableau system for public announcement logic. It is implemented in the programming language Clojure. Clojure is a functional programming language in the style of LISP. It is a young programming language but has several things going for it that make it well-suited to our purposes. Functional programming languages are heavily inspired by lambda calculus. Unlike most other types of programming languages this means that they are organized in a way to encourage the use of immutable data structures and functions as primary means of abstraction. This makes such languages a good fit for implementing procedures that were first described using mathematical notation. Allow us to illustrate this point with an example. Computer programs usually store ordered sequences of elements in one of two data structures-'lists' or 'vectors'. Ignoring implementation details, the key difference is that it's very fast to access, add, or remove elements at the front of a list, whereas it's very fast to access elements from a vector regardless their position in the sequence. The trade-off is that adding or removing elements at the front of a vector is slower. Suppose that we want to sort a vector. In a functional programming language we would use a procedure- called a function-that yields or 'returns' a new vector. In other (imperative) languages the original vector is typically modified and the original data is lost. Using Clojure also has performance advantages because Clojure programs are executed on the Java Virtual Machine (JVM). Clojure programs are trans91 lated or 'compiled' to an intermediate representation called 'Java bytecode'. The JVM is then asked to run this bytecode. The JVM is a mature software platform and is very efficient at this task. Another advantage is that Clojure has good abstractions for writing code that performs tasks in parallel. Performance benefits are important because theorem provers are inherently computationally intensive applications. Code parallelism is especially important because in recent years high-end computer processors have only seen modest year-over-year improvements with respect to running sequential programs. There are, on the other hand, clear trends towards more parallel computing architectures. Clojure programs are highly portable. First of all, because they are run on the JVM they can be executed on any computer architecture and operating system that can run Java programs. This includes Windows, OS X, Linux, and Android. Second, there is a dialect of Clojure that is compiled to JavaScript. This dialect, named ClojureScript, is very similar to Clojure and it is in fact typical that large parts of a Clojure programs are also valid ClojureScript code. Such programs could, for instance, be run on the JVM when performance is essential and in a web browser when user-friendly distribution of the program is deemed more important. In the remainder of this chapter we implement the proof system from chapter 4 in Clojure. We present it as a proof-of-concept. We set out to create highly parallel code but also tried to be true to the core principles of our approach. This means that we refrained from trying several optimizations that we felt might work. We leave these for further research. 7.1 A brief overview of Clojure In this section we briefly outline the major distinguishing features and syntax of Clojure. We refer the reader to [17] for a more thorough introduction to this programming language. Being a variant on LISP, Clojure is homoiconic. This means that it is possible to interpret Clojure source code in terms of Clojure data structures in a straightforward way. Take the following program: CHAPTER 7 92 1 ( defn is−even? [n] 2 ( i f (= (mod n 2) 0) 3 true 4 fa lse ) ) The above code is represented by the following list: • The 'symbol' ‹defn›. • The symbol ‹is−even?›. • The following vector: – The symbol ‹n›. • The following list: – The symbol ‹if›. – The following list: * The symbol ‹=›. * The following list: * The symbol ‹mod›. * The symbol ‹n›. * The integer ‹2›. * The integer ‹0›. This is also called an abstract syntax tree (AST). In a Clojure AST, symbols are usually names or 'bindings'. Bindings are primarily lexically scoped. This means they behave like lambda abstraction. The code above defines a function ‹is−even?› that takes one argument, bound to ‹n›. The function itself is in fact bound by ‹defn› to the variable name ‹is−even?› in the current 'namespace'. It can also be accessed from other namespaces or files. We'll look into how to do this in a bit. For now we merely want to point out that the code above already uses this feature: The functions ‹=› and ‹mod› are actually defined in the namespace ‹clojure.core›. CHAPTER 7 93 In Clojure programs, lists are usually interpreted as invocations of functions, 'special forms', or 'macros'. Special forms are used for fundamental constructs like if-then-else branching, variable declarations, and function definitions. We will discuss macros later on. The first element in a list is the name of the function, special form, or macro. It is executed with the remaining elements in the list serving as arguments. Other data structures-including vectors, numbers, and booleans-are not evaluated further. Therefore the Clojure code ‹[1 2 3]› corresponds to a vector of the numbers 1, 2, and 3 in the AST and in the program. Observe that we cannot include a list of the numbers 1, 2, 3 in our program by typing ‹(1 2 3)›. Instead we are expected to type ‹( list 1 2 3)›. With the very basics out of the way, let's look at those functions, special forms, and macros built-in to Clojure that we will be using. We will also introduce some extra syntax along the way. We start by giving some more examples of ‹if› statements, and of the special form ‹cond›. Note that semicolons start a comment and absorb everything up to the end of the line. Strings (sequences of characters) are surrounded by double quotes. 5 ( i f fa lse 1 2) ; 2 6 ( i f n i l 1 2) ; 2 7 ( i f " for sure" 1 2) ; 1 ( only fa l se and n i l are ' falsy ' ) 8 ( i f fa lse 1) ; n i l 9 ( if−not false 1 2) ; 1 10 11 ; a s ingle cond−statement can replace multiple if−statements 12 ( cond (= 1 3) :one 13 (= 2 3) :two 14 (= 3 3) : three 15 : e l se :i−give−up ) To define a variable the 'special form' ‹def› is used. 16 ( def x " tex t " ) 17 ; the variable x i s bound to " tex t " from th i s point on CHAPTER 7 94 There are several ways to create functions. 18 ( defn f [ x y ] 19 (+ x y ) ) 20 ; from here on ( f 3 4) evaluates to 7 21 22 ( def f ( fn [ x y ] (+ x y ) ) ) ; th i s has the same ef fec t 23 24 ( ( fn [ x ] ( * x x ) ) 3) ; 9 Functions that are not assigned a variable name are often called lambdas. There's also a special form for creating functions with exactly one argument. 25 #( * % %) ; equivalent to ( fn [ x ] ( * x x ) ) The following syntax enables us to create functions that take a variable number of arguments. 26 ( defn count−args [ x & xs ] (+ 1 ( count xs ) ) ) 27 ; ( count−args "a" 10 5.2 [1 2 3 4 5 ] ) evaluates to 4 Above, in the function body of ‹count−args›, ‹x› evaluates to ‹"a"› and ‹xs› evaluates to the list ‹(10 5.2 [1 2 3 4 5])›. Functions can dispatch to different bodies of code depending on the number of arguments passed. 28 ( defn f 29 ( [ ] "zero" ) ; ( f ) −> "zero" 30 ( [ x ] "one" ) ; ( f n i l ) −> "one" 31 ( [ x y ] "two" ) ; ( f "a" "b" ) −> "two" 32 ( [ x y & xs ] "more" ) ) ; ( f [ ] [ ] [ ] ) −> "more" Function arguments that are vectors can also be 'destructured'. That is to say, the elements of the vector can directly be assigned to individual variables. Here's an example: 33 ( defn str−birthday [name [ [ year month day ] place ] ] 34 ( str name " was born in " place 35 " on " day " " CHAPTER 7 95 36 ( get {1 "January" ; e t c . 37 6 "June" ; e t c . 38 12 "December" } 39 month) 40 " " year " . " ) ) 41 ; e . g . ( str−birthday "Rousseau" [[1712 6 28] "Geneva " ] ) The above example also illustrates the use of 'maps' (or dictionaries). We discuss more examples of maps further down. The function ‹str› converts each of its arguments to a string and appends the results. Bindings can also be introduced using the special form ‹let›. 42 ( defn f [n ] 43 ( l e t [ x ( * n n) 44 y ( * x x ) ] 45 (+ y 1 ) ) ) 46 ; equivalent to (+ ( * n n n n) 1) Note that it's also possible to use destructuring in combination with ‹let›. We also want to use this opportunity to mention an advanced destructuring feature. It is possible to destructure a sequence-that is, a list or a vector-and create a binding for the entire sequence at the same time 47 ( l e t [ [ a b & xs :as l ] [1 2 3 4 5 ] ] 48 l ) 49 ; [1 2 3 4 5] Here's a variant on ‹let› for defining functions: 50 ( let fn [ ( f [ x ] ( inc x ) ) ] 51 ( f 3 ) ) Note that the functions ‹inc› and ‹dec› increment and decrement their argument by one. Clojure has a unique syntax for loops. 52 ( defn repeat−string [n s ] 53 ( loop [n n CHAPTER 7 96 54 acc " " ] 55 ( i f (= n 0) 56 acc 57 ( recur ( dec n) ( str acc s ) ) ) ) ) 58 ; ( repeat−string 5 "ab" ) evaluates to "ababababab" Every time ‹recur› is used, new values are bound to ‹n› and ‹acc› and the loop body is executed once more. The first thing at the top of a Clojure source file is normally a namespace declaration. For this, ‹ns› is used; ‹ns› is also used to make outside namespaces accessible. 59 ( ns myproject.this 60 ( : require [ clojure.core.reducers :as r ] 61 [ c lo jure .set : r e fe r : a l l ] 62 [ myproject.that ] ) ) The above instruction makes the function ‹map› from the namespace ‹clojure.core.reducers› accessible as ‹r/map›. It also binds the ‹intersection› to the intersection function from the namespace ‹clojure.set›. Functions and macros from ‹clojure.core› are made available without a prefix by default. Since the namespace of this file is called ‹myproject.this›, the file should be stored in file named 'this.clj' in a folder 'myproject'. Similarly the last line loads the file 'that.clj' in the same folder. The syntax for ‹ns› is a bit peculiar as ‹:require› is not a function but a keyword. All terms starting with a colon are keywords. You can think of keywords as strings that are not intended to be manipulated and are not intended to be ever shown to the user. Still, the question remains why ‹:require› is at the start of a list. Without disclosing the details we want to use this case as a segue to one feature typical of homoiconic languages. Macros allow powerful transformations on parts of the Clojure AST. When a macro is invoked, the expressions passed to it are rewritten into a new expression. This happens at compile time. The program is only run after all macros have expanded into macro-free code. Macros are a great feature because they allow Clojure to have a simple yet extensible syntax. CHAPTER 7 97 There are two important macros that we will use throughout this chapter. They are called the 'threading' macros. The macro ‹−>› takes a variable number of arguments. Given two expressions for arguments, the second one being a list, it inserts the first expression as the second element of the second expression. Given a third argument-also a list-it inserts the resulting expression as the second element of the third expression. And so on. 63 (−> foo 64 ( bar baz ) ) 65 ; expands to ( bar foo baz ) 66 67 (−> foo 68 ( bar baz ) 69 ( qux quux quuux ) ) 70 ; expands to ( qux ( bar foo baz ) quux quuux ) The second threading macro ‹−>>› is similar to ‹−>› but inserts results as the last, rather than second, element of the next expression. 71 (−>> foo 72 ( bar baz ) ) 73 ; expands to ( bar baz foo ) 74 75 (−>> foo 76 ( bar baz ) 77 ( qux quux quuux ) ) 78 ; expands to ( qux quux quuux ( bar baz foo ) ) Relatedly, the function ‹apply› can be used to change how functions are called. The special form ‹partial› can be used for partial application of functions. 79 ( apply + [1 2 3 4 ] ) ; equivalent to (+ 1 2 3 4) 80 81 ( def f ( part ia l + 1 2 3 ) ) 82 ( f 4 5) ; ( + 1 2 3 4 5) CHAPTER 7 98 Let's now turn our attention to functions that operate on collections-lists, vectors, sets, and maps. Once more we illustrate their usage by example. 83 ( l i s t 1 2 3 4) ; l i s t 84 ( conj ( l i s t 1 2 3 4) 5) ; ( l i s t 5 1 2 3 4) ( prepends ) 85 ( cons 1 ( l i s t 2 3 4 5 ) ) ; ( l i s t 1 2 3 4 5) 86 87 [1 2 3 4] ; vector 88 ( vector 1 2 3 4) ; same 89 ( conj [1 2 3 4] 5) ; [1 2 3 4 5] ( appends ) 90 ( cons 1 [2 3 4 5 ] ) ; ( l i s t 1 2 3 4 5) 91 92 ( f i r s t [1 2 3 ] ) ; 1 93 ( second ( l i s t 1 2 3 ) ) ; 2 94 ( nth [1 2 3] 2) ; 3 95 ( next [1 2 3 ] ) ; [2 3] 96 97 #{1 2 3 4} ; se t 98 ( hash−set 1 2 3 4) ; same 99 ( contains? #{1 2 3} 3) ; true 100 ( conj #{1 2 3 4} 5) ; #{1 2 3 4 5} 101 102 { : a 1 :b 2 : c 3} ; map 103 (hash−map :a 1 :b 2 : c 3) ; same 104 ( get { :a 1 :b 2 : c 3} :b ) ; 2 105 ( conj { :a 1 :b 2} [ : c 3 ] ) ; adds a key−value pair 106 ( assoc { :a 1 :b 2} : c 3) ; same 107 108 ( count [1 2 3 ] ) ; 3 109 110 ( into [1 2] [3 4 ] ) ; same as ( conj ( conj [1 2] 3) 4) We need to do a lot of computations on collections. For this purpose we use Clojure's 'combine-reduce' infrastructure. It allows us to perform such operations efficiently. CHAPTER 7 99 Every collection we have mentioned is 'reducible'. This means they can be transformed using the functions ‹map›, ‹mapcat›, and ‹ filter › from the namespace ‹clojure.core.reducers›. This yields a new but abstract collection. This abstract collection keeps a reference to the original collection and to the operations that have to be performed. Notice that ‹map› and the other functions we just mentioned don't actually perform any transformations on the original collection. Afterwards the function ‹reduce› can be used to materialize the modified collection as, for example, a vector. Some collections are also 'foldable'. For these collections the function ‹fold› can be used instead of ‹reduce› to perform the scheduled transformations in parallel. When ‹fold› is applied to a non-foldable but reducible collection it simply calls ‹reduce›. We illustrate by example. Assume the namespace ‹clojure.core.reducers› has been aliased to ‹r›. 111 (−>> [1 10 100 1000] ; or ig inal co l l e c t i on 112 ( r/map #( * 2 %) ) ; multiply every element by 2 113 ( r/reduce conj # { } ) ) ; conj every element into a set 114 ; #{2 20 200 2000} 115 116 (−>> [1 10 100 1000] 117 ( r/mapcat ( fn [ x ] [ x ( * 2 x ) ] ) ) 118 ; 1 , 2 , 10 , 20 , 100, 200, 1000, 2000 119 ( r/ f i l t e r #(> % 100)) 120 ; 200, 1000, 2000 121 ( r/reduce conj [ 5 ] ) ) 122 ; [5 200 1000 2000] 123 124 (−>> ( range 1 5000) ; create a non−foldable co l l e c t i on 125 ( apply vector ) ; convert the l i s t to a ( foldable ) vector 126 ( r/map −) 127 ( r/ fold ( fn 128 ( [ ] # { } ) 129 ( [ l e f t right ] ( into l e f t right ) ) ) CHAPTER 7 100 130 conj ) ) 131 ; #{−1 −2 −3 −4 −5 −6 −7 −8 −9 −10 . . . } The first type of argument passed to ‹fold› is called a monoid in Clojure parlance. Clojure monoids are functions that, when passed zero arguments, return an identity element. When passed two arguments, both of the same type as the identity element, it combines them. This latter operation must be associative. This also explains why they are called monoids-their namesake algebraic structures are structures that contain an identity element and an associative operation. When ‹fold› is applied to a foldable collection, the collection is partitioned into large classes of elements. The previously discussed function ‹reduce› is applied to every one of these classes. Its first argument is the second argument passed to ‹fold› (in the example above this function is ‹conj›) and its second argument is the monoid's identity element. It is also possible to apply ‹map› (the function) to maps (the data structure). Simply pass a function to ‹map› that takes two arguments-a key and a value. 132 (−>> { :a 1 :b 2} 133 ( r/map ( fn [ key val ] [ key (− val ) ] ) ) 134 ( r/ fold ( r/monoid into ( constantly { } ) ) conj ) ) 135 ; { : a −1 :b −2} The function ‹constantly› creates a function that takes any number of arguments and always returns the same value. The function ‹monoid› creates a monoid, where the first argument is the combining function and the second argument is a function that returns the identity element. Notice that, as a matter of fact, the original map in the previous example is small and would therefore not actually be processed in parallel. A naive way to fold a collection ‹coll› would be to write the following code: 136 ( r/ fold ( r/monoid into vector ) conj co l l ) This, however, involves a lot of unnecessary copying. For first the collection is divided into several parts-provided it is foldable and contains many elements-and each of these parts is reduced to a vector. Afterwards the CHAPTER 7 101 elements of these vectors, starting from the second vector, are appended to the first one. A better solution is to write ‹(r/foldcat coll)›. This will first reduce different parts of ‹coll› to a vector-like structure (technically, Java's ‹ArrayList›) and append them in a list-like structure. The result is usually foldable-we omit the specifics but will come back to this at the end of section 7.6. ‹foldcat› uses the monoid ‹cat› internally. This monoid can also be used to concatenate two foldable collections. 137 ( r/cat coll1 coll2 ) 138 ; s imilar to ( into co l l1 co l l2 ) , but faster Finally, we want to mention that it's sometimes possible to omit the second argument-the function to use in the reducing phase-to ‹fold›. In this case the monoid is used instead. 139 ( r/ fold ( r/monoid + ( constantly 0 ) ) 140 ( apply vector ( range 0 10000))) 141 ; equals ( apply + ( range 0 10000)) We have now discussed the basics of Clojure. We use more features of Clojure than have been explained so far, but we will explain these as we discuss our Clojure program. 7.2 Utility functions We start by defining a namespace ‹dyntab.util›. Here we define functions that will prove useful, but are more broad in scope than our current enterprise- creating a theorem prover. First, we register the namespace and load two required Clojure package. We already discussed the package ‹clojure.core.reducers› in the previous section. The functions in ‹clojure.set› have self-explaining names. 1 ( ns dyntab.uti l 2 ( : require [ clojure.core.reducers :as r ] 3 [ c lo jure .set :as set ] ) ) CHAPTER 7 102 We will make a lot of use of multi-maps. We represent them using maps that have sets for values. 4 ( defn mmap−get [m k] 5 ( get m k # { } ) ) 6 7 ( defn mmap−conj [m [k v ] ] 8 ( assoc m k ( conj (mmap−get m k) 9 v ) ) ) 10 11 ( defn mmap−merge [& ms] 12 ( apply merge−with into ms) ) 13 14 ( defn map−merge−overwrite [& ms] 15 ( apply merge−with ( fn [ x y ] y ) ms) ) 16 17 ( defn mmap−get−unique [m k] 18 ( l e t [ v (mmap−get m k ) ] 19 ( if−not (= ( count v ) 1) 20 ( throw ( str "No unique value for " k " in " m) ) ) 21 ( f i r s t v ) ) ) 22 23 ( defn mmap−diff [m1 m2] 24 (−>> m1 25 ( r/map ( fn [ [ k v ] ] 26 [ k ( set/difference v ( get m2 k # { } ) ) ] ) ) 27 ( r/ f i l t e r ( fn [ [ k v ] ] 28 ( not (= v # { } ) ) ) ) 29 ( r/reduce conj { } ) ) ) The first function here, ‹mmap−get› is straightforward. When querying a multi-map, if there's no value that corresponds to our key ‹k› then we prefer to get an empty set rather than the value ‹nil›. The second function, ‹mmap−conj›, defines the preferred way of adding a single element to a multimap-viz. by adding it to the set currently associated with its key. CHAPTER 7 103 Next we have two functions for merging (multi-)maps. The first merge function assigns to every key ‹k› the union of all sets associated with ‹k› in the multi-maps ‹ms›. The second merge function represents a different way of 'merging' multi-sets. To every key ‹k› it assigns the value associated with ‹k› in the rightmost multi-map ‹m› (in the order that they are passed to ‹mmap−merge−overwrite›) that assigns a nonempty set to ‹k›. ‹mmap−merge−overwrite› assumes that whenever a multi-map assigns a nonempty set to a key ‹k›, it internally stores no value at all for ‹k›; this is a difference that is 'hidden' by ‹mmap−get›. The call ‹(mmap−get−unique m k)› is a shorthand for the expression ‹( first (mmap−get m k))›, except that it raises an error if ‹m› does not associate a singleton with the key ‹k›. Finally, the function ‹mmap−diff› returns the multi-map that assigns to every ‹k› the set that results from subtracting the set associated with ‹k› in the second argument from the set associated with ‹k› in the first argument. The following function is an efficient way to check if a foldable collection that results from applying ‹mapcat› or ‹ filter › is empty. (For other collections, ‹count› can be used.) 30 ( defn fold−empty? [ co l l ] 31 ( r/ fold ( fn 32 ( [ ] true ) 33 ( [ l e f t right ] ( and l e f t right ) ) ) 34 ( constantly false ) 35 co l l ) ) Maps and sets will be our preferred data types for storing collections of objects. The following function folds a foldable collection into a set. 36 ( defn foldset [ co l l ] 37 ( r/ fold set/union conj co l l ) ) Next up is the function ‹rjuxt›. Given a collection ‹coll› and a function ‹f› that maps every element of ‹coll› onto a set, ‹rjuxt› returns a foldable collection of all lists ‹[x y]› such that ‹x› is an element of ‹coll› and ‹y› is an element of ‹(f x)›. CHAPTER 7 104 38 ( defn rjuxt [ f co l l ] 39 ( r/mapcat ( fn [ x ] ( r/map ( fn [ y ] [ x y ] ) 40 ( f x ) ) ) 41 co l l ) ) Given a sequence of sets, the following function first removes the empty sets and then returns the Cartesian product of the remaining sets. 42 ( defn one−from−each [ coll−of−colls ] 43 ( let fn [ [ f [ acc rem] 44 ( cond (empty? rem) [ acc ] 45 ( empty? ( f i r s t rem ) ) ( f acc ( next rem ) ) 46 : e l se (−>> ( f i r s t rem) 47 ( r/mapcat #( f ( conj acc %) 48 ( next rem ) ) ) ) ) ] ] 49 ( f # { } coll−of−colls ) ) ) With the above definitions we have enough tools to build a theorem prover. 7.3 Syntax We start by defining the syntax. We interpret the keywords ‹:p›–‹ :t › as atomic propositions and the keywords ‹:a›–‹:e› as indices. 1 ( ns dyntab.syntax ) 2 3 ( def Prop #{ :p :q : r : s : t } ) 4 5 ( def Ind #{ :a :b : c :d :e } ) Complex formulas are represented by vectors. Thus we write the negation of ‹A› as ‹[:not A]›, the conjunction of ‹A› and ‹B› as ‹[:and A B]›, box-‹x› ‹A› as ‹[:box x A]›, and '‹B› holds after announcing ‹A›' as ‹[ :! A B]›. The function ‹wff?› tests if its argument is a well-formed formula. CHAPTER 7 105 6 ( defn wff? [ form] 7 ( try 8 ( case [ ( count form) ( nth form 0) ] 9 [2 :not ] ( wff? ( nth form 1) ) 10 [3 :and ] (and ( wff? ( nth form 1) ) 11 ( wff? ( nth form 2 ) ) ) 12 [3 :box ] (and ( contains? Ind ( nth form 1) ) 13 ( wff? ( nth form 2 ) ) ) 14 [3 : ! ] ( and ( wff? ( nth form 1) ) 15 ( wff? ( nth form 2 ) ) ) 16 fa lse ) 17 ( catch Exception x ; not a co l l or empty co l l 18 ( contains? Prop form ) ) ) ) The ‹case› construct matches the result of clj(count form) and ‹nth form 0› against four possibilities. If matching fails then ‹false› is returned. If ‹form› is a proposition (or otherwise not a collection) then ‹(count form)› raises an exception or error. Similarly, if ‹form› is an empty collection then ‹(nth form 0)› raises an exception. In these case we return ‹true› if and only if ‹form› is an atomic proposition. 7.4 Tuple bags In this section we define the data type that we will use to store lgraphs. We call this data type a 'tuple bag'. We start by defining the namespace ‹tableaux.bag› and importing two familiar packages. 1 ( ns dyntab.bag 2 ( : require [ clojure.core.reducers :as r ] 3 [ dyntab.uti l :as u ] ) ) Next, we define the 'interface' ‹ITupleBag›. 4 ( defprotocol ITupleBag CHAPTER 7 106 5 ( post [ this co l l ] ) 6 ( query [ this k ] ) 7 ( newest [ this k ] ) 8 (mark [ this marker ] ) 9 ( since [ this marker ] ) 10 ( process [ this marker rules ] ) ) In a sense, what we say is that to be a tuple bag is to implement the following functions: • Given a tuple bag and a collection of 'messages', ‹post› sends every one of these messages to a 'indexer' (internal to the tuple bag). This indexer assigns zero or more keys to the message. The updated tuple bag is returned. • Given a tuple bag and a key, ‹query› returns the set of messages associated with that key. • Given a tuple bag and a key, ‹newest› looks up the last time a ‹post› invocation assigned one or more messages to that key. It returns the set of those messages (or the empty set if no such messages were posted). • Given a tuple bag and a keyword, ‹mark› returns a new tuple bag. The keyword serves as an annotation in the history of posts. • Given a tuple bag and a keyword, ‹since› returns a multi-map of those messages-and the keys they were assigned to-added since the tuple bag was marked with the given keyword. If a message is posted twice, only the first time it was posted is taken into account. • Given a tuple bag, a keyword, and a collection of rules, the function ‹process› looks up what messages were posted ‹since› the tuple bag was marked with the given keyword. These messages (and their keys) are processed by the given rules. Rules are functions. When called with no arguments, a rule return a key indicating that it can process messages that are associated with that key. CHAPTER 7 107 ‹process› calls these rules with two arguments-viz. the tuple-bag (after marking it) and a new message. Rules return foldable collections. ‹process› returns a list of the following elements: (i) the tuple bagmarked with the given keyword and (ii) the union of the foldable collections returned by the rules. These are the functions through which we interact with tuple bags. We explain what indexers and rules are further down. First we define the data type ‹TupleBag›. Here we specify how we will, as a matter of fact, store tuple bags in memory. We also define a function for creating tuple bags with a given collection of indexers but no messages initially. 11 ( defrecord TupleBag [ indexers everything newest history ] ) 12 13 ( defn tuple−bag [ indexers ] 14 ( TupleBag. indexers { } { } ( l i s t ) ) ) Notice that our tuple bag initially contains the following elements or 'fields': • ‹indexers› A foldable collection of indexers. Each indexer is a function that takes a message as an argument and returns a collection of keys. • ‹everyting› is a multi-map that maps keys (as returned by the indexers) to sets of messages. It's monotone in the sense that posting messages to the tuple bag only ever increases this multi-map. • ‹newest› is also a multi-map of keys to sets of messages. It maps every key ‹k› to the set of messages assigned to ‹k› the last time ‹post› assigned a message to ‹k›. • ‹history› is a list of two kind of arguments. The first kind of elements are multi-maps, where each multi-map maps keys to sets of messages. The function ‹post› prepends a multi-map to this list everytime it is invoked. This multi-map contains the key-value pairs that were newly added to CHAPTER 7 108 ‹everything›. The second elements are keywords, which serve as markers in the history stream. This keywords are added by the function ‹mark›. Our implementation is as follows. 15 ( extend−type TupleBag 16 ITupleBag 17 ( post [ this co l l ] 18 ( l e t [ aggr−result (−>> ( .indexers this ) 19 (u/ rjuxt ( constantly co l l ) ) 20 ( r/mapcat 21 ( fn [ [ f v ] ] 22 ( r/map ( fn [k ] [k v ] ) 23 ( f v ) ) ) ) 24 ( r/ fold u/mmap−merge 25 u/mmap−conj ) ) ] 26 ( TupleBag. ( . indexers this ) 27 (u/mmap−merge ( .everything this ) 28 aggr−result ) 29 (u/map−merge−overwrite ( .newest this ) 30 aggr−result ) 31 ( cons (u/mmap−diff aggr−result 32 ( .everything this ) ) 33 ( .h istory this ) ) ) ) ) 34 ( query [ this k ] (u/mmap−get ( .everything this ) k ) ) 35 ( newest [ this k ] (u/mmap−get−unique ( .newest this ) k ) ) 36 (mark [ this marker ] 37 ( assert ( keyword? marker ) ) 38 ( TupleBag. ( . indexers this ) 39 ( .everything this ) 40 ( .newest this ) 41 ( cons marker ( .h istory this ) ) ) ) 42 ( since [ this marker ] 43 (−>> ( .h istory this ) CHAPTER 7 109 44 ( r/take−while #(not= % marker ) ) 45 ( r/ f i l t e r col l? ) 46 ( r/ fold u/mmap−merge) ) ) 47 ( process [ this marker rules ] 48 ( l e t [new−bags ( since this marker ) ] 49 [ (mark this marker ) 50 (−>> rules 51 (u/ rjuxt #( get new−bags ( % ) ) ) 52 ( r/mapcat ( fn [ [ f v ] ] ( f this v ) ) ) 53 (u/ foldset ) ) ] ) ) ) The function ‹assert› causes the program to terminate abruptly if passed ‹false› or ‹nil›. In ‹mark› we used it tomake sure ‹marker› is a keyword because passing a collection here would be confusing. The function ‹take−while› from ‹clojure.core.reducers› does what its name suggests. Here we use it to keep only the first items in the tuple-bag history; we ignore everything starting at ‹marker›. Notice that the functions that start with a period, access the members of ‹TupleBag› instances directly. The function ‹TupleBag.› (notice the trailing dot) instantiates such instances. It takes four arguments, corresponding to the desired values for the fields of the tuple bag. Our next task is to define the indexers that we need. But first we define a little utility function. It works like ‹nth›, but returns ‹nil› instead of raising an exception when the requested element could not be found, even when ‹nth› is applied to a non-sequential object. 54 ( defn nth−or−nil [ obj n] 55 ( try 56 ( nth obj n) 57 ( catch Exception x n i l ) ) ) There's one indexer that indexes all messages (assuming they are indeed tuples). It files them under the key ‹[:by−arity x]›, with ‹x› the number of elements in the message. 58 ( defn index−by−arity [ x ] CHAPTER 7 110 59 [ [ :by−arity ( count x ) ] ] ) All other indexers either only index pairs or only index triples. We first discuss the ones that index pairs. 60 ( defn index−pairs−by−first [ x ] 61 ( i f (= 2 ( count x ) ) 62 [ [ :pairs−by−first ( f i r s t x ) ] ] 63 ni l ) ) 64 65 ( defn index−pairs−by−second [ x ] 66 ( i f (= 2 ( count x ) ) 67 [ [ :pairs−by−second ( second x ) ] ] 68 ni l ) ) 69 70 ( defn index−pairs−by−fsecond [ x ] 71 ( i f (= 2 ( count x ) ) 72 [ [ :pairs−by−fsecond ( nth−or−nil ( second x ) 0 ) ] ] 73 ni l ) ) 74 75 ( defn index−pairs−by−first−fsecond−ssecond [ x ] 76 ( i f (= 2 ( count x ) ) 77 ( l e t [ form ( second x ) ] 78 [ [ :pairs−by−first−fsecond−ssecond 79 ( f i r s t x ) 80 ( nth−or−nil form 0) 81 ( nth−or−nil form 1 ) ] ] ) 82 ni l ) ) 83 84 ( defn index−pairs−by−fsecond−fssecond [ x ] 85 ( i f (= 2 ( count x ) ) 86 ( l e t [ outer−form ( second x ) 87 inner−form (nth−or−nil outer−form 1) ] 88 [ [ :pairs−by−fsecond−fssecond CHAPTER 7 111 89 ( nth−or−nil outer−form 0) 90 ( nth−or−nil inner−form 0 ) ] ] ) 91 ni l ) ) The first of the above indexers indexes pairs by their first element. The other indexers index by the second element of the pair. Thus the indexer ‹index−pairs−by−second› indexes pairs by the entirety of their second element. The next function indexes by the result of applying ‹first › to the second element of the pair. The function ‹index−pairs−by−first−fsecond−ssecond› indexes pairs ‹x› by their first element, and by ‹( first (second x))›, or ‹nil› if no such element exists, and ‹(second (second x))› (or ‹nil›). The fifth and final pair indexer, ‹index−pairs−by−fsecond−fssecond›, indexes pairs ‹x› by ‹( first (second x))› (or ‹nil›) and ‹( first (second (second x)))› (or ‹nil›). Finally, we list the indexers for triples. They are straightforward so we don't discuss them any further. 92 ( defn index−triples−by−first−second [ x ] 93 ( i f (= 3 ( count x ) ) 94 [ [ :triples−by−first−second ( f i r s t x ) ( second x ) ] ] 95 ni l ) ) 96 97 ( defn index−triples−by−first−third [ x ] 98 ( i f (= 3 ( count x ) ) 99 [ [ :triples−by−first−third ( f i r s t x ) ( nth x 2 ) ] ] 100 ni l ) ) 101 102 ( defn index−triples−by−second [ x ] 103 ( i f (= 3 ( count x ) ) 104 [ [ :triples−by−second ( second x ) ] ] 105 ni l ) ) 106 107 ( defn index−triples−by−third [ x ] 108 ( i f (= 3 ( count x ) ) 109 [ [ :triples−by−third ( nth x 2 ) ] ] 110 ni l ) ) CHAPTER 7 112 7.5 Tableau system We have everything we need to implement the tableau system for PAL. First we set up a new namespace and then we define the tableau rules. 1 ( ns dyntab.tableau 2 ( : require [ clojure.core.reducers :as r ] 3 [ c lo jure .set :as set ] 4 [ dyntab.bag :as bag ] 5 [ dyntab.uti l :as u] 6 [ dyntab.syntax :as syntax ] ) ) There are two kinds of rules that we need to take into account: deterministic rules and nondeterministic rules. Deterministic rules present us with a collection of tuples that have to be added to the tableau. Nondeterministic rules, on the other hand, give us a collection of collections of tuples. From each of these collections of tuples we are expected to choose one tuple. Of course, in practice we want to try all of our options anyway, but only as branches that we investigate independently. Deterministic rules are easy. We can process them in parallel and simply merge the collection of formulas that they return. We then ‹post› the merged collection. Let us first look at the deterministic rules. Recall that when a rule is called with no arguments it returns the key that should trigger the rule. Whenever a message is associated with said key, the rule is called with the tuple bag (after marking it) and the message for arguments. 7 ( defn rule−not−not 8 ( [ ] [ :pairs−by−fsecond−fssecond :not :not ] ) 9 ( [ tb [n 10 [ not1 [ not2 form ] ] ] ] 11 [ [ n form ] ] ) ) 12 13 ( defn rule−and 14 ( [ ] [ :pairs−by−fsecond :and ] ) CHAPTER 7 113 15 ( [ tb [n 16 [ and1 form1 form2 ] ] ] 17 [ [ n form1] 18 [n form2 ] ] ) ) 19 20 ( defn rule−box1 21 ( [ ] [ :pairs−by−fsecond :box ] ) 22 ( [ tb [n 23 [ box1 idx form ] ] ] 24 (−>> (bag/query tb [ :triples−by−first−second idx n ] ) 25 ( r/map ( fn [m] [ ( nth m 2) form ] ) ) ) ) ) 26 27 ( defn rule−box2 28 ( [ ] [ :by−arity 3 ] ) 29 ( [ tb [ idx src dest ] ] 30 (−>> (bag/query 31 tb 32 [ :pairs−by−first−fsecond−ssecond 33 src :box idx ] ) 34 ( r/map ( fn [m] [ dest ( nth ( second m) 2 ) ] ) ) ) ) ) 35 36 ( defn rule−not−box 37 ( [ ] [ :pairs−by−fsecond−fssecond :not :box ] ) 38 ( [ tb [n 39 [ not1 [box1 idx form ] ] ] ] 40 ( i f (−>> (bag/query tb [ :triples−by−first−second idx n ] ) 41 ( r/ f i l t e r ( fn [ [ idx2 src2 dest2 ] ] 42 ( get ( bag/query tb [ :by−arity 2 ] ) 43 [ dest2 [ :not form ] ] ) ) ) 44 (u/fold−empty? ) ) 45 ( l e t [m (gensym "node" ) ] 46 [ [m] 47 [ idx n m] CHAPTER 7 114 48 [m [ :not form ] ] ] ) 49 [ ] ) ) ) 50 51 ( defn rule−T 52 ( [ ] [ :by−arity 1 ] ) 53 ( [ tb [n ] ] (−>> syntax/Ind 54 ( r/map ( fn [ x ] [ x n n ] ) ) ) ) ) 55 56 ( defn rule−B 57 ( [ ] [ :by−arity 3 ] ) 58 ( [ tb [ idx src dest ] ] [ [ idx dest src ] ] ) ) 59 60 ( defn rule−4 61 ( [ ] [ :by−arity 3 ] ) 62 ( [ tb [ idx src dest ] ] 63 (−>> [ ( r/map ( fn [ [ idx2 src2 dest2 ] ] [ idx src dest2 ] ) 64 ( bag/query 65 tb 66 [ :triples−by−first−second idx dest ] ) ) 67 ( r/map ( fn [ [ idx2 src2 dest2 ] ] [ idx src2 dest ] ) 68 ( bag/query 69 tb 70 [ :triples−by−first−third idx src ] ) ) ] 71 ( r/mapcat identity ) ) ) ) Notice that there are two rules for (non-negated) box formulas. One is triggered by the addition of a box formula and the other rule is triggered by the addition of edges. We use the function ‹gensym› to create previously unused names for new nodes. Predictably, ‹identity› is a function that takes one argument and returns said argument unmodified. As explained above, nondeterministic rules return collections of collections of tuples. To aid readability we let the names of the nondeterministic rules end in an asterisk. CHAPTER 7 115 72 ( defn rule−not−and* 73 ( [ ] [ :pairs−by−fsecond−fssecond :not :and ] ) 74 ( [ tb [n 75 [ not1 [and1 form1 form2 ] ] ] ] 76 [ [ [ n [ :not form1 ] ] 77 [n [ :not form2 ] ] ] ] ) ) 78 79 ( defn rule−precond1* 80 ( [ ] [ :pairs−by−fsecond : ! ] ) 81 ( [ tb [n 82 [ bang1 ann−form post−form ] ] ] 83 (−>> (bag/query tb [ :by−arity 1 ] ) 84 ( r/map ( fn [ [ n ] ] 85 [ [ n ann−form] [n [ :not ann−form ] ] ] ) ) ) ) ) 86 87 ( defn rule−precond2* 88 ( [ ] [ :pairs−by−fsecond−fssecond :not : ! ] ) 89 ( [ tb [n 90 [ not1 [bang1 ann−form post−form ] ] ] ] 91 (−>> (bag/query tb [ :by−arity 1 ] ) 92 ( r/map ( fn [ [ n ] ] 93 [ [ n ann−form] [n [ :not ann−form ] ] ] ) ) ) ) ) 94 95 ( defn rule−precond3* 96 ( [ ] [ :by−arity 1 ] ) 97 ( [ tb [n ] ] 98 (−>> (bag/query tb [ :pairs−by−fsecond : ! ] ) 99 ( r/map ( fn [ [ x [ann1 ann−form post−form ] ] ] 100 [ [ n ann−form] [n [ :not ann−form ] ] ] ) ) ) ) ) 101 102 ( defn rule−precond4* 103 ( [ ] [ :by−arity 1 ] ) 104 ( [ tb [n ] ] CHAPTER 7 116 105 (−>> (bag/query 106 tb 107 [ :pairs−by−fsecond−fssecond :not : ! ] ) 108 ( r/map ( fn [ [ x [ not1 [ann1 ann−form post−form ] ] ] ] 109 [ [ n ann−form] [n [ :not ann−form ] ] ] ) ) ) ) ) There are four precondition rules. The first two rules add ‹ann−form› or ‹[:not ann−form]› to every node when a formula ‹[ :! ann−form post−form]› or ‹[:not [ :! ann−form post−form]]› is added to any node. The other two rules are activated when a node is added. They look up all dynamic formulas ‹[ :! ann−form post−form]› (and negations thereof) from any node and add ‹ann−form› or ‹[:not ann−form]› to the current node. The function ‹post› that we discussed earlier takes as arguments a tuple bag and a collection of messages (tuples). It returns an updated tuple bag. For nondeterministic rules we need slightly different behavior. We start from a collection of collections of tuples. From each of these collections of tuples we take one tuple and we put the chosen tuples in a new collection. This gives us n collections of tuples. We independently post these collections to the tuple bag and thus end up with n tuple bags. Each representing a different branch. 110 ( defn disjunctive−post [ tb coll−of−colls ] 111 ( r/map ( part ia l bag/post tb ) 112 (u/one−from−each coll−of−colls ) ) ) We now define a function for constructing a new tableau. Given a node and a formula, ‹tableau› constructs a new tuple bag with all the indexes required by the rules we discussed earlier and posts the node and formula. If ‹tableau› is given only a formula then the node ‹:start−node› is used. 113 ( defn tableau 114 ( [ form] ( tableau :start−node form ) ) 115 ( [ node form] 116 ( i f ( not ( syntax/wff? form ) ) 117 ( throw ( IllegalArgumentException. 118 ( str "Not a wff : " form ) ) ) ) CHAPTER 7 117 119 (−> (bag/tuple−bag 120 [ bag/index−by−arity 121 bag/index−pairs−by−second 122 bag/index−pairs−by−fsecond 123 bag/index−pairs−by−first−fsecond−ssecond 124 bag/index−pairs−by−fsecond−fssecond 125 bag/index−triples−by−first−second 126 bag/index−triples−by−first−third 127 bag/index−triples−by−second 128 bag/index−triples−by−third ] ) 129 ( bag/post [ [ node ] [node form ] ] ) ) ) ) Given a tableau, the following operation returns the limit of applying all the tableau rules. 130 ( defn saturate [ tableaux ] 131 ( let fn [ ( phase1 [ inner−tabs ] 132 (−>> inner−tabs 133 ( r/map #(bag/process % 134 :tab−sat−mark 135 [ rule−not−not 136 rule−and 137 rule−box1 138 rule−box2 139 rule−T 140 rule−B 141 rule−4 ] ) ) 142 ( r/map ( part ia l apply bag/post ) ) 143 ( r/ foldcat ) ) ) 144 ( phase2 [ inner−tabs ] 145 (−>> inner−tabs 146 ( r/map #(bag/process % 147 :tab−sat−mark2 148 [ rule−not−box ] ) ) CHAPTER 7 118 149 ( r/map ( part ia l apply bag/post ) ) 150 ( r/map #(bag/process % 151 :tab−sat−mark3 152 [ rule−not−and* 153 rule−precond1* 154 rule−precond2* 155 rule−precond3* 156 rule−precond4* ] ) ) 157 ( r/mapcat ( part ia l apply disjunctive−post ) ) 158 ( r/ foldcat ) ) ) ] 159 ( loop [ tableaux tableaux 160 cur−phase phase1 161 changed false ] 162 ( l e t [ new−tableaux ( cur−phase tableaux ) ] 163 ( if−not (−>> new−tableaux 164 ( r/mapcat #(bag/since % :tab−sat−mark ) ) 165 (u/fold−empty? ) ) 166 ( recur new−tableaux phase1 true ) 167 ( i f (= cur−phase phase1 ) 168 ( recur new−tableaux phase2 changed ) 169 [ changed new−tableaux ] ) ) ) ) ) ) It is very noticeable that there are two phases to the saturation process. In the first phase all of the deterministic rules except ‹rule−not−box› are applied. It is only when these rules are saturated that the second phase commences. If changes are made to the tableau in the second phase then the process immediately starts over from the first phase. The reason for this is to ensure that, via ‹rule−T›, ‹rule−B›, and ‹rule−4›, for all a the set of a-links is an equivalence relation before ‹rule−not−box› is given the opportunity to create new nodes. This ensures that the function terminates. Finally, we define a function for checking if a tableau has literal contradictions. 170 ( defn consistent? [ tab ] CHAPTER 7 119 171 ( l e t [not−forms (bag/query 172 tab 173 [ :pairs−by−fsecond :not ] ) ] 174 (−>> (bag/query tab [ :pairs−by−fsecond ni l ] ) 175 ( r/ f i l t e r ( fn [ [ n p ] ] ( get not−forms [n [ :not p ] ] ) ) ) 176 (u/fold−empty? ) ) ) ) We now have a tableau system that can be used to check the satisfiability of non-dynamic formulas. To check the satisfiability of public announcements we need tableau cascades. 7.6 Tableau cascades As before we start by configuring the namespace and defining a function for creating tableau cascades. 1 ( ns dyntab.cascade 2 ( : require [ clojure.core.reducers :as r ] 3 [ c lo jure .set :as set ] 4 [ dyntab.uti l :as u] 5 [ dyntab.bag :as bag ] 6 [ dyntab.syntax :as syntax ] 7 [ dyntab.tableau :as tab ] ) ) 8 9 ( defn tableau−cascade [ form] 10 ( bag/post ( bag/tuple−bag [ bag/index−by−arity 11 bag/index−pairs−by−first 12 bag/index−triples−by−first−second 13 bag/index−triples−by−second 14 bag/index−triples−by−third ] ) 15 [ [ :start−tableau ] 16 [ :start−tableau ( tab/tableau form ) ] ] ) ) Our tableau structures are monotone in the sense that we only ever add tuples to them. We never remove anything. Tableau cascades, as presented in CHAPTER 7 120 previous chapters, are not monotone. Their labels (tableaux) are repeatedly replaced by new labels-although the new labels are always supersets of the labels they replace. Below we take a slightly different approach. We will not remove deprecated labels. Instead we simply provide a function that allows us to easily retrieve the most up-to-date label. 17 ( defn newest−tableau [ casc t ] 18 (−> (bag/newest casc [ :pairs−by−first t ] ) 19 ( second ) ) ) Recall that saturating tableau cascades involves three operations-namely, developing the tableaux therein, priming, and synchronizing. We start by providing a rule for developing a tableau in a tableau cascade until the tableau is saturated. The new tableau is then posted to the tableau cascade (unless it was already saturated from the start). 20 ( defn saturate−tableau 21 ( [ ] [ :by−arity 2 ] ) 22 ( [ casc [ t tab ] ] 23 (−>> [ tab ] 24 ( tab/saturate ) 25 ( ( fn [ [ changed tableaux ] ] 26 ( i f changed 27 ( r/map ( fn [new−tab] [ t new−tab ] ) 28 tableaux ) ) ) ) 29 ( r/ foldcat ) 30 ( vector ) ) ) ) Priming and synchronizing may trigger updates on tableaux within the tableau cascade. Upon encountering a pattern in a first tableau a second tableau may need to be updated and vice versa. To detect patterns in a tableau we apply rules to it. These rules return a collection of multi-maps. These multi-maps are interpreted as follows: • The set associated with the key ‹nil› is a collection of messages to post to the tableau cascade. CHAPTER 7 121 • Any key that is not ‹nil› is assumed to be a tableau cascade node ‹t›. The set associated with this key is a collection of messages to post to ‹(newest−tableau casc t)›. The updated tableau becomes the new label for ‹t›. The following function takes a tableau and a collection of rules as arguments. It applies the rules and merges the vectors of multi-maps that are returned. 31 ( defn meta−process [ tab rules ] 32 [ ( r/ fold 33 u/mmap−merge 34 ( second (bag/process tab :meta−post−mark rules ) ) ) ] ) Given a tableau cascades and a vector of multi-maps the following function posts the messages in the multi-map and returns an updated tableau cascade. 35 ( defn meta−post [ casc tables ] 36 (−>> ( apply u/mmap−merge tables ) 37 ( r/mapcat ( fn [ t co l l ] 38 ( i f t 39 [ [ t (−> ( newest−tableau casc t ) 40 ( bag/mark :meta−post−mark) 41 ( bag/post co l l ) ) ] ] 42 co l l ) ) ) 43 ( r/ foldcat ) 44 ( bag/post casc ) ) ) Notice that when a tableau is updated it is marked with the keyword ‹:meta−post−mark›. This marker is also used in the function ‹meta−process› above. We use the above conventions in our priming operation. The rule ‹prime› is triggered when a tableau is changed in a tableau cascade. When triggered by ‹[t tab]› it invokes ‹meta−process› on the tableau. The first two rules given to ‹meta−process› ensure that if a tableau node contains the formulas ‹[ :! form1 form2]› and ‹form1› then a new tableau is created. Specifically, the CHAPTER 7 122 first rule is triggered by the presence of formulas ‹[ :! form1 form2]› and then checks if ‹form1› is present in the tableau node; the second rule is triggered by the addition of any formula ‹form1› and checks if ‹[ :! form1 form2]› is also present. The third rule is triggered by negated public announcements. It adds the precondition to the current tableau node and adds a new tableau to the tableau cascade. 45 ( defn prime 46 ( [ ] [ :by−arity 2 ] ) 47 ( [ casc [ t tab ] ] 48 (meta−process 49 tab 50 [ ( fn 51 ( [ ] [ :pairs−by−fsecond : ! ] ) 52 ( [ cur−tab [n [op form1 form2] :as node−label ] ] 53 ( l e t [new−t (gensym " tableau" ) ] 54 ( i f (−> (bag/query cur−tab [ :by−arity 2 ] ) 55 ( contains? [n form1 ] ) ) 56 [ { n i l # { [new−t] 57 [new−t ( tab/tableau n form2 ) ] 58 [ form1 t new−t ] } 59 t #{node−label } } ] 60 [ ] ) ) ) ) 61 ( fn 62 ( [ ] [ :by−arity 2 ] ) 63 ( [ cur−tab [n form :as node−label ] ] 64 [ { n i l (−>> (bag/query 65 cur−tab 66 [ :pairs−by−first−fsecond−fssecond 67 n : ! form ] ) 68 ( r/mapcat 69 ( fn [ [ n2 [op form2 form3 ] ] ] 70 ( l e t [new−t (gensym " tableau" ) ] 71 [ [ new−t] CHAPTER 7 123 72 [new−t ( tab/tableau n form3 ) ] 73 [ form t new−t ] ] ) ) ) 74 (u/ foldset ) ) 75 t #{node−label } } ] ) ) 76 ( fn 77 ( [ ] [ :pairs−by−fsecond−fssecond :not : ! ] ) 78 ( [ cur−tab [n [op1 [op2 form1 form2 ] ] :as node−label ] ] 79 ( l e t [new−t (gensym " tableau" ) ] 80 [ { n i l # { [new−t] 81 [new−t ( tab/tableau n [ :not form2 ] ) ] 82 [ form1 t new−t ] } 83 t #{node−label } } 84 { t # { [n form1 ] } } ] ) ) ) ] ) ) ) We now turn our attention to synchronization. We start by defining a function that, given a tableau cascade ‹casc› and a tableau cascade node ‹t›, returns a multi-map from tableau nodes ‹n› to the tableau cascade nodes ‹t2› such that (i) ‹(newest−tableau casc t2)› contains ‹n› and (ii) there is an edge in ‹casc› between ‹t› and ‹t2›. 85 ( defn synchronization−range [ casc t ] 86 (−>> (bag/query casc [ :triples−by−second t ] ) 87 ( r/map #(nth % 2 ) ) 88 ( r/ foldcat ) 89 ( r/cat (−>> (bag/query casc [ :triples−by−third t ] ) 90 ( r/map second ) 91 ( r/ foldcat ) ) ) 92 ( r/mapcat ( fn [ t2 ] 93 (−>> ( newest−tableau casc t2 ) 94 ( # ( bag/query % [ :by−arity 1 ] ) ) 95 ( r/map ( fn [ [ n ] ] {n #{ t2 } } ) ) ) ) ) 96 ( r/ fold u/mmap−merge) ) ) Definition 4.12 frames the synchronizing operation in set-theoretic terms. It does not give us an algorithm for synchronizing tableaux, but fortunately CHAPTER 7 124 it's not difficult to create such an algorithm. For any two tableau cascade nodes t1 and t2 of a tableau cascade C , all we have to do is decide which tuples of C(t1?) should be added to the label of t2 (and vice versa). When a new tableau ‹t2› is added we start by copying over all nodes from the tableau ‹t1› that spawned it. The rule for this is triggered by the addition of a tableau cascade edge, which is only ever added when a new tableau is created. 97 ( defn synchronize−init 98 ( [ ] [ :by−arity 3 ] ) 99 ( [ casc [ precond t1 t2 ] ] 100 [ ( r/ fold u/mmap−merge 101 [ (−>> (bag/query ( newest−tableau casc t1 ) 102 [ :pairs−by−second precond ] ) 103 ( r/map ( fn [ [ n form ] ] { t2 #{ [n ] } } ) ) 104 ( r/ fold u/mmap−merge ) ) ] ) ] ) ) Other triggers for copying tableau nodes are the result of changes within ‹t1› or ‹t2›. Every node that is added to ‹t2› is added to ‹t1›. If the formula ‹form› is added to a node in ‹t1› then this node is copied to ‹t2›. The rule ‹synchronize› takes care of these conditions. It also deals with atoms and edges. 105 ( defn synchronize 106 ( [ ] [ :by−arity 2 ] ) 107 ( [ casc [ t tab ] ] 108 ( l e t [ sync−range ( synchronization−range casc t ) ] 109 (meta−process 110 tab 111 [ ( fn ; copy node to left−hand tableaux 112 ( [ ] [ :by−arity 1 ] ) 113 ( [ cur−tab [n ] ] 114 (−>> (bag/query casc [ :triples−by−third t ] ) 115 ( r/map ( fn [ [ precond t1 t2 ] ] 116 { t1 #{ [n ] CHAPTER 7 125 117 [n precond ] } } ) ) ) ) ) 118 ( fn ; copy node to right−hand tableaux 119 ( [ ] [ :by−arity 2 ] ) 120 ( [ cur−tab [n form ] ] 121 (−>> (bag/query casc 122 [ :triples−by−first−second 123 form t ] ) 124 ( r/map ( fn [ [ precond t1 t2 ] ] 125 { t2 #{ [n ] } } ) ) ) ) ) 126 ( fn ; copy atoms to th i s tableau 127 ( [ ] [ :by−arity 1 ] ) 128 ( [ cur−tab [n ] ] 129 (−>> ( get sync−range n) 130 ( r/map #(bag/newest casc 131 [ :pairs−by−first % ] ) ) 132 ( r/mapcat 133 #(bag/query 134 ( second %) 135 [ :pairs−by−fsecond ni l ] ) ) 136 ( r/ f i l t e r #(= ( f i r s t %) n ) ) 137 ( r/map ( fn [ x ] { t #{x } } ) ) ) ) ) 138 ( fn ; copy atoms to neighboring tableaux 139 ( [ ] [ :pairs−by−fsecond ni l ] ) 140 ( [ cur−tab [n atom ] ] 141 ( r/map ( fn [ t2 ] { t2 #{ [n atom ] } } ) 142 ( get sync−range n ) ) ) ) 143 ( fn ; copy incoming edges to th i s tableau 144 ( [ ] [ :by−arity 1 ] ) 145 ( [ cur−tab [n ] ] 146 (−>> ( get sync−range n) 147 ( r/map #(bag/newest casc 148 [ :pairs−by−first % ] ) ) 149 ( r/mapcat #(bag/query ( second %) CHAPTER 7 126 150 [ :triples−by−third n ] ) ) 151 ( r/ f i l t e r 152 #( contains? ( bag/query cur−tab 153 [ :by−arity 1 ] ) 154 [ ( second % ) ] ) ) 155 ( r/map ( fn [ x ] { t #{x } } ) ) ) ) ) 156 ( fn ; copy outgoing edges to th i s tableau 157 ( [ ] [ :by−arity 1 ] ) 158 ( [ cur−tab [n ] ] 159 (−>> ( get sync−range n) 160 ( r/map #(bag/newest casc 161 [ :pairs−by−first % ] ) ) 162 ( r/mapcat 163 #(bag/query ( second %) 164 [ :triples−by−second n ] ) ) 165 ( r/ f i l t e r 166 #( contains? ( bag/query cur−tab 167 [ :by−arity 1 ] ) 168 [ ( nth % 2 ) ] ) ) 169 ( r/map ( fn [ x ] { t #{x } } ) ) ) ) ) 170 ( fn ; copy edges to neighboring tableaux 171 ( [ ] [ :by−arity 3 ] ) 172 ( [ cur−tab [ idx n m] ] 173 ( r/map ( fn [ t2 ] { t2 #{ [ idx n m] } } ) 174 ( set/ intersection 175 ( get sync−range n) 176 ( get sync−range m) ) ) ) ) ] ) ) ) ) Whenever a node is added to ‹t1› or ‹t2› the atoms of the other tableau must be copied over. Similarly, when an atom is added to ‹t1› or ‹t2› then this same atom must be added to the other tableau. Copying edges follows similar reasoning. We can now define the algorithm for saturating tableau cascades. The following function develops, primes, and synchronizes a given collection of CHAPTER 7 127 tableau cascades. It returns the limit of all branches resulting from these operations. 177 ( defn saturate [ cascades ] 178 ( l e t [ next−casc 179 (−>> cascades 180 ( r/map #(bag/process 181 % 182 :casc−sat−mark 183 [ saturate−tableau ] ) ) 184 ( r/mapcat ( part ia l apply tab/disjunctive−post ) ) 185 ( r/map #(bag/process 186 % 187 :casc−sat−mark2 188 [ prime 189 synchronize 190 synchronize−init ] ) ) 191 ( r/map ( part ia l apply meta−post ) ) 192 ( r/ fold 8 ( r/monoid r/cat vector ) conj ) ) ] 193 ( if−not (−>> next−casc 194 ( r/mapcat #(bag/since % :casc−sat−mark ) ) 195 (u/fold−empty? ) ) 196 ( recur next−casc ) 197 next−casc ) ) ) The fragment ‹(r/fold 8 (r/monoid r/cat vector) conj)› behaves similarly to ‹r/foldcat›. However, ‹r/foldcat› only returns a foldable collection if the initial collection is foldable and large enough to make it worthwhile to process in parallel. Our replacement code always returns a foldable collection. Moreover, it does parallel processing in batches of 8 tableau cascades. This is more sensible for our purposes than using batches of 512 items-as is the default for ‹r/fold›. With the system that we developed in this chapter we can check whether a formula of L◻! is satisfiable. We start by constructing an initial tableau CHAPTER 7 128 cascade and applying ‹saturate›. The formula is satisfiable if and only if this yields us a tableau cascade in which all tableaux are consistent. 198 ( defn consistent? [ casc ] 199 (−>> (bag/query casc [ :by−arity 1 ] ) 200 ( r/map #(bag/newest casc [ :pairs−by−first ( f i r s t % ) ] ) ) 201 ( r/ f i l t e r #(not ( tab/consistent? ( second % ) ) ) ) 202 (u/fold−empty? ) ) ) 203 204 ( defn sat i s f iab le? [ form] 205 (−>> ( saturate [ ( tableau−cascade form ) ] ) 206 ( r/ f i l t e r consistent? ) 207 (u/fold−empty? ) 208 ( not ) ) ) 209 210 ( defn valid? [ form] 211 ( not ( sa t i s f iab le? [ :not form ] ) ) ) The source code that was presented in this chapter is also available online at https://github.com/jdevuyst/tableaux. 7.7 Remarks We set out to create a proof of concept theorem prover for public announcement logic. On this we believe to have delivered. We do have some comments with respect to possible expansions on our codebase. First, we want to make a few retrospective comments on the overall design of our theorem prover. Afterwards we would like to make some comments on its performance in practice. We are satisfied with the overall structure of our code. Nevertheless, the ‹TupleBag› data structure could use some rethinking. The system of installing ad hoc indexers provides good performance and is easy to implement. However, it comes at a cost. That cost is the complexity of the rules. A better tuple CHAPTER 7 129 bag would allow us to rewrite ‹rule−box1› and ‹rule−box2› into one rule. Informally this rule would be as follows: Given two tuples ‹[n [:box idx form]]› and ‹[idx n m]›, add ‹[m form]›. The RETE algorithm provides functionality as described above [18]. We know of two RETE implementations for Clojure, Mímir [32] and Clara [8]. RETE relies on heuristics to provide good performance. Because our application was expected to be performance sensitive from the start we decided not to use RETE at this point. Whether or not these performance concerns are justified is something we leave to future research. Indeed, our present tuple bag implementation provides a useful performance baseline for possible future efforts to refactor ‹TupleBag›. If RETE, or any other forward chaining system, were to be added in a future update then ideally it should be implemented in a such a way that it can also match inter-tableau patterns. For instance, it should be possible to have a tableau cascade rule such that, given a tableau cascade edge ‹[form t1 t2]› in ‹casc›, an edge ‹[idx n m]› in ‹(newest−tableau casc t1)›, and two singles ‹[n]› and ‹[m]› in ‹(newest−tableau casc t2)› the edge ‹[idx n m]› is added to the tableau for ‹t2›. Currently ‹synchronize› contains three rules for this! Given a forward chaining system it would also be worth considering to implement a domain specific language for specifying rules. This would make it easier to extend our software. Knowledge of Clojure would no longer be required, thereby significantly reducing the barrier to entry. Finally, we want to make some remarks about performance. We used the Oracle Java 7 virtual machine. The first thing we noticed was that for complex formulas we had to manually increase the memory available to the JVM. We used the command line option ‹−Xmxn› to increase the available memory to 6 GB (out of 8 GB total memory). Still, we found that for sufficiently complex formulas our theorem prover ran out of memory after a few minutes. Specifically, the garbage collector would start 'trashing'. This means that most of the time spent executing the program was spent on garbage collection. Each garbage collection cycle would take tens of seconds and a new 'full' cycle was started right after the previous one ended. We did attempt to use the CHAPTER 7 130 incremental garbage collection (available using the option ‹−Xincgc›) but this did not help. Because the 'full' garbage collection cycles were started one after another we conjecture that the problem is that not enough memory was available. The JVM has a generational garbage collector, meaning that it tries to recycle recently allocatedmemory before searching for unreferenced parts in old data. Hence, had the problem been that the garbage collector could not handle the intermediate data generated then we would not expect to see so many full cycles being performed. The above results suggest that tuple bags should be refactored to use less memory or to offload parts of their content to disk. On the other hand, it might be the case that a linear decrease of memory used by ‹TupleBag› would be immediately defeated due to the theoretic space complexity of our algorithm. Analysis of the space complexity of our program is left for further reasearch. Furthermore, refactoring ‹TupleBag› to use less memory might involve performance tradeoffs that create new bottlenecks. We ran our theorem prover on a laptop with an 1.7 GHz Intel i7 Haswell processor. This processor has four cores. We found that we could easily attain CPU utilization of 370% and more by processing tableau cascades in batches of around 8 items at a time. However, we also found that this decreased the execution time by slightly less than 50%. More research is needed to determine the cause of this somewhat disappointing speed up. 7.8 Related work LoTREC is the only software program that we know of that contains a tableaubased theorem prover for public announcement logic. LoTREC is an extensible system that comes with a domain specific language and a graphical user interface. Evidently our Clojure program does not have the same level of maturity. Nevertheless, the theoretic foundations of our program are simple enough that, at this point, the lack of a domain specific language for tableau rules (and tableau cascade rules) does not strike us as a major shortcoming. Additionally, the graphical user interface of LoTREC is rather complicated. CHAPTER 7 131 8 Conclusion We set out to create proof systems for dynamic modal logics that are conceptually simple, easy to use, modular, and extensible. Let's review these items one by one and evaluate if we succeeded. • Conceptual simplicity. From the get go we modeled our tableau systems closely after the semantics they target. We believe this has resulted in transparent proof systems. • Ease of use. Because the rules of the tableau systems are based on the semantics of the different dynamic languages, they are easy to understand and apply. Determining whether two tableau stand in relations !φ −→, ⊗φ −−→, ¡φ −→, ♯φ −−→, or ⇑φ −−→ is no more difficult than computing the outcome of an operation |!φ, |⊗φ, |¡φ, |♯φ, or |⇑φ. The workings of tableau cascades and the operations of priming and synchronizing are fairly straightforward. We reckon that the operation of ⊗-correcting is somewhat inelegant, but that the benefit of having the tableau rules be independent of tableau cascades is worth the cost. Finally, folding is not the easiest concept to understand but (i) it is only required for certain combinations of frame conditions and (ii) we feel it is preferable to have a folding operation than to include frame condition properties in the rule R◻ (as is common in the literature). • Modularity. For every truth schema in the different languages we have at most two tableau rules. Every dynamic operator also has two corresponding clauses that constrain what it means for a tableau to be 'open'. Finally, these clauses depend on a relation between tableaux that is closely related to the dynamic operation on models. Consequently, our tableau systems are highly modular. The way the relations !φ −→, ⊗φ −−→, ¡φ −→, ♯φ −−→, and ⇑φ −−→ are related to the operations |!φ, |⊗φ, |¡φ, |♯φ, and |⇑φ is also modular in the sense that lemmas 4.1, 5.1, and 6.1 were established before the soundness and completeness proofs. Similarly, we would tout it as a benefit with respect to modularity that the operations of folding, priming, and synchronizing are not needed for the soundness and completeness proofs. Indeed, we only introduced tableau cascades after proving soundness and completeness. Our tableau cascades themselves are also modular. Most dynamic operators require only that a priming operation is defined and that the definition of satisfaction of tableau cascades is amended. • Extensibility. Throughout this dissertation we have to a large extent been able to add constructs to our languages without having to revisit earlier results. To wit, we did not have to create a proof system from scratch for every logic and it would be straightforward to create a proof system for the language that would result from combining all dynamic operators in one language. To summarize, we hold that we have succeeded in creating an alternative proof theory for several popular dynamic modal logics that has pedagogic and esthetic advantages. In section 6.1 we encountered one belief revision operator that we did not (yet) manage to translate to our style of tableau systems. This is a notable limitation. It's presently not known what changes would need to be made to our general approach to make it compatible with 'conservative upgrades'. CHAPTER 8 133 For future research we would be interested in applying the techniques discussed in this volume to more expressive logics. For instance, presently no tableau systems appear to exist for dynamic epistemic logics with common knowledge [22]. Beyond this, the minimal revision logic in [13] has dynamic operators that might fit in well with our approach to tableau systems. Our Clojure implementation demonstrates that our tableau system for public announcement logic can readily be turned into an automatic theorem prover. A synchronization algorithm has to be devised but this is an easy enough task. No complicated new algorithms are required. For future research we think the primary focus should be on adding a forward chaining engine and defining a domain specific language for defining tableau rules and tableau cascade rules. Afterwards, adding support for L◻⊗ and LU◻¡♯⇑ should require only a fairly straightforward translation of the results from chapters 5 and 6. CHAPTER 8 134 ◆ Bibliography [1] C.E. Alchourrón, P. Gärdenfors, and D. Makinson. On the logic of theory change: Partial meet contraction and revision functions. Journal of Symbolic Logic, 50:510–530, 1985. [2] P. Balbiani, H.P. van Ditmarsch, A. Herzig, and T. de Lima. Tableaux for public announcement logic. Journal of Logic and Computation, 20:55–76, 2010. [3] A. Baltag and L.S. Moss. Logics for epistemic programs. Synthese, 139:165–224, 2004. [4] A. Baltag, L.S. Moss, and S. Solecki. The logic of public announcements, common knowledge, and private suspicions. Technical Report SENR9922, University of Amsterdam, 1999. [5] A. Baltag and S. Smets. Conditional doxastic models: A qualitative approach to dynamic belief revision. In G. Mints and R. de Queiroz, editors, Proceedings of WOLLIC 2006, volume 165 of Electronic Notes in Theoretical Computer Science, pages 5–21, 2006. [6] A. Baltag and S. Smets. A qualitative theory of dynamic interactive belief revision. In Logic and the Foundations of Game and Decision Theory (LOFT 7), Texts in Logic and Games 3, pages 13–60. AmsterdamUniversity Press, 2008. [7] P. Blackburn, M. de Rijke, and Y. Venema. Modal Logic. Cambridge Tracts in Theoretical Computer Science. Cambridge University Press, 2002. 135 [8] R. Brush. Clara: Forward-chaining rules in clojure. https://github.com/ rbrush/clara-rules, 2013. [9] M. Castilho, L. Fariñas del Cerro, O. Gasquet, and A. Herzig. Modal tableaux with propagation rules and structural rules. Fundamenta Informaticae, 32(3/4):281–297, 1997. [10] M. D'Agostino, Dov M. Gabbay, H. Reiner, and J. Posegga, editors. Handbook of Tableau Methods. Springer, 1999. [11] R. Davies and F. Pfenning. A modal analysis of staged computation. Journal of the ACM, pages 258–270, 1996. [12] M.S. de Boer. KE tableaux for public announcement logic, 2007. [13] J. De Vuyst. Minimal revision and classical Kripke models: First results. In H.P. van Ditmarsch, J. Lang, and S. Ju, editors, LORI 2011, volume 6953 of Lecture Notes in Artificial Intelligence, pages 300–313. Springer, 2011. [14] L. Fariñas del Cerro, D. Fauthoux, O. Gasquet, A. Herzig, D. Longin, and F. Massacci. Lotrec: The generic tableau prover for modal and description logics. In Proceedings of the First International Joint Conference on Automated Reasoning, LNCS, pages 453–458. Springer, 2001. [15] L. Fariñas del Cerro and O. Gasquet. A general framework for patterndriven modal tableaux. Logic Journal of the IGPL, 10(1):51–83, 2002. [16] M. Fitting. Proof methods for modal and intuitionistic logics, volume 169. Springer, 1983. [17] M. Fogus and C. Houser. The Joy of Clojure. Manning Publications, 2nd edition, forthcoming. [18] C. Forgy. Rete: A fast algorithm for the many pattern/many object pattern match problem. Artificial Intelligence, 19:17–37, 1982. BIBLIOGRAPHY 136 [19] O. Gasquet, A. Herzig, D. Longin, and M. Sahade. Lotrec: Logical tableaux research engineering companion. In B. Beckert, editor, Automated Reasoning with Analytic Tableaux and Related Methods, volume 3702 of Lecture Notes in Computer Science, pages 318–322. Springer, 2005. [20] J.D. Gerbrandy and W. Groeneveld. Reasoning about informatino change. Journal of Logic, Language, and Information, 6:147–169, 1997. [21] R. Goldblatt. Mathematical modal logic: A view of its evolution. Journal of Applied Logic, 1(5-6):309–392, 2003. [22] J.U. Hansen. Terminating tableaux for dynamic epistemic logics. Electronic Notes in Theoretical Computer Science, 262:141–156, 2010. [23] A. Herzig, S. Konieczny, and L. Perrussel. On iterated revision in the AGM framework. In Symbolic and Quantitative Approaches to Reasoning with Uncertainty, pages 477–488. Springer, 2003. [24] J. Hintikka. Knowledge and belief an introduction to the logic of the two notions. Contemporary philosophy series. Cornell University Press, 4th edition, 1969. [25] G.E. Hughes and M.J. Cresswell. A New Introduction to Modal Logic. Routledge, 1996. [26] S.A. Kripke. A completeness theorem in modal logic. Journal of Symbolic Logic, 24:1–14, 1959. [27] S.A. Kripke. Semantical analysis of modal logic I: Normal modal propositional calculi. Mathematical Logic Quarterly, 9:67–96, 1963. [28] F. Liu. Reasoning about Preference Dynamics. Springer Library, 2011. [29] M. McGrath. Propositions. In E.N. Zalta, editor, The Stanford Encyclopedia of Philosophy. Summer 2012 edition, 2012. [30] J.A. Plaza. Logics of public communications. In Proceedings of the 4th International Symposium on Methodologies for Intelligent Systems, pages 201–216, 1989. BIBLIOGRAPHY 137 [31] G. Primiero. A multi-modal type system and its procedural semantics for safe distributed programming. In Intuitionistic Modal Logic and Applications Workshop (IMLA11), Nancy, 2011. [32] H. Råberg. Mímir: An experimental rule engine written in clojure. https: //github.com/hraberg/mimir, 2012-2013. [33] J. Van Benthem. Dynamic logic for belief revision. Journal of Applied Non-Classical Logics, 17(2), 2007. [34] J. van Benthem. Logical Dynamics of Information and Interaction. Cambridge University Press, 2011. [35] J. Van Benthem and F. Liu. Dynamic logic of preference upgrade. Journal of Applied Non-Classical Logics, 14(2), 2004. [36] H.P. van Ditmarsch. Knowledge games. PhD thesis, University of Groningen, 2000. [37] H.P. van Ditmarsch, W. van der Hoek, and B. Kooi. Dynamic epistemic logic, volume 337 of Synthese Library. Springer, 2007. [38] Y. Wang and Q. Cao. On axiomatizations of public announcement logic. Synthese, pages 1–32, 2013. [39] T. Williamson. Knowledge and Its Limits. Oxford University Press, 2002. BIBLIOGRAPHY 138 ◆ Index of Definitions R-saturated, 28 ⊩, 47, 65, 78 | |, 15 !φ ⟶, 48 ⇑φ ⟶, 83 ⊗φ ⟶, 67 ♯φ ⟶, 83 ¡φ ⟶, 83 σ-contingent, 24 σ-contradictions, 24 σ-development, 27 σ-invalid, 24 σ-satisfiable, 24 σ-saturated, 28 σ-theorems, 24 σ-unsatisfiable, 24 σ-valid, 24 φ-declarative, 49 ⊗-correcting, 73 ⊗-priming, 72 ×, 8 a-chain, 10 a-edge, 10 a-path, 10 n-tuple, 8 .everything, 108 .history, 108 .indexers, 108 .newest, 108 ⌊σ⌋-development, 36 ⌊σ⌋-saturated, 37 Se0 ...el, 8 S(∗0 ...∗l−1), 9 S[∗0 ...∗l−1], 9 S[e0 ...?...el−1], 9 ⊩, 19 ⌊R⌋, 36 Ind, 18 Prop, 18 L-tableau, 25 Lit, 18 root(G), 10 abstract syntax tree, 93 accessibility relation, 19 accessible, 10 action model, 64 139 actions, 64 affected, 11 AGM, 76 applying, 57 AST, 93 Backus-Naur Form, 14 belief revision, 76 bisimilar, 14 bisimulation, 14 BNF, 14 chain, 10 closed, 29 collection, 99 completeness, 3, 17 conclusion, 1, 2 consistent?, 119, 129 constraints, 35 copy, 36 correct, 17 current node, 11 deduction, 1 deduction theorem, 3 disjunctive-post, 117 dyntab.bag, 106 dyntab.cascade, 120 dyntab.syntax, 105 dyntab.tableau, 113 dyntab.util, 102 edge, 10 embedding, 12 entailment, 2 events, 64 fold-empty?, 104 folding, 37 foldset, 104 for, 28 forcing relation, 19 frame, 11 frame condition, 21 fully synchronized, 59 grammar, 16 incoming a-edge, 10 Ind, 105 index-by-arity, 110 index-pairs-by-first, 111 index-pairs-by-first-..., 111 index-pairs-by-fsecond, 111 index-pairs-by-fsecond-..., 111 index-pairs-by-second, 111 index-triples-by-first-second, 112 index-triples-by-first-third, 112 index-triples-by-second, 112 index-triples-by-third, 112 ITupleBag, 106 Kripke model, 12, 18 Kripke semantics, 6 label, 10 label-set, 10 lgraph, 9 link, 10 literal contradiction, 29 INDEX OF DEFINITIONS 140 literal propositions, 18 literals, 18 map-merge-overwrite, 103 mark, 106, 109 meta-post, 122 meta-process, 122 mmap-conj, 103 mmap-diff, 103 mmap-get, 103 mmap-get-unique, 103 mmap-merge, 103 model, 2, 17 monoid, 101 natively satisfies, 29 newest, 106, 109 newest-tableau, 121 node, 10 non-destructive, 25 nth-or-nil, 110 one-from-each, 105 open, 29, 49, 67, 83 outgoing a-edge, 10 pair, 8 path, 10 pointed graph, 11 points, 19 possible world semantics, 6 post, 106 precondition, 64 preference change, 77 premise, 1, 2 prime, 123 process, 106, 109 proof system, 2 Prop, 105 query, 106, 109 reasoning, 1, 16 reductive, 27 rjuxt, 104 rule-4, 113 rule-and, 113 rule-B, 113 rule-box1, 113 rule-box2, 113 rule-not-and*, 115 rule-not-box, 113 rule-not-not, 113 rule-precond*, 115 rule-precond2*, 115 rule-precond3*, 115 rule-precond4*, 115 rule-T, 113 satisfiable?, 129 satisfied, 56, 72, 87 satisfies, 29 saturate, 118, 128 saturate-tableau, 121 saturated, 28 semantics, 1, 16 sequence, 96 since, 106, 109 single, 8 INDEX OF DEFINITIONS 141 soundness, 3, 17 states, 19 stock model, 32 stock tableau, 52 string, 94 synchronization-range, 124 synchronize, 125 synchronize-init, 125 synchronizing, 58 syntax, 1, 16 tableau, 117 tableau cascade, 56 tableau rule, 25 tableau system, 2, 4 tableau-cascade, 120 tautology, 3 threading macro, 98 triple, 8 tuple, 8 tuple-bag, 108 TupleBag, 108, 109 valid?, 129 valuation, 19 vertex, 10 virtual a-loop, 35 weak completeness, 3 well-behaved frame condition, 21 well-formed formula (wff), 18 wff?, 105 world, 19 INDEX OF DEFINITIONS