Formalizing Dijkstra

We present a HOL formalization of the foundational parts of Dijkstra’s classic monograph “A Discipline of Programming”. While embedding programming language semantics in theorem provers is hardly new, this particular undertaking raises several interesting questions, and perhaps makes an interesting supplement to the monograph. Moreover, the failure of HOL’s first order proof tactic to prove one ‘theorem’ indicates a technical error in the book. 0 A Discipline of Programming Dijkstra’s “A Discipline of Programming” [4] is widely, and we think rightly, regarded as a classic. As he describes it, the original intention was to present some algorithms, emphasizing the process of discovery leading to them rather than giving them as cut-and-dried results. However, Dijkstra also wished to present the programs using more mathematical rigour than is the norm. The book emphasizes a view of a program as an abstract mathematical object, whose runnability on a machine is, so to speak, a fortunate accident: Historically speaking . . . the fact that programming languages could be used as a vehicle for instructing existing automatic computers . . . has for a long time been regarded as their most important property. . . . I view a programming language primarily as a vehicle for the description of (potentially highly sophisticated) abstract mechanisms. [pp. 8–9] Dijkstra’s main technical innovation, covered in depth for the first time in this book, is the use of predicate transformers to give the semantics of programs. Predicate transformer semantics is quite convenient for formal correctness proofs, since it has a direct relationship with the satisfaction of appropriate input-output conditions. Moreover, it turned out [1] that one could introduce predicate transformers not implementable as code, and use these as stepping stones in formal program derivations, giving a natural formalization of informal top-down design methods. Dijkstra was one of the earliest and strongest advocates of formal correctness proofs of programs rather than extensive testing. Nowadays this point of view is increasingly having a practical impact, with major hardware companies pursuing formal verification. But for a long time Dijkstra must have felt like a prophet crying in the wilderness. As I have now said many times and written in many places: program testing can be quite effective for showing the presence of bugs, but is hopelessly inadequate for showing their absence. [p. 20] These points of view must lie behind flourishes such as: None of the programs in this monograph, needless to say, has been tested on a machine. [p. xvi] In the light of this comment, it seemed interesting to check his proofs by machine! While Dijkstra [7] attacked the anti-verification polemic of DeMillo, Lipton, and Perlis [2] as a ‘political pamphlet from the Middle Ages’, he accepted that long tedious proofs are inadequate, and that ‘communication between mathematicians is an essential part of our culture’. Moreover Dijkstra [5] elsewhere seems to oppose the idea of checking proofs by computer: To the idea that proofs are so boring that we cannot rely upon them unless they are checked mechanically I have philosophical objections, for I consider mathematical proofs as a reflection of my understanding and ‘understanding’ is something we cannot delegate, either to another person or to a machine. Formalizing programming languages inside theorem provers has become a major research topic. Our work largely follows the classic paper by Gordon [9], and doesn’t pretend to offer any major technical advances, but we think that in combination with an analysis of Dijkstra’s book it raises a few interesting issues. 1 Formalization of States A fundamental concept throughout the book, and imperative programming generally, is the notion of a state. Dijkstra devotes all of Chap. 2 to a gentle and rather non-operational introduction to the concept. To fall short of his ideal somewhat, we may briefly describe the state as a mapping that given a particular point during execution returns the values of all the program variables at that point. For the moment, we will not concern ourselves with how states are represented and how variables as rvalues or lvalues consult or modify the state, nor how variables are declared or scoped – this is discussed much later, as in Dijkstra’s monograph where it is delayed until Chap. 10. For all the basic semantics and program command definitions, we can think of the state as simply some arbitrary type, and we normally use the HOL type variable :S. In what follows, predicates over states, or equivalently sets of states, are used incessantly. One often wants to say that for example ‘P and Q both hold in state 1 Dijkstra [p14] talks about predicates ‘corresponding’ to sets; in the HOL formalization they actually are sets. s’. This isn’t the same as P ∧Q, but rather P (s) ∧Q(s). It’s often attractive – and in any case Dijkstra does it this way – to ‘hide’ the state in such assertions. The easiest way, already used in many programming language embeddings, is to define analogs of all the logical operations but lifted up to the level of predicates: