Using Z
Specification, Refinement, and Proof
Jim Woodcock
University of Oxford
Jim Davies
University of Oxford
Copyright: this hypertext version of Using Z is easily copied, distributed, and printed; if you choose to do this, we would ask you to remember that it is under copyright: if you reproduce any of the material, please include an appropriate acknowledgement, and—if you find the material useful—please encourage us (and our publishers) by buying a copy of the book.
Contents
Foreword xi Using this Book xiii Acknowledgments xv
1 Introduction 1
1.1 Formal methods 1
1.2 The CICS experience 2
1.3 The Z notation 3
1.4 The importance of proof 4
1.5 Abstraction 5
2 Propositional Logic 9
2.1 Propositional logic 9
2.2 Conjunction 10
2.3 Disjunction 13
2.4 Implication 14
2.5 Equivalence 17
2.6 Negation 20
2.7 Tautologies and contradictions 23
3 Predicate Logic 27
3.1 Predicate calculus 28
3.2 Quantifiers and declarations 30
3.3 Substitution 34
vi
4 Equality and Definite Description 45
4.1 Equality 45
4.2 The one-point rule 48
4.3 Uniqueness and quantity 50
4.4 Definite description 52
3.4 Universal introduction and elimination 36
3.5 Existential introduction and elimination 40
3.6 Satisfaction and validity 43
5 Sets
57
5.1 Membership and extension 57
5.2 Set comprehension 61
5.3 Power sets 65
5.4 Cartesian products 66
5.5 Union, intersection, and difference 68
5.6 Types 69
6 Definitions 73
6.1 Declarations 73
6.2 Abbreviations 74
6.3 Generic abbreviations 75
6.4 Axiomatic definitions 77
6.5 Generic definitions 79
6.6 Sets and predicates 81
7 Relations 83
7.1 Binary relations 83
7.2 Domain and range 85
7.3 Relational inverse 88
7.4 Relational composition 91
7.5 Closures 94
8 Functions 99
8.1 Partial functions 99
8.2 Lambda notation 101
8.3 Functions on relations 103
8.4 Overriding 105
8.5 Properties of functions 107
8.6 Finite sets 111
vii
9 Sequences 115
9.1 Sequence notation 115
9.2 A model for sequences 119
9.3 Functions on sequences 122
9.4 Structural induction 124
9.5 Bags 128
10 Free Types 133
10.1 The natural numbers 133
10.2 Free type definitions 135
10.3 Proof by induction 140
10.4 Primitive recursion 142
10.5 Consistency 145
11 Schemas 147
11.1 The schema 147
11.2 Schemas as types 152
11.3 Schemas as declarations 154
11.4 Schemas as predicates 158
11.5 Renaming 160
11.6 Generic schemas 162
12 Schema Operators 165
12.1 Conjunction 165
12.2 Decoration 168
12.3 Disjunction 174
12.4 Negation 177
12.5 Quantification and hiding 178
12.6 Composition 182
13 Promotion 185
13.1 Factoring operations 185
13.2 Promotion 193
13.3 Free and constrained promotion 196
14 Preconditions 201
14.1 The initialisation theorem 201
14.2 Precondition investigation 203
14.3 Calculation and simplification 206
14.4 Structure and preconditions 210
viii
15 A File System 217
15.1 A programming interface 217
15.2 Operations upon files 218
15.3 A more complete description 220
15.4 A file system 222
15.5 Formal analysis 227
16 Data Refinement 233
16.1 Refinement 233
16.2 Relations and nondeterminism 236
16.3 Data types and data refinement 241
16.4 Simulations 244
16.5 Relaxing and unwinding 248
17 Data Refinement and Schemas 257
17.1 Relations and schema operations 257
17.2 Forwards simulation 259
17.3 Backwards simulation 270
18 Functional Refinement 283
18.1 Retrieve functions 283
18.2 Functional refinement 285
18.3 Calculating data refinements 286
18.4 Refining promotion 291
19 Refinement Calculus 297
19.1 The specification statement 298
19.2 Assignment 299
19.3 Logical constants 304
19.4 Sequential composition 306
19.5 Conditional statements 309
19.6 Iteration 311
20 A Telecommunications Protocol 321
20.1 Specification: the external view 321
20.2 Design: the sectional view 322
20.3 Relationship between external and sectional views 325
20.4 Enriching the model 328
ix
21 AnOperatingSystemScheduler 331
21.1 Processes 331
21.2 Specification 332
21.3 Chains 336
21.4 Design 339
21.5 Correctness of the design step 344
22 ABoundedBufferModule 347
22.1 Specification 347
22.2 Design 351
22.3 A retrieve relation 352
22.4 Implementation 360
22.5 Executable code 363
23 ASaveArea 365
23.1 Specification 365
23.2 Design 368
23.3 Further design 372
23.4 Refinement to code 376
Index
Notation 387 Resources 389 This Book 391 Thanks 393
381
Foreword
Formal methods require a soundly based specification language. Until now the emphasis in the Z literature has been on the use of Z as a specification language. In this arena, use of Z is extensive and has been fostered by its many positive aspects, including the importance that has been placed on the careful merging of text and formal material.
The construction of a clear specification is the cornerstone of any formal development and—as the authors of the current book make clear—sometimes there is little incentive to go further with formalism than to provide such a specification.
But formal methods should also include a precise notion of correctness: a formal method should pin down exactly what it means for a design to satisfy a specification and provide tractable proof obligations for use in a development which requires formal justification. This book addresses notions of develop- ment based on Z specifications.
The authors’ emphasis on proof should be applauded. Although sometimes seen as a difficult undertaking, formal proofs are justified for systems on which major reliance is to be placed. There are also strong reasons for understanding notions of proof even where their use in full formality is not anticipated.
Pedagogically, experience with proof is the best route to a thorough under- standing of many of the logical and data operators in a specification language. Furthermore, attempting even outline proofs about specifications and designs will inculcate good taste in the construction of specifications.
For practical purposes, perhaps the most important reason for studying proof notions is that proof obligations can be used as mental checks during reviews or inspections of stages of design even where formal proofs are not presented. It is important to remember that errors made early in the develop-
xii
ment process are extremely expensive to correct if detected late. One of the key messages then is that proof investment in the early development phases of a project can pay a dividend in terms of productivity.
I therefore find myself in full agreement with the authors of this book when they tackle the issue of data refinement proofs before methods of refining to executable code. If one intends to use proofs only on some aspects of a project, it is the early decisions on data representation which will repay the investment most clearly.
In addition to set and logic notation, Z offers a ‘schema notation’ whose use gives rise to some delicate issues (calculation of pre-conditions etc.) in working out an appropriate development method for Z. The reader of this book is in the hands of experts who carefully motivate their refinement rules and tackle the question of why they are correct. The authors’ depth of experience is also clear from the warnings throughout the text of potential pitfalls of which the reader should be aware.
To derive maximum benefit from this book the reader should be prepared to study the material in detail. This is made easier by the careful progression of ideas and the well-chosen examples. The reader should also follow the larger case studies towards the end of the book. Such an investment will be hand- somely repaid by a thorough understanding of a development method from Z specifications to code.
Cliff B Jones
Using this Book
This book contains enough material for three courses of study: a course on mathematics for software engineering, a course on formal specification, and a course on refinement. This material can be adapted in a number of ways, to support other courses or as part of a programme of self-paced learning. To make the book easier to use, we have divided it into six parts:
Introduction Chapter 1 explains the use of formal methods, and introduces the Z notation. We discuss the importance of proof and explain what makes a good specification.
Logic Chapters 2 to 4 are an introduction to mathematical logic. We explain both propositional and predicate calculus, and introduce the concepts of equality and definite description.
Relations Chapters 5 to 10 cover sets and relations. We show how to specify objects, and relationships between them, using pieces of mathematics. We show also how the mathematical logic of Chapters 2 to 4 can be used to reason about specifications.
Schemas Chapters 11 to 14 introduce the schema language. We explain how schemas can be used to structure a specification, using logical combinators, sequential composition, and promotion. We present techniques for checking for logical consistency.
Refinement Chapters 16 to 19 are concerned with refinement. We formulate a theory of refinement within the relational calculus, and extend it to cover specifications involving schemas. We then show how a concrete design may be refined to produce executable code.
xiv
Case Studies Chapter 15 and Chapters 20 to 23 contain case studies in specification and refinement. These case studies show how the Z notation can be used to produce an abstract specification, a concrete design, and a programming language implementation.
These parts can be combined to provide an appropriate introduction to using Z, whatever the background of the reader.
The material in the book has already been used in a number of taught courses, at both graduate and undergraduate levels. Examples include:
Full-time MSc in Computation (1 year)
Logic and Relations are taught as a core course; Schemas and Case Studies are taught as an optional course.
Part-time Postgraduate Diploma/MSc in Software Engineering (2 years) Logic and Relations are taught as a single core course, Schemas as another core course, and Refinement as an optional course. Each course is delivered in a week of intensive teaching.
BA in Computer Science (3 years)
Logic and Relations are taught as part of a discrete mathematics course in the first year. Schemas are taught as part of a software engineering course in the second year.
Notice that, by omitting the development of each specification, Case Studies can be used in courses that do not cover Refinement.
Acknowledgments
This book is based upon our experience in teaching and using formal methods at the Programming Research Group, Oxford, and elsewhere. The courses that we teach draw their inspiration from the work of others: Jean-Raymond Abrial, Paul Gardiner, Ian Hayes, He Jifeng, Tony Hoare, Cliff Jones, Carroll Morgan, Jeff Sanders, Ib Holm Sørensen, Mike Spivey, and Bernard Sufrin.
We are grateful to many others: John Axford, Rosalind Barden, Stephen Brien, Neil Brock, Tim Clement, David Cooper, Will Harwood, Jonathan Hoare, Fleur Howles, Michael Jackson, Roger Jones, Steve King, Peter Lupton, Andrew Martin, Colin O’Halloran, Steve Schneider, Roger Shaw, Jane Sinclair, Susan Stepney, Pete Verey, Geoff Winn, John Wordsworth, and Maureen York.
We are grateful also to the students who have attended our lectures over the years: at the Programming Research Group; at Royal Holloway, University of London; at the University of Reading; at the University of Klagenfurt; on industrial courses and summer schools in Europe, North America, and Africa. Their comments and suggestions are much appreciated.
The file system and save area case studies are based upon work carried out by Ian Hayes and Ib Sørensen; the better examples of simulation were suggested by Carroll Morgan and Paul Gardiner; the better examples of refinement owe much to the work of Cliff Jones. The diagrams in Chapter 1 were supplied by the London Transport Museum.
Jackie Harbor, Helen Martin, and Derek Moseley of Prentice Hall were profes- sional but sympathetic at every turn. The last two years would have been less enjoyable if it had not been for their good humour, gentle tolerance, and quiet efficiency.
We would also like to thank our families, without whose love and support this book could not have been completed. This book is dedicated to them.
xvi
We would like to acknowledge the significant contribution made by the following institutions and organisations to the development of the material presented in this book:
• BNR Europe;
• British Telecom;
• Defence Research Agency, Malvern;
• Department of Computer Science, Reading;
• Department of Continuing Education, Oxford;
• Engineering and Physical Sciences Research Council; • Formal Systems (Europe) Ltd;
• IBM UK Laboratories;
• Kellogg College, Oxford;
• Logica Cambridge;
• Pembroke College, Oxford;
• Programming Research Group, Oxford;
• Rutherford–Appleton Laboratory.
Thank you.
Chapter 1
Introduction
Today’s software comes with extensive documentation: user guides, reference manuals, and design documents. There are on-line help systems, interactive tutorials, and friendly ‘introductions for dummies’. Yet the behaviour of soft- ware is often a surprise to users and designers alike. Components interact and interfere, undesirable properties emerge, and systems fail to meet their requirements.
The more spectacular consequences make the headlines: aircraft crash, trains collide, people receive fatal doses of radiation, and emergency telephone services are withdrawn. The less spectacular we face every day: time is wasted, effort is expended to no avail, important projects are scrapped, and our health is damaged by sheer frustration. All of this, and more, because software fails to live up to our expectations.
There are many explanations for this: the requirements upon a piece of software are hard to define, the ways in which a system may be used are hard to anticipate, and there is always a demand for additional functionality. Indeed, the fact that many pieces of software actually work, and work well, is some indication of the skill of those whose job it is to develop them.
1.1 Formal methods
One way to improve the quality of software is to change the way in which soft- ware is documented: at the design stage, during development, and after release. Existing methods of documentation offer large amounts of text, pictures, and diagrams, but these are often imprecise and ambiguous. Important informa- tion is hidden amongst irrelevant detail, and design flaws are discovered too late, making them expensive or impossible to correct.
2 1 / Introduction
There is an alternative. Formal methods, based upon elementary mathe- matics, can be used to produce precise, unambiguous documentation, in which information is structured and presented at an appropriate level of abstraction. This documentation can be used to support the design process, and as a guide to subsequent development, testing, and maintenance.
It seems likely that the use of formal methods will become standard prac- tice in software engineering. The mathematical basis is different from that of civil or mechanical engineering, but it has the same purpose: to add precision, to aid understanding, and to reason about properties of a design. Whatever the discipline, the use of mathematics can be expensive, but it is our experience that it can actually reduce costs.
Existing applications of formal methods include: the use of probability theory in performance modelling; the use of context-free grammars in compiler design; the use of the relational calculus in database theory. The formal method described in this book has been used in the specification and design of large software systems. It is intended for the description of state and state-based properties, and includes a theory of refinement that allows mathematics to be used at every stage of program development.
1.2 The CICS experience
CICS is one of the most successful pieces of software in the world: there are over 30 000 licences, and most of the world’s top companies use it. CICS stands for Customer Information Control System, a family of transaction processing products produced by IBM UK Laboratories at Hursley Park. CICS provides data access, communications, integrity, and security services. Put simply, CICS manages information.
When we use an automated teller machine in San Francisco, an account at our local branch in Oxford is debited, even though the machine is thousands of miles away. During the busiest times, there may be many thousands of customers of the bank using the service all over the world, and we all expect to be served within a reasonable time. CICS offers a way of achieving this.
There have been regular releases of CICS since the mid-1970s. Each release has introduced additional features and extended the structure of the existing code. In the early 1980s, the complexity of the system started to become a serious problem for the company. A decision was made to re-design some of the CICS modules with the aim of making extensions easier. An important part of the proposed solution involved finding a more precise way to specify functionality.
1.3 / The Z notation 3
Such precision requires the use of mathematical techniques that were, at that time, little known outside academia. A happy coincidence brought the CICS manager, Tony Kenny, and the Oxford professor, Tony Hoare, together at a conference. They hatched a plan to apply Oxford’s ideas to Hursley’s problems. Oxford advised on how formal methods could be used for the specification and design of new CICS modules. Hursley showed how the methods could be adapted to problems on an industrial scale.
A particular formal method, the Z notation, was used to specify the new CICS functionality. Hursley’s programmers were used to writing specifications in English, and the rigorous, mathematical notation was seen as a challenge. In practice, the notation proved easy to learn and to apply, even for program- mers with no previous experience of mathematics. The result was a perceived improvement in the quality and reliability of delivered code.
The first CICS product to be designed using Z was CICS/ESA version 3, an- nounced in June 1989. In April 1992, the Queen’s Award for Technological Achievement was conferred upon IBM United Kingdom Laboratories Limited and Oxford University Computing Laboratory for ‘the development and use of an advanced programming method that reduces development costs and signif- icantly enhances quality and reliability’: namely, Z.
1.3 The Z notation
The Z notation is based upon set theory and mathematical logic. The set theory used includes standard set operators, set comprehensions, Cartesian products, and power sets. The mathematical logic is a first-order predicate calculus. To- gether, they make up a mathematical language that is easy to learn and to apply. However, this language is only one aspect of Z.
Another aspect is the way in which the mathematics can be structured. Mathematical objects and their properties can be collected together in schemas: patterns of declaration and constraint. The schema language can be used to describe the state of a system, and the ways in which that state may change. It can also be used to describe system properties, and to reason about possible refinements of a design.
A characteristic feature of Z is the use of types. Every object in the mathe- matical language has a unique type, represented as a maximal set in the current specification. As well as providing a useful link to programming practice, this notion of types means that an algorithm can be written to check the type of every object in a specification; several type-checking tools exist to support the practical use of Z.
4 1 / Introduction
A third aspect is the use of natural language. We use mathematics to state the problem, to discover solutions, and to prove that the chosen design meets the specification. We use natural language to relate the mathematics to objects in the real world; this job is often partly achieved by the judicious naming of variables, but additional commentary is vital. A well-written specification should be perfectly obvious to the reader.
A fourth aspect is refinement. We may develop a system by constructing a model of a design, using simple mathematical data types to identify the desired behaviour. We may then refine this description by constructing another model which respects the design decisions made, and yet is closer to implementation. Where appropriate, this process of refinement can be continued until executable code is produced.
The Z notation, then, is a mathematical language with a powerful struc- turing mechanism. In combination with natural language, it can be used to produce formal specifications. We may reason about these specifications using the proof techniques of mathematical logic. We may also refine a specification, yielding another description that is closer to executable code.
Z is not intended for the description of non-functional properties, such as usability, performance, size, and reliability. Neither is it intended for the de- scription of timed or concurrent behaviour. However, there are other formal methods that are well suited for these purposes. We may use these methods in combination with Z to relate state and state-change information to comple- mentary aspects of design.
1.4 The importance of proof
In this book, we place considerable emphasis upon proof. When we introduce the language of mathematical logic, we explain the use of a proof system. When we introduce the language of sets and relations, we explain how formal proofs may be constructed about such objects. When we introduce the language of schemas, we show how to prove that a specification is consistent, and how to prove that one specification refines another. Our intentions are two-fold: first, to show that proof adds quality to software development; second, to show that proof is a feasible part of the industrial use of formal methods.
If we reason about a specification, if we attempt to construct proofs about its properties, then we are more likely to detect problems at an early stage of system development. The process of constructing proofs can help us to understand the requirements upon a system, and can assist us in identifying any hidden assumptions. Proof at the specification stage can make a significant contribution to the quality of software.
1.5 / Abstraction 5
At the design stage, a proof can show us not only that a design is correct, but also why it is correct. The additional insight that this affords can be invaluable: as requirements evolve and the design is modified, the consequences are easier to investigate. At the implementation stage, a proof can help us to ensure that a piece of code behaves according to the specification. Again, a significant contribution to quality can be made.
The construction of proofs is an essential part of writing a specification, just as proof-reading is an essential part of writing a book. A specification without proofs is untested: it may be inconsistent; it may describe properties that were not intended, or omit those that were; it may make inappropriate assumptions. The practice of proof makes for better specifications.
It seems to be part of software engineering folklore that proof is impos- sible on an industrial scale; however, our experience has been different. We have been involved in many large-scale applications of formal methods; some involved proof, others did not. We have seen that techniques involving proof are successful where formal methods are used with a light touch, and where proofs are conducted at an appropriate level of formality.
In many situations, a rigorous argument, or a semi-formal justification, will be sufficient to bring about the desired improvement in quality. In other, more critical situations, it may be necessary to increase the level of formality until the correctness of the design is beyond doubt. In some situations, a completely formal proof may be required. The trick of using formal methods effectively is to know when proofs are worth doing and when they are not.
1.5 Abstraction
An essential property of a good specification is an appropriate choice of abstrac- tion. A good example of this is provided by the various maps of the London Underground. When the first map was published in 1908, it was faithful to the geography of the lines: all the twists and turns of the tracks and the relative distances between stations were recorded faithfully and to scale. However, the purpose of the map was to show travellers the order of stations on each line, and the various interchanges between lines; the fidelity of the map made it difficult to extract this information.
In 1933, the map was changed to a more abstract representation, called the Diagram. Here, the connectivity of stations on the network was preserved, and at last, passengers could see at a glance the route to their destination. Abstraction from superfluous detail—in this case the physical layout of the lines—was the key to the usefulness of the Diagram. Figures 1.1 and 1.2 show published versions before and after the change.
6 1 / Introduction
Figure 1.1 A faithful geographical representation
The Diagram was, and still is, a good specification of the London Under-
ground network. It is
• Abstract. Since it records only the logical layout, not the physical reality in all its detail.
• Concise. Since it is printed on a single A5 sheet of card that is folded twice so that it fits into the pocket.
• Complete. Since every station on the London Underground network is rep- resented.
• Unambiguous. Since the meaning of the symbols used is explained, and the Diagram is expressed in simple geometrical terms. It is a precise and accurate description of the Underground network.
• Maintainable. Since it has been successfully maintained over the last 60 years, reflecting the changes in the network as stations have opened and closed, and new lines have been added.
1.5 / Abstraction
7
Figure 1.2 A more abstract description
• Comprehensible. Since it has been regarded fondly by its users from its first issue in January 1933, the Diagram must be readily understood by the general public.
• Cost-effective. Since it cost only five guineas to commission the specifica- tion from the engineering draughtsman Harry Beck.
The Diagram gives its users a good conceptual model; it is how Londoners and visitors see the Underground network. It embodies a specification structure that enables users to make sense out of a rather complex implementation. To do this, it uses abstract shapes, colours, and compression. All lines have been reduced to 90◦ or 45◦ angles. The various lines are coloured differently. The central area, where there are more stations, is shown in greater detail than the outlying parts, as if the Diagram were being viewed through a convex lens.
Furthermore, the Diagram may be used to predict the result of travelling on the Underground network. We might observe that if we start at Oxford Circus, travel eastbound on the Central Line and change trains at Tottenham
8 1 / Introduction
Court Road, then take the Northern Line, we may arrive at Mornington Crescent. In mathematical terms, this property is a theorem of the system; in practical terms, it describes a possible route.
The Diagram has served its purpose well; if only every specification were as good as this. Interestingly, the first sketch of the Diagram was rejected by the Publicity Department of the Underground. They thought that the idea of a 90◦ and 45◦ schematic treatment was too ‘revolutionary’. The abstract notation was thought to be too strange and incomprehensible for the ordinary user of the Underground network.
Chapter 2
Propositional Logic
In this chapter we introduce a logical language based upon traditional propo- sitional calculus. This language is part of the logical language of Z; other parts appear in subsequent chapters. Our presentation is based upon inference and proof: each component of the language is presented alongside rules that ex- plain when it may be introduced or eliminated.
Collected together, these rules form a system of natural deduction: they state what may be deduced from a proposition, and under what conditions that proposition may be concluded. This provides a framework for reasoning about statements in our language, proving properties and establishing results.
2.1 Propositional logic
Propositional logic deals with the statement of alleged facts which must be either true or false, but not both.
Example 2.1 The following statements are propositions:
• A tomato is a fruit.
• An orange is a fruit.
• Oranges are not the only fruit.
In our logical language, propositions may be connected in various ways. The following table describes five propositional connectives, arranged in descend-
10 2 / Propositional Logic ing order of operator precedence:
The table gives the connective’s symbol, its name, and how it is pronounced. Using the notion of precedence, we can see that the proposition
¬p ∧ q ∨ r q ⇒ p ∧ r
is equivalent to the parenthesised version
(((¬p) ∧ q) ∨ r) (q ⇒ (p ∧ r))
Using these connectives, we can build up compound propositions. Example 2.2
• ¬(jaffa cakes are biscuits)
• your cat is rich ∧ your dog is good looking
• the economic recovery has started ∨ the minister is lying • Jim is thirty-something ⇒ Jim is under forty
• Jim is thirty-something Jim is under forty
The truth of a compound proposition is uniquely determined by the truth of its constituent parts.
2.2 Conjunction
In the semantics of Z, a formal meaning is given to propositions; we don’t propose to reproduce this here, but rather to give an informal understanding. For example, the conjunction p ∧ q is true exactly when p is true and q is true. In case the reader thinks that this might be a sleight of hand—defining ∧ in
¬
negation
not
∧
conjunction
and
∨
disjunction
or
⇒
implication
implies
equivalence
if and only if
2.2 / Conjunction 11 terms of ‘and’—we can explain it by using a truth table:
In the first column we describe all the situations that we are interested in: all the combinations of the possible truth values of p and q (abbreviating truth and falsity to t and f ). In the second we have written down the truth value of p∧qineachofthesesituations. Thus,p∧qistruejustinthecasethatpis true and q is true.
Now, suppose that we wanted to prove that p ∧ q is true: the truth table tells us when that is so. If we follow the row that has the entry t for p ∧ q, we see that we must prove that both p and q are true (have the entry t). Thus, to prove p ∧ q, we must prove both p and also q. Now, suppose that we know that p ∧ q is true, then we certainly know that p must be true; we also know that q must be true. We can summarise these observations with the following rules of inference:
p q [∧−intro] p ∧ q [∧−elim1] p ∧ q [∧−elim2] p∧qpq
These inference rules form part of the natural deduction system that we use to conduct our proofs.
Each inference rule is written in the following form:
p
q
p∧q
t
t
t
t
f
f
f
t
f
f
f
f
premiss1 . . . premissn [name] conclusion
side condition
The list of premisses is sometimes empty; the role of the side condition will become clear later. The meaning of such a rule is that the truth of the conclusion follows from the truth of the premisses: whenever the premisses are true, then so is the conclusion.
The rules come in two flavours. For an operator op, the op-elimination rule describes what may be deduced from p op q; and the op-introduction rule describes under what conditions p op q can be concluded. Using these rules to introduce and eliminate different operators, we can start from a set of propositions, or hypotheses, and derive another proposition. If the set of hypotheses is empty, then we call the derived proposition a theorem.
12 2 / Propositional Logic
We now have two ways of proving things about a proposition. Consider the conjecture that conjunction is commutative. This means that it doesn’t matter which way round we present the operands to the conjunction operator: p ∧ q is the same as q ∧ p. We prove this first by constructing a truth table, and second by using the rules that we have for introducing and eliminating the conjunction operator.
Example 2.3 First, consider the two truth tables:
We can abbreviate the two tables by displaying them in one:
Notice that the columns for p ∧ q and q ∧ p are identical: in every situation they take the same truth value; thus, we can conclude that they are the same proposition, and so conjunction is commutative.
Now, we shall prove that conjunction is commutative by using a natural deduc- tion argument.
Example 2.4 We want to prove that p ∧ q is equivalent to q ∧ p, and this may be deduced from the rule:
p∧q q∧p
We prove this derived rule by exhibiting a proof tree, built from rules fitted together jigsaw-wise. The leaves (at the top of the tree) are instances of the premisses, and the root (at the bottom of the tree) is the conclusion.
q∧p
p
q
p∧q
t
t
t
t
f
f
f
t
f
f
f
f
q
p
q∧p
t
t
t
f
t
f
t
f
f
f
f
f
p
q
p∧q
q∧p
t
t
t
t
t
f
f
f
f
t
f
f
f
f
f
f
p ∧ q [∧−elim2] p ∧ q [∧−elim1]
q
p [∧−intro]
2.3 / Disjunction 13
In this tree, there are three rules which have been used. Where the conclu- sion of one rule forms the premiss of the next, they match exactly. The tree matches the rule that we were trying to prove, since, if we take all the leaves and remove duplicates, we end up with the premiss of the rule; the root of the tree corresponds to the conclusion.
One more piece of terminology and its notation. Some premisses are in- troduced during a proof: they are called assumptions. An assumption must be discharged during a proof, and there are certain rules (discharge rules) which do this. The assumption p is denoted by ⌈p⌉[]. In the next section we see examples of assumptions and discharge rules.
2.3 Disjunction
The disjunction p ∨ q is true if and only if p is true or q is true:
This is inclusive or: the disjunction is true in any situation in which one of the disjuncts is true, including the situation in which both are true. The disjunction p ∨ q is true if and only if either p is true or q is true. Our three rules are:
p
q
p∨q
t
t
t
t
f
t
f
t
t
f
f
f
⌈p⌉[i] ⌈q⌉[i] pqp∨qrr
p ∨ q [∨−intro1] p ∨ q [∨−intro2] r
[∨−elim[i]]
Both introduction rules hold because, if p is true, then p ∨ q is true; similarly for q. The elimination rule follows by supposing that p ∨ q is true; then, either p or q holds (we don’t know which, and it might be both). Whatever follows from this (say r) must follow in both cases. Thus, the elimination rule is an example of case analysis. In the premiss
⌈p⌉[i] r
the notation ⌈p⌉[i] indicates that p is an assumption which may be made in order to prove r. The superscript i indicates that this assumption is justified
14 2 / Propositional Logic
by a step labelled i in the proof tree. It is discharged from the proof of r when the rule is applied: given a proof of p ∨ q, a proof of r from the assumption p, and a proof of r from the assumption q, the rule concludes r.
Example 2.5 Disjunction is commutative:
The entries for p ∨ q and q ∨ p are identical. Example 2.6 Disjunction is commutative:
p∨q q∨p
⌈p⌉[1] ⌈q⌉[1]
p∨q q∨p [∨−intro2] q∨p [∨−intro1]
q ∨ p [∨−elim[1]]
2.4 Implication
The implication p ⇒ q may be viewed as expressing an ordering between the antecedent p and the consequent q: it states that the antecedent is stronger than (or equal to) the consequent. False is stronger than true; true is weaker than false; anything is as strong as itself. This gives the truth table
p
q
p∨q
q∨p
t
t
t
t
t
f
t
t
f
t
t
t
f
f
f
f
p
q
p⇒q
t
t
t
t
f
f
f
t
t
f
f
t
2.4 / Implication 15
Thus, the implication is true unless the antecedent is true and the consequent is false.
The implication p ⇒ q is true if and only if we can prove q by assuming p. Thus, in order to prove that p ⇒ q, we may assume that p is true and then prove that q is true also. If we know that p ⇒ q, then we can conclude that q is true, providing that we show that the assumption p holds. This gives us the two rules for implication:
p ⇒ q [⇒−intro[i]] q
Example 2.7 We can replace a conjunction of antecedents in an implication by
separate antecedents:
(p ∧ q ⇒ r) ⇒ (p ⇒ (q ⇒ r))
We may prove this by constructing a truth table:
⌈p⌉[i]
q p⇒qp
[⇒−elim]
p
q
r
(p ∧ q ⇒ r) ⇒ (p ⇒ (q ⇒ r))
t
t
t
ttttt
t
t
f
tftff
t
f
t
ftttt
t
f
f
ftttt
f
t
t
ftttt
f
t
f
ftttf
f
f
t
ftttt
f
f
f
ftttt
Every entry in the column underneath the major connective in the proposition is a t: thus the proposition is true in every situation.
Example 2.8 We can replace a conjunction of antecedents in an implication by separate antecedents:
(p ∧ q ⇒ r) ⇒ (p ⇒ (q ⇒ r))
16 2 / Propositional Logic To see how this might be established, consider the incomplete proof tree:
.
(p ∧ q ⇒ r) ⇒ (p ⇒ (q ⇒ r))
The major connective is an implication; we could consider how it got there, and
try to introduce it:
⌈p ∧ q ⇒ r⌉[1] .
(p ⇒ (q ⇒ r)) [⇒−intro[1] ] (p ∧ q ⇒ r) ⇒ (p ⇒ (q ⇒ r))
This leaves us with a new goal, p ⇒ (q ⇒ r), in which the major connective is again an implication. We follow the same procedure as before; we consider how this operator may be introduced:
⌈p ∧ q ⇒ r⌉[1] ⌈p ⌉[2]
.
q ⇒ r [⇒−intro[2]]
(p ⇒ (q ⇒ r))
(p ∧ q ⇒ r) ⇒ (p ⇒ (q ⇒ r))
[⇒−intro[1]]
Again the goal is an implication. Using the introduction rule a third time leaves
us in the following situation:
⌈p ∧ q ⇒ r⌉[1] ⌈p ⌉[2] ⌈q⌉[3]
.
r [⇒−intro[3] ]
q ⇒ r
(p ⇒ (q ⇒ r))
(p ∧ q ⇒ r) ⇒ (p ⇒ (q ⇒ r))
[⇒−intro[2]] [⇒−intro[1]]
At this stage, the structure of the goal suggests nothing: there is no struc- ture. Now is the time to start working forwards from the assumptions: one of them has an implication, so we should try to eliminate that:
2.5 / Equivalence
⌈p∧q⇒r⌉[1] r
17
q ⇒ r
(p ⇒ (q ⇒ r))
(p ∧ q ⇒ r) ⇒ (p ⇒ (q ⇒ r))
⌈p ∧ q ⇒ r⌉[1] ⌈p ⌉[2] ⌈q⌉[3]
.
p∧q [⇒−elim] [⇒−intro[3] ]
[⇒−intro[2]] [⇒−intro[1]]
It is clear now how to finish this proof: the assumptions p and q can be con- joined to discharge the conjunction p ∧ q:
⌈p⌉[2] ⌈q⌉[3]
⌈p ∧ q ⇒ r⌉[1] p ∧ q [∧−intro]
r [⇒−elim] q ⇒ r [⇒−intro[3]]
(p ⇒ (q ⇒ r)) [⇒−intro[2]] (p∧q⇒r)⇒(p⇒(q⇒r)) [⇒−intro[1]]
2.5 Equivalence
The equivalence p q means that p and q are of the same strength; thus it might also be called bi-implication: p q means that both p ⇒ q and q ⇒ p. Since p and q have the same strength, they must therefore have the same entries in the truth table:
The rules for introducing and eliminating the equivalence connective follow from the observation that p q is equivalent to p ⇒ q and q ⇒ p (they are
p
q
pq
t
t
t
t
f
f
f
t
f
f
f
t
18 2 / Propositional Logic reminiscent of the rules for conjunction).
p⇒q q⇒p [−intro] pq [−elim1] pq [−elim2] pq p⇒q q⇒p
Example 2.9 If p is stronger than q, then p ∧ q and p have the same strength: p⇒q
p∧qp
To show that this is a derived rule of our system, consider the goal
.
p∧qp
The major connective is the equivalence, so let’s try to introduce it:
. .
p∧q⇒p p⇒p∧q [−intro]
p∧qp
In the left-hand subtree, the major connective is now an implication, so let’s try
to introduce that:
⌈p ∧ q⌉[1] .
p p∧q⇒p
.
[⇒−intro[1] ] p∧qp
. [⇒−intro] p⇒p∧q [−intro]
The left-hand subtree may now be completed by conjunction elimination on the assumption. Turning now to the right-hand subtree, we should immediately introduce the implication:
⌈p ∧ q⌉[1]
p [∧−elim1]
p ∧ q ⇒ p [⇒−intro[1]] p ∧ q p
⌈p ⌉[2] .
p ∧ q
p ⇒ p ∧ q [⇒−intro[2]]
[−intro]
2.5 / Equivalence 19 Now, the major connective is a conjunction, so we introduce it:
⌈p ∧ q⌉[1]
p [∧−elim1]
p ∧ q ⇒ p [⇒−intro[1]] p ∧ q p
q
⌈p ⌉[2] .
⌈p ⌉[2] .
p
p ⇒ p ∧ q [⇒−intro[2]]
p ∧ q
[∧−intro] [−intro]
The left-most unfinished subtree can be closed easily, since we have to prove p from the assumption p: that is immediate. The right-most one cannot be pushed further backwards, since there is no structure to exploit; instead, we work from our premiss:
⌈p ∧ q⌉[1]
p [∧−elim1]
p ∧ q ⇒ p [⇒−intro[1]] p ∧ q p
p ⇒ q ⌈p⌉[2] q
⌈p ⌉[2] .
p [⇒−elim] [∧−intro]
p ∧ q
p ⇒ p ∧ q [⇒−intro[2]]
[−intro]
Again, the closing of this subtree is trivial, thus completing the proof:
⌈p ∧ q⌉[1]
p [∧−elim1]
p ∧ q ⇒ p [⇒−intro[1]] p ∧ q p
[⇒−elim] [∧−intro]
p ⇒ q p ∧ q
⌈p⌉[2]
⌈p⌉[2]
p ⇒ p ∧ q [⇒−intro[2]]
A derived rule may be used in the same way as any other inference rule; the above example gives us
p ⇒ q [subsume] p∧qp
This is just one of several similar inference rules involving conjunction, dis- junction, and implication.
q
[−intro]
20 2 / Propositional Logic 2.6 Negation
The negation ¬p is true if and only if p is false. The truth table is simple:
Our rules for negation make use of a special proposition called false, which stands for a contradiction: it is false in every situation. If ¬p is true, then p is false; and if p is true, then ¬p is false. Notice that it is not possible for ¬p and p both to be true. This gives us three rules:
p
¬p
t
f
f
t
⌈p⌉[i] false ¬p
[¬−intro[i] ]
p ¬p false
[¬−elim]
⌈¬p⌉[j] false
p [false−elim[j] ]
Our system requires three rules to deal with negation. At first sight, it might seem that the two rules that we have called ¬−intro and false−elim would be sufficient, but they would give us no way of concluding false.
Example2.10 OneofdeMorgan’sLawsstatesthatthenegationofadisjunc- tion is the conjunction of negations:
¬(p ∨ q) [de Morgan1] ¬p ∧ ¬q
We start by considering the goal:
.
¬p ∧ ¬q
Clearly, we should break up the conjunction:
. .
¬p ¬q [∧−intro] ¬p ∧ ¬q
2.6 / Negation 21 Let’s focus on the left subtree. In order to prove the negation ¬p, we should
assume p and then force a contradiction: ⌈p ⌉[1]
. . false [¬−elim] .
¬p [¬−intro[1] ] ¬q [∧−intro] ¬p ∧ ¬q
Now, what should the contradiction be? We have the premiss ¬(p ∨ q), we could try to contradict that:
⌈p ⌉[1] .
p∨q
¬p
We can close this subtree by noting that we can prove p ∨ q from p:
¬(p∨q) [¬−elim] false [¬−intro[1]]
. .
¬p ∧ ¬q
¬q [∧−intro]
⌈p ⌉[1]
p ∨ q [∨−intro1] ¬(p ∨ q) [¬−elim]
false [¬−intro[1]] ¬p
¬p ∧ ¬q
The rest of the proof follows by symmetry:
⌈p⌉[1]
p ∨ q [∨−intro1] ¬(p ∨ q) [¬−elim]
false [¬−intro[1]] ¬p
¬p ∧ ¬q
Before a natural deduction system becomes really useful, it is necessary to prove results about negation. In the next theorem we use the variant of de Morgan’s law that we have just proved.
. .
¬q [∧−intro] ⌈q⌉[2]
p ∨ q [∨−intro2]
false [¬−intro[2]]
¬(p ∨ q) [¬−elim] ¬q [∧−intro]
22 2 / Propositional Logic Example 2.11 The Law of the Excluded Middle states that either a proposition
is true or it is false. That is,
p ∨ ¬p
The major connective is a disjunction, so let’s try to introduce it. Which
disjunct should we throw away? Let’s try ¬p: .
p [∨−intro1] p ∨ ¬p
Now there is no structure to analyse, so we are lost, since there are no as- sumptions or premisses either. We must admit defeat and backtrack to the last choice that we made. Perhaps we should have thrown away p instead:
.
¬p [∨−intro2]
p ∨ ¬p
Now we are in the same position: we still cannot complete the proof. Again, we must backtrack to the last decision point. This time, we go right back to the start of the proof. We have tried both varieties of disjunction introduction, and there are neither assumptions nor premisses to work from. What now? One possible way forward is to try to contradict our goal: assume ¬(p ∨ ¬p) and force a contradiction:
⌈¬(p ∨ ¬p)⌉[1] .
false [false−elim[1] ] p ∨ ¬p
Our contradiction follows by Example 2.10: ⌈¬(p ∨ ¬p)⌉[1]
¬p ∧ ¬¬p [de Morgan1]
.
false [¬−elim]
p ∨ ¬p [false−elim[1]]
2.7 / Tautologies and contradictions 23
The proof tree isn’t quite closed, because of the technicality that we need two separate propositions: ¬p and ¬¬p. We can get each from the conjunction, so we need to duplicate our work from the assumption, and use both varieties of conjunction elimination:
⌈¬(p ∨ ¬p)⌉[1]
¬p ∧ ¬¬p [de Morgan1]
¬p [∧−elim1] false
Now we have finished, and the proof tree is complete.
The last example shows an important part of the proof process: the exploration of possibilities. When we look at a proof, we see only a completed chain of rea- soning; we do not see the other attempts that may have been made. Further- more, rules like negation elimination give us a problem in a backwards proof, since p appears in the premiss, but not in the conclusion. Thus, when we match the consequent to our current goal, we still have to find an instantiation of p.
2.7 Tautologies and contradictions
Propositions which evaluate to t in every combination of their propositional variables are known as tautologies: they are always true. If, on the other hand, they evaluate to f in every combination, then they are known as contradictions. Of course, the negation of a contradiction is a tautology, and vice versa.
Example 2.12 The following propositions are tautologies:
p ∨ ¬p p⇒p
p ⇒ (q ⇒ p)
while the following are contradictions:
p ∧ ¬p
p ¬p
¬(p ⇒ (q ⇒ p))
⌈¬(p ∨ ¬p)⌉[1]
¬p ∧ ¬¬p [de Morgan1]
[∧−elim2] [¬−elim]
¬¬p p ∨ ¬p [false−elim[1]]
24 2 / Propositional Logic
To prove that a proposition is a tautology, we have only to produce a truth table and check that the major connective takes the value t for each combination of propositional variables.
Example 2.13 We prove that ¬p ∨ q p ⇒ q is a tautology by exhibiting the following table:
Tautologies involving equivalences are particularly useful in proofs; they can be used to rewrite goals and assumptions to facilitate the completion of an ar- gument. For any pair of propositions a and b, the tautology a b corresponds to a pair of inference rules:
b [ab] a [ab] ab
If either of these propositions appears in a proof, then we may replace it with the other:
p
q
¬p ∨ q p ⇒ q
t t f f
t f t f
fttt fftf tttt tttt
. a.
b [ab] . .
A logical equivalence may be used to justify rewriting even when the proposition involved is only part of the goal or assumption:
.
(¬p∨q)⇒r [(¬a∨b)(a⇒b)] .
.
(p ⇒ q) ⇒ r
.
2.7 / Tautologies and contradictions 25 Tautologies involving implications also correspond to inference rules: if
a ⇒ b is a tautology, then a [a⇒b]
may be used as a derived rule. An implication alone is not enough to justify rewriting part of a goal. To see why not, consider the following proposition:
(p ∧ q) ⇒ (r ∨ s)
The proposition (a ∧ b) ⇒ a is a tautology, but the proof step
(p∧q)⇒(r∨s) [(a∧b)⇒a] p ⇒ (r ∨ s)
is invalid. The statement p ⇒ (r ∨ s) does not follow from (p ∧ q) ⇒ r ∨ s: it is possible for the former to be false when the latter is true.
Example 2.14 The following tautology ¬(p ∧ q) ⇒ ¬p ∨ ¬q
corresponds to another of de Morgan’s laws:
¬(p ∧ q) [de Morgan2] ¬p ∨ ¬q
A proposition which is neither a tautology nor a contradiction is said to be a contingency.
b
Chapter 3
Predicate Logic
In this chapter we introduce another part of our logical language. The language of propositions introduced in the previous chapter allows us to make state- ments about specific objects, but it does not allow us to make statements such as ‘Every cloud has a silver lining’. These are known as universal statements, since they describe properties that must be satisfied by every object in some universe of discourse.
Example 3.1 The following are examples of universal statements:
• Each student must hand in course work.
• Nobody knows the trouble I seen.
• Jim doesn’t know anybody who can sign his bail application.
Sometimes we wish to state that at least one thing has a particular property, without necessarily knowing which thing it is. This leads to an existential state- ment.
Example 3.2 The following are examples of existential statements:
• I heard it from one of your friends. • A mad dog has bitten Andy.
• Some people prefer logic.
28 3 / Predicate Logic
To formalise such statements, we require a language that reveals the internal structure of our propositional statements, a language that allows us to take them apart and apply them to objects without proper names. The language we require is the language of predicate calculus.
3.1 Predicate calculus
A predicate is a statement with a place for an object. There may be many such places within a single predicate; this is often the case when the objects con- cerned are mathematical. When these places are filled, our predicates become statements about the objects that fill them. We could say that a predicate is a proposition with a gap for an object of some kind.
For example, the statement ‘ > 5’ is a predicate. As it stands, it is not a proposition; we cannot say whether it is true or false until we have filled the empty place. We could turn it into a proposition by putting 0 in this place; the result would be ‘0 > 5’, a proposition that happens to be false. This is not the only way to fill a gap, however. We could also choose to put an object variable in the empty place above.
The predicate ‘x > 5’ is still not a proposition; we cannot say whether it is true or false without knowing what x is. The use of object variables is a powerful technique, and holds the key to expressing the universal and existen- tial properties described above. We can make a proposition out of ‘x > 5’ by adding a quantifier to the front of the expression. For example, we could state that ‘there is an x, which is a natural number, such that x > 5’. Here, the quan- tifier is ‘there is an…’, and we have quantified the predicate ‘x > 5’ to produce a true proposition.
In mathematics, the symbol ‘∃’ is used to denote the expression ‘there is an …’; in Z, the natural numbers are denoted by the symbol ‘N’. Thus, we can write down our quantified predicate in Z as:
∃ x : N • x > 5.
To see that the quantified predicate is true, consider the number 6: it is a natural number, and it is greater than 5.
Existential quantification may be thought of as a generalised form of dis- junction: for example,
∃x:N•x>5
0>5∨1>5∨2>5∨3>5∨…
3.1 / Predicate calculus 29 The predicate is true for some natural number; it is true of 0 or it is true of 1
or it is true of 2 or it is true of 3, etcetera.
Example 3.3 The statements in Example 3.2 may be formalised as follows:
• Let Friends stand for the set of all your friends, and let x told y mean that x has told y.
∃ f : Friends • f told me
• Let MadDog stand for the set of all mad dogs, and let x bit y mean that x
has bitten y.
∃ d : MadDog • d bit Andy
• Let Person stand for the set of all people, and let PL(x) mean that x prefers logic.
∃ p : Person • PL(p)
Another way of quantifying a predicate is to say that it is true for every value. We might take the predicate ‘x > 5’ and prepend a universal quantifier to produce the statement ‘for every x which is a natural number, it is the case that x > 5’. Here, the quantifier is ‘for every x …’, and we have quantified the predicate to produce a false proposition.
In mathematics, the notation ‘∀’ is used to denote the universal quantifier. We can write down our new predicate in Z as follows:
∀ x : N • x > 5. Again, this is the same as ∀ y : N • y > 5.
This predicate is false because not every natural number x is greater than 5: consider 3.
The universal quantifier may be thought of as a generalised conjunction: for example,
∀x:N•x>5
0>5∧1>5∧2>5∧3>5∧…
30 3 / Predicate Logic
The predicate > 5 would have to be true of every natural number; of 0 and of 1 and of 2 and of 3, etcetera. It is not true of 0, for example, and thus the whole quantified expression is false.
Example 3.4 The statements in Example 3.1 may be formalised as follows:
• Let Student stand for the set of all students, and let Submit(x) mean that
x must hand in course work. ∀s : Student • Submit(s)
• Let Person be the set of all people, and let knows trouble(x) mean that x knows the trouble I seen.
∀ p : Person • ¬knows trouble(p)
• Again, let Person be the set of all people. Let x Knows y means that x knows
y, and let x CanBail y mean that x can sign y’s application for bail. ∀ p : Person • Jim Knows p ⇒ ¬(p CanBail Jim)
3.2 Quantifiers and declarations
In the Z notation, the two kinds of quantified expressions have a similar syntax:
Qx:a|p•q where
• Q is the quantifier;
• x is the bound variable; • aistherangeofx;
• p is the constraint; and • q is the predicate.
The optional constraint p restricts the set of objects under consideration; only those objects in a that satisfy p are to be considered. The constraint takes
3.2 / Quantifiers and declarations 31 on the role of a conjunction or an implication, depending upon the quantifier
concerned, as may be seen from the following equivalences:
(∃x:a|p•q) (∃x:a•p∧q) (∀x:a|p•q) (∀x:a•p⇒q)
The existentially quantified predicate
∃x:a|p•q
is pronounced ‘there exists an x in a satisfying p, such that q’. The universally
quantified predicate
∀x:a|p•q
is pronounced ‘for all x in a satisfying p, q holds’.
Each quantifier introduces a ‘bound variable’, which is analogous to a local
variable in a block-structured programming language. In the quantified pred- icate Q x : a | p • q the bound variable x has a scope that is exactly the constraint p and predicate q. The quantifiers bind very loosely, so the scope of a quantified variable extends to the next enclosing bracket.
Example 3.5 In the following expression, the scope of variable x is marked by a brace:
(∀ x : a | p • q ∧ r ) ∨ s ⇒ t
scope of x
If a statement contains more than one quantifier, the scopes may overlap. This poses no problems unless the same name is chosen for two variables bound by different quantifiers; in this case, there would be a hole in one of the scopes.
Example 3.6 In the following expression, the scope of the first bound variable has a hole corresponding to the scope of the second:
scope of second y
∀y:a|p•q∧(∀y:b|r•s⇒t )∧u∨v
scope of first y scope of first y
32 3 / Predicate Logic
As the above example shows, there is scope for confusion whenever two differ- ent variables have the same name.
Whenever such confusion can arise, we will choose another name for one of the variables. We can change the name of a bound variable without changing the meaning of the quantified expression, as long as we avoid the names of any other variables that appear.
Example 3.7 Consider the following quantified expression, which states that every natural number x is greater than or equal to zero:
∀ num : N • num ≥ 0
The choice of ‘num’ as the variable name is not important; the following ex-
pression has the same meaning:
∀nat :N•nat ≥0
We must take care that the new name chosen for a bound variable has not already been used for a different variable in the same expression.
Example 3.8 Consider the following quantified expression, which states that there is some natural number max such that every natural number num must be less than or equal to max:
∃ max : N • ∀ num : N • num ≤ max
This statement is false: there is no greatest natural number.
If we were to change the name of the universally-quantified variable from num to max, then some confusion would result. The following expression states that there is some natural number such that every natural number is
less than or equal to itself.
∃ max : N • ∀ max : N • max ≤ max
This statement is true; the meaning has changed.
To avoid changing the meaning of a statement, we insist that a fresh variable name is chosen whenever such a change of name occurs. This name should not appear elsewhere in the logical expressions under consideration.
In the last example, we saw two variables quantified at the start of an ex- pression, one immediately after the other. In this case, the quantifiers were different. Had they been the same, we could have quantified both variables at the same time, separating their declarations with a semicolon.
3.2 / Quantifiers and declarations 33 Example 3.9 The quantified predicate
∃x:a•∃y:b•p could also be written as
∃ x : a; y : b • p
There is a circumstance in which this is not possible: when the first quantified variable appears in the range of the second.
Example 3.10 In the expression below, the first bound variable is used as the range of the second:
∃a:b•∃c:a•p
In this case, it would make no sense to merge the two quantifications.
If a variable x appears in a predicate p but is not bound by any quantifier, we say that x is free in p. Each occurrence of x that is outside the scope of a declaration of the form ‘∀ x : a’ or ‘∃ x : a’ is said to be a free occurrence.
Example 3.11 In the expression below, there is a single free occurrence of vari- able z:
∀x:N•z≤x
This predicate states that every natural number x is greater than z, whatever z
may be.
If we use the same name for two different variables, then we may find that a
variable appears both free and bound in the same expression.
Example 3.12 There are both free and bound occurrences of variable x in the expression below:
x =3∧∀x:N•0≤ x
free occurrence bound occurrence
The occurrence of x adjacent to the quantifier is neither free nor bound; it is a binding occurrence.
34 3 / Predicate Logic
3.3 Substitution
If a predicate p contains a free occurrence of variable x, then p may represent a non-trivial statement about x. The choice of variable x is important: p does not, in general, represent the same statement about any other variable y. If we wish to change the subject of the statement from x to y, we must replace each free occurrence of x in p with an occurrence of y. This process is called substitution.
We write p[y / x] to denote the predicate that results from substituting y for each free occurrence of x in predicate p; this new operator binds more tightly than any other. The expression y need not be another variable; it can be any expression whose possible values match those of x.
Example 3.13
1.(x≤y+2)[0/x] (0≤y+2) 2.(∃x:N•x≤y+2)[0/x] (∃x:N•x≤y+2) 3.(∃x:N•x≤y+2)[5/y] (∃x:N•x≤5+2)
We write p[t / x][u / y] to denote the predicate p[t / x] with the expression u systematically substituted for free occurrences of the variable y.
Example 3.14
1.(x≤y+2)[0/x][5/y] (0≤y+2)[5/y] (0≤5+2) 2.(x≤y+2)[y/x][5/y] (y≤y+2)[5/y] (5≤5+2)
We write p[t,u/x,y] to denote the result of simultaneously substituting t for x and u for y in predicate p. In general, this is different from the multiple substitution p[t / x][u / y].
Example 3.15
1.(x≤y+2)[y,5/x,y] (y≤5+2) 2.(x≤y+2)[y/x][5/y] (y≤y+2)[5/y] 5≤5+2
3.3 / Substitution 35
A potential problem with substitution is the unintentional capture of free variables. If y is bound in p, then the substitution p[y / x] might include new bound instances of y in place of free instances of x. This may change the meaning of p in a way that is not intended.
Example 3.16 Let Person denote the set of all people, and let m LooksLike n mean that person m looks like person n. The following predicate is a statement about a person o; it states that there is some person who does not look like o:
∃ p : Person • ¬(p LooksLike o)
We may make the same statement about person m by substituting m for o:
∃ p : Person • ¬(p LooksLike m)
However, if we substitute p for o, we obtain a different statement entirely:
∃ p : Person • ¬(p LooksLike p)
The expression substituted for o contains a free occurrence of p, which is then bound by the quantifier. The new predicate states that there is someone who does not look like themself. The substitution has brought an unwanted change of meaning.
To avoid such confusion, we may rename bound variables prior to substitution, choosing fresh variable names to avoid variable capture.
We can give equivalences to explain the effect of substitution into quanti- fied expressions. In the simplest case, the variable being substituted for has the same name as the one being quantified:
(∀x:a|p•q)[t/x] (∀x:a[t/x]|p•q) (∃x:a|p•q)[t/x] (∃x:a[t/x]|p•q)
In this case, the only part of the expression that may change is the range of the quantified variable. In general, this substitution will have no effect; it is poor practice to include a free variable in the declaration of a bound variable of the same name.
If the quantifier is binding some variable other than x, then the substitution will have more of an effect. If y is not free in t, then
(∀y:a|p•q)[t/x] (∀y:a[t/x]|p[t/x]•q[t/x]) (∃y:a|p•q)[t/x] (∃y:a[t/x]|p[t/x]•q[t/x])
36 3 / Predicate Logic If y is free in t, then we choose a fresh variable z, different from x and not
appearing in t:
(∀y : a | p • q)[t /x]
(∀z:a[t/x]|p[z/y][t/x]•q[z/y][t/x])
(∃y : a | p • q)[t /x]
(∃z:a[t/x]|p[z/y][t/x]•q[z/y][t/x])
By using z instead of y for the name of the quantified variable, we have avoided any possibility of unintentional variable capture.
If the major operator in an expression is not a quantifier, then the effect of substitution is easy to explain:
(¬p)[t/x] ¬p[t/x] (p∧q)[t/x] p[t/x]∧q[t/x] (p∨q)[t/x] p[t/x]∨q[t/x]
(p⇒q)[t/x] p[t/x]⇒q[t/x] (pq)[t/x] p[t/x]q[t/x]
In every case, substitution distributes through the propositional operators.
3.4 Universal introduction and elimination
In general, the truth-table technique for giving meaning to connectives and reasoning about them is useless for the quantifiers, since the sets that bound variables may range over are simply too large. However, we may build upon the natural deduction system of the previous chapter by adding rules to introduce and eliminate quantifiers.
If we view universal quantification as a generalised conjunction, then we should be able to generalise the rules for conjunction to get the rules for the universal quantifier. Consider first the introduction rule. In order to prove p ∧ q, one needs to prove both p and q. In order to prove ∀ x : a • p, one must prove that p is true for each value in a. This doesn’t sound terribly hopeful, as it might involve an infinite number of premisses, and therefore an infinite number of proofs.
A better approach might be to prove that p holds for an arbitrary member of a: if we make no assumptions whatsoever about which member of a we choose in order to prove p, then our proof generalises to all members. A simplified
3.4 / Universal introduction and elimination 37 rule for introducing universal quantification is the following:
⌈x ∈ a⌉[i]
q provided that x is not free
∀x : a • q [[i]] in the assumptions of q
where x ∈ a means that x is a member of set a.
Notice that we are required to check that x is not free in the assumptions of
q. This ensures that we are not making any assumptions about which member of a we are choosing. The assumptions of q are those leaves of the proof tree above q that have not been discharged: by implication-introduction, for example.
In the full form of the universal quantifier, there is also a constraint that x must satisfy; we may treat the constraint as an additional assumption:
⌈x ∈ a⌉[1] ⌈p ⌉[1]
q [1] provided that x is not free ∀x:a|p•q [∀−intro ] intheassumptionsofq
This rule may be derived from the first ∀−intro rule:
⌈x ∈ a⌉[1] ⌈p ⌉[2]
.
q
p ⇒ q [⇒−intro[2]]
∀x:a•p⇒q [∀−intro[1]] ∀x:a|p•q [defn]
The constraint part of a universal quantification may be treated as the an- tecedent of an implication.
From a conjunction, one may conclude either of the conjuncts; by analogy, from a universally quantified predicate, one may conclude that the predicate holds for any value in the range. Suppose that we have the universally quanti- fied predicate ∀ x : a • p, and that the expression t denotes a value in a; then p must be true of t.
t∈a ∀x:a•p p[t /x]
38 3 / Predicate Logic
We systematically substitute t for x in p.
The full form requires the equivalent of implication elimination, to demon-
strate that the expression chosen satisfies the constraint:
t∈a ∀x:a|p•q p[t/x] [∀−elim] q[t /x]
A special case of the last rule takes t as x: x∈a ∀x:a|p•q p [∀−elim]
q
Example 3.17 The universal quantifier distributes through conjunction. We will prove this in one direction only:
(∀ x : a • p ∧ q) ⇒ ((∀ x : a • p) ∧ (∀ x : a • q)) We begin the proof with the stated goal:
.
(∀ x : a • p ∧ q) ⇒ ((∀ x : a • p) ∧ (∀ x : a • q))
The major connective here is the implication, so we assume the antecedent and try to prove the consequent:
⌈∀ x : a • p ∧ q⌉[1] .
(∀x : a • p) ∧ (∀x : a • q) [⇒−intro[1]] (∀ x : a • p ∧ q) ⇒ ((∀ x : a • p) ∧ (∀ x : a • q))
In order to prove this conjunction, we should prove each conjunct separately:
⌈∀ x : a • p ∧ q⌉[1] .
⌈∀ x : a • p ∧ q⌉[1] .
∀x:a•q [∧−intro] (∀ x : a • p ∧ q) ⇒ ((∀ x : a • p) ∧ (∀ x : a • q))
∀x:a•p
(∀x : a • p) ∧ (∀x : a • q) [⇒−intro[1]]
3.4 / Universal introduction and elimination 39 We shall deal with the left-hand subtree. The major connective is the universal
quantifier, so we introduce it.
⌈∀ x : a • p ∧ q⌉[1] ⌈x ∈ a⌉[2]
.
p
∀x : a • p [∀−intro[2]]
⌈∀ x : a • p ∧ q⌉[1] .
∀x : a • q [∧−intro]
(∀x : a • p) ∧ (∀x : a • q) [⇒−intro[1]]
(∀ x : a • p ∧ q) ⇒ ((∀ x : a • p) ∧ (∀ x : a • q))
We cannot work backwards any further, so now we must take advantage of our assumptions. If we eliminate the universal quantifier, we expose a useful conjunction:
⌈x ∈ a⌉[2]
⌈∀ x : a • p ∧ q⌉[1] p ∧ q
.
[∀−elim]
p
∀x : a • p [∀−intro[2]]
⌈∀ x : a • p ∧ q⌉[1] .
∀x : a • q [∧−intro]
[⇒−intro[1]]
⌈x ∈ a⌉[2]
⌈∀ x : a • p ∧ q⌉[1]
p ∧ q [∀−elim]
p [∧−elim1]
∀x : a • p [∀−intro[2]]
[∧−intro] (∀x:a•p∧q)⇒((∀x:a•p)∧(∀x:a•q)) [⇒−intro[1]]
(∀x : a • p) ∧ (∀x : a • q)
(∀ x : a • p ∧ q) ⇒ ((∀ x : a • p) ∧ (∀ x : a • q))
Now this subtree is finished, since we can use conjunction elimination to con- nect top and bottom. The right-hand subtree is symmetric with the left.
⌈x ∈ a⌉[3]
⌈∀ x : a • p ∧ q⌉[1]
p ∧ q [∀−elim]
q [∧−elim2]
∀x : a • q [∀−intro[3]]
(∀ x : a • p) ∧ (∀ x : a • q)
Example 3.18 Provided that x does not occur free in the antecedent, then we can move the universal quantifier through an implication
(∀ x : a • p ⇒ q) (p ⇒ ∀ x : a • q) provided x is not free in p
40
3 / Predicate Logic
⌈p ⇒ ∀ x : a • q⌉[4] ∀ x : a • q
A suitable proof would be:
⌈x ∈ a⌉[5]
∀x:a•p⇒q [∀−intro[5]]
[⇒−elim]
q
p ⇒ q [⇒−intro[6]]
⌈p⌉[6] [∀−elim]
⌈x ∈ a⌉[3]
(p⇒∀x:a•q)⇒(∀x:a•p⇒q) [⇒−intro[4]]
[−intro]
⌈∀ x : a • p ⇒ q⌉[1] p ⇒ q
[∀−elim] ⌈p⌉[2] ∀x:a•q [∀−intro[3]]
[⇒−elim] p⇒∀x:a•q [⇒−intro[2]]
q (∀x:a•p⇒q)⇒(p⇒∀x:a•q) [⇒−intro[1]]
(∀ x : a • p ⇒ q) (p ⇒ ∀ x : a • q)
3.5 Existential introduction and elimination
The existential quantification ∃ x : a | p • q is true if and only if there is some x in set a such that p and q are true. Of course, this object does not have to be called x; it can be any expression t such that t has a value in a and the following predicate is true:
p[t /x] ∧ q[t /x]
That is, given that we are talking about t not x, both the constraint and the quantified predicate should hold.
To introduce an existential quantifier, we must show that a suitable expres- sion t exists: we must provide an example.
t ∈ a p[t /x] q[t /x] [∃−intro] ∃x:a|p•q
As before, the expression t ∈ a means that t is a member of set a.
3.5 / Existential introduction and elimination 41
Example 3.19 With suitable assumptions about N, +, and >, we can prove that for any natural number x, there is some natural number y such that y is greater than x. We use existential introduction, choosing x + 1 as a specific value:
⌈x ∈ N⌉[1]
⌈x ∈ N⌉[1] x < x + 1 [arithmetic]
x+1∈N [arithmetic] (x
A special case of the existential-introduction rule takes expression t to be the variable x. If p and q are already true, then there is no reason to substitute another expression for x:
x ∈ a p q [∃−intro] ∃x:a|p•q
Example 3.20 If, in the course of a proof, we have established that x ∈ N and x ≥ 0, then we may apply the special case of existential-introduction and con- clude that
∃x:N•x≥0
Elimination of the existential quantifier is a more difficult affair. The pred- icate∃x:a•sstatesthatthereissomeobjectxinaforwhichsistrue. If x appears free in p then simply removing the quantifier leaves us with an un- justified statement about a free variable x. We cannot, in general, conclude p from ∃ x : a • p. To use the information contained in p, we must complete any reasoning that involves x before eliminating the quantifier.
Suppose that we assume only that x ∈ a and that p holds of x. If we are then able to derive a predicate r that does not involve x, and we know that there is some x in a for which p is true, then we may safely conclude r.
⌈x ∈ a ∧ p⌉[i]
∃ x : a • p r [i] provided x is not free in the
r [∃−elim ] assumptions, and x is not free in r
42 3 / Predicate Logic It is important that nothing is assumed about x during the derivation of r , apart
from the explicit assumption
⌈x ∈ a ∧ p⌉[i]
which states that x is in a and that p holds.
The full form of the existential-elimination rule includes the optional con-
straint part of the quantification:
⌈x ∈ a ∧ p ∧ q⌉[i] ∃ x : a | p • q r
r
[∃−elim[i]]
provided x is not free
in the assumptions, and x is not free in r
These rules are generalisations of the case analysis rule given in Chapter 2 for the elimination of the ∨ operator. For each value of x, we must show that r follows from p and q.
Example 3.21 Existential quantifiers commute. We will prove this in one direc- tion only:
(∃ x : a • ∃ y : b • p) ⇒ (∃ y : b • ∃ x : a • p) provided x is not free in b, and y is not free in a.
⌈∃ x : a • ∃ y : b • p⌉[1]
⌈∃ y : b • p⌉[2] ∃ y : b • ∃ x : a • p [∃−intro]
⌈x ∈ a⌉[2] ⌈p⌉[3]
⌈y ∈ b⌉[3] ∃ x : a • p [∃−intro]
∃y : b • ∃x : a • p [∃−elim[3]] ∃y : b • ∃x : a • p [∃−elim[2]]
(∃x:a•∃y:b•p)⇒(∃y:b•∃x:a•p) [⇒−intro[1]]
The two quantifiers are related in the same way as the propositional oper- ators they generalise. The statement ‘for some x in a, predicate p is true’ is the negation of ‘for every x in a, predicate p is false’. In terms of equivalences:
∃x:a•p ¬∀x:a•¬p ∀y:b•q ¬∃y:b•¬q
These two equivalences are generalisations of the de Morgan laws for the ∧ and ∨ operators given in Chapter 2.
3.6 / Satisfaction and validity 43
3.6 Satisfaction and validity
A predicate with free variables or ‘spaces’ is neither true nor false; it cannot be assigned a truth value until values are chosen for these variables or the spaces are filled. Some predicates will become true whatever values are chosen: these are said to be valid predicates.
Example 3.22 If n denotes a natural number, then the predicate n≥0
is valid: it will be true whichever value is chosen from the list 0, 1, 2, 3, . . .
A predicate that is true for some, but not necessarily all, choices of values is
said to be satisfiable.
Example 3.23 If n denotes a natural number, then the predicate
n≥5
is satisfiable. There are natural numbers greater than or equal to 5.
A predicate that is false for all choices is said to be unsatisfiable. Valid, satisfi- able, and unsatisfiable predicates are the analogues of tautologies, contingen- cies, and contradictions in the language of propositions.
Chapter 4
Equality and Definite Description
In this chapter we extend our language of mathematics by adding a theory of equality between expressions. The language of predicate calculus with equality is strictly more expressive than without, since it allows us to assert the identity of two objects, or to distinguish between them. We provide inference rules to support the intuitive notion that expressions which are equal may be substi- tuted one for the other, without affecting the truth of a statement, or the value of a larger expression. These rules form the basis of our theory of equality, and properties such as symmetry and transitivity can be derived from them.
The addition of equality allows us to formulate a simple rule for reasoning with quantifications: the one-point rule. We show how this rule may be used to introduce and eliminate the existential quantifier. We show also how equality may be used in statements expressing uniqueness and numerical quantity. We conclude the chapter by introducing a notation for identifying objects by using a description of their properties, rather than by referring to them by name.
4.1 Equality
The notion of equality is a familiar one: in arithmetic we learn that 1 + 1 equals 2; in the Christian religion, the 25th of December equals Christmas Day. Such statements are meant to indicate that the two expressions concerned have the same value, or that they denote the same object. In a formal description, we identify expressions using the equality symbol:
1+1 = 2, ChristmasDay = 25thDecember
We write e = f when e is identical to f , in the sense that we cannot distinguish between them.
46 4 / Equality and Definite Description Example 4.1 In an identity parade, a witness may state that ‘the man on the
right is the man who stole my idea’, making the following identification:
the man on the right = the man who stole my idea
That is, the man on the right is identical to the man who stole the idea.
The ‘=’ symbol is due to Robert Recorde, whose textbook on algebra The Whet- stone of Witte, published in 1557, used the symbol for the first time. Recorde argued that a pair of parallel lines of the same length were suitable as the sym- bol for equality ‘bicause noe 2 thynges can be moare equalle’.
We do not use equality to state that two predicates are identical: the propo- sitional connective of equivalence is reserved for that purpose. Rather, we use equality to state that two values (such as numbers) are identical. Thus, we may write 5 + 3 = 3 + 5, since both sides of the equation are expressions which denote values. These denoted values are the same, so the equality is true. Equalities form the atomic propositions in our logical language; the only other way of obtaining an atomic proposition is through set membership, described in Chapter 5.
Everything is identical to itself: thus, if t is any expression, then t is equal to t. This principle is known as the law of reflection:
t = t [eq-ref]
It should be remarked that there are logics in which this principle does not
hold. It is, however, an axiom of standard Z.
Example 4.2 In basic arithmetic, everybody knows that
1+1 = 1+1
whatever the properties of numbers and addition.
Another axiom involving equality is Leibniz’s law, or the substitution of equals: if s = t, then whatever is true of s is also true of t.
s=t p[t/x][eq-sub] p[s/x]
In fact, Leibniz (1646–1716) stated the following Principle of the Identity of Indiscernibles: s = t if and only if every property of s is a property of t, and conversely. The rule above follows from this principle.
4.1 / Equality 47 Example 4.3 If we know that Christmas Day = 25th December , and that
25th December falls on a Sunday this year
then we may apply the [eq-sub] rule and conclude that
Christmas Day falls on a Sunday this year
If two expressions e and f are not identical, then we write e ≠ f . This is simply an abbreviation for ¬(e = f ).
Example 4.4 Expressions with different properties are themselves different: p[s/x] ¬p[t/x]
s≠t
This may be proved by
¬p[t / x] [subst] ⌈s = t⌉[1] (¬p)[t /x] [eq-sub]
(¬p)[s / x] [subst] p[s/x] ¬p[s/x] [¬−elim]
false [¬−intro[1] ] ¬(s = t) [abbreviation]
Using the rules [eq-ref] and [eq-sub], we are able to establish that equality is symmetric: for any expressions s and t, if s = t, then t = s. If we let x be a fresh variable, so that x does not appear in either s or t, then we may construct the following derivation:
s≠t
t = t [eq-ref] s=t (t=x)[t/x][subst]
(t =x)[s/x] [eq-sub] t = s [subst]
Having derived this property, we may use it as a rule of inference in our natural deduction system; we will refer to it as [eq-symm].
48 4 / Equality and Definite Description Example 4.5 From the identification made in Example 4.1, we may apply the
[eq-symm] rule and conclude that:
the man who stole my idea = the man on the right
We are also able to establish that equality is transitive: for any expressions s, t and u, if s = t and t = u then s = u. Again, let x be a fresh variable:
t = u [subst] s = t (x = u)[t /x] [eq-sub]
(x=u)[s/x] [subst] s=u
Example 4.6 After the identity parade, it is revealed that the man on the right is Professor Plum, the prominent plagiarist:
the man on the right = Professor Plum
We may add this to the information in Example 4.5 and conclude that
the man who stole my idea = Professor Plum
4.2 The one-point rule
The notion of equality allows us to manipulate the existential quantifier. If the identity of a bound variable is revealed within the quantified expression, then we may replace all instances of that variable, and remove the existential quantifier. Consider the following predicate:
∃x:a•p∧x=t
This states that there is a value of x in a for which p ∧ x = t is true. If t is in a, and p holds with t substituted for x, then t is a good candidate for this value.
This is the basis of the one-point rule for the existential quantifier, which embodies the following equivalence:
(∃x : a • p ∧ x = t) t ∈ a ∧ p[t /x]
4.2 / The one-point rule 49
For this to work, x must not be free in t. If it were, then x would be bound on the left-hand side of the equivalence but free on the right. In this case, if we were to replace the left-hand side of the equivalence by the right-hand side, x would suddenly become a free variable.
The right-to-left implication is rather obvious: it relies on existential intro- duction, and the equality suggests what the term should be:
⌈t ∈ a ∧ p[t /x]⌉[1]
p[t / x] [∧−elim2] t = t [eq-ref]
⌈t ∈a∧p[t/x]⌉[1] p[t/x]∧t =t [∧−intro] t ∈ a [∧−elim1] (p ∧ x = t)[t /x] [subst]
∃x:a•p∧x=t [∃−intro] t∈a∧p[t/x]⇒(∃x:a•p∧x=t) [⇒−intro[1]]
The left-to-right direction is more interesting, since it relies on the use of exis- tential elimination. Notice that the use of this rule is sound, due to the proviso that x is not free in t.
⌈x = t⌉[2]
t = x [eq-sym]
t ∈ a
⌈∃ x : a • p ∧ x = t ⌉[1]
t ∈ a ∧ p[t / x]
⌈x = t⌉[2] t = x
[eq-sym] p[t /x]
⌈p⌉[2]
p[x / x] [subst]
[eq-sub]
⌈x ∈ a⌉[2]
t ∈ a ∧ p[t /x]
[∃−elim[2]] (∃x:a•p∧x=t)⇒t∈a∧p[t/x] [⇒−intro[1]]
[eq-sub]
[∧−intro]
So, the existential one-point rule is a derived rule in our logic:
∃x:a•p∧x=t [one-point]
t ∈ a ∧ p[t /x] provided that x is not free in t
It is particularly useful in specification: we know that some object x exists with a particular property, and we have identified x as t; this rule allows us to infer immediately that p holds of t. The fact that we have an equivalence is also very useful, in that it allows us to eliminate an existentially quantified variable without changing the strength of the predicate.
Example 4.7 The predicate ∃n:N•4+n=6∧n=2
50 4 / Equality and Definite Description is equivalent, by the one-point rule, and since n does not appear free in the
expression ‘2’, to the proposition 2∈N∧4+2=6
which is, of course, true. The predicate
∃ n : N • 6 + n = 4 ∧ n = −2
is equivalent, by the one-point rule, and since n does not appear free in the
expression ‘−2’, to the proposition −2 ∈ N ∧ 6 − 2 = 4
which is, of course, false. The predicate
∃ n : N • (∀ m : N • n > m) ∧ n = n + 1
cannot be simplified using the one-point rule, since n is free in the expression
‘n+1’.
4.3 Uniqueness and quantity
Equality can be used to make our predicate calculus more expressive, by allow- ing us to identify and distinguish objects.
Example 4.8 Let x loves y mean that x is in love with y, and let Person be the set of all people. We may symbolise the proposition ‘only Romeo loves Juliet’ using a conjunction:
Romeo loves Juliet
∧
∀ p : Person • p loves Juliet ⇒ p = Romeo
That is, any person who loves Juliet must be Romeo.
A similar technique can be used to formalise statements containing the English
phrases ‘at most’ and ‘no more than’.
Example 4.9 The statement ‘there is at most one person with whom Romeo is in love’ may be formalised as
∀ p, q : Person • Romeo loves p ∧ Romeo loves q ⇒ p = q
4.3 / Uniqueness and quantity 51 That is, if p and q are two people that Romeo loves, then they must be the same
person.
Example 4.10 The statement ‘no more than two visitors are permitted’ can be
formalised as
∀ p, q, r : Visitors • p = q ∨ q = r ∨ r = p
The notion of ‘at least one’ can be formalised using the existential quantifier.
Example 4.11 The statement ‘at least one person has applied’ could be for- malised as
∃ p : Person • p ∈ Applicants
However, to say ‘at least two’, we need equality.
Example 4.12 ‘There are at least two applicants’ may be formalised as
∃p,q : Applicants • p ≠ q
With the notions of ‘at least’ and ‘at most’, we have a method for formalising definite numerical propositions. This will be made easier later in the book when we have introduced finite sets. Then we shall be able to say, for example, that there are 29 distinct things with property p.
Example 4.13 The statement ‘there is exactly one book on my desk’ may be formalised as
∃ b : Book • b ∈ Desk ∧ (∀ c : Book | c ∈ Desk • c = b)
where ‘Book’ denotes the set of all books, and ‘x ∈ Desk’ means that ‘x is on my
desk’.
Specifying that there is exactly one object with a given property occurs so often
that there is a special notation for it: the unique quantifier. We write ∃1 x : a • p
52 4 / Equality and Definite Description
when there exists exactly one element x of set a such that p holds. This new quantifier can be defined in terms of the two forms of quantifier introduced in Chapter 3:
∃1x:a|p•q ∃x:a|p• q∧
∀y : a • p[y /x] ∧ q[y /x] ⇒ y = x
The predicate ∃1 x : a | p • q is true under two conditions: there must be an element x of a satisfying p and q and any element y of a that satisfies p and q is identical to x.
4.4 Definite description
We often use a descriptive phrase to denote an object, rather than a name. For example, when a crime has been committed, and the police have not yet learned who committed it, the tabloids are not silenced for want of a name— the individual in question is referred to as ‘the driver of the white car’ or ‘the cat in the hat’. In both of these examples, it is the word ‘the’ that is important; it is used to indicate existence and uniqueness.
Example 4.14 Each of the following phrases indicates that there is a unique object with a certain property:
• The man who shot John Lennon
• The woman who discovered radium • The oldest college in Oxford
In our mathematical language, there is a special notation for this definite de- scription of objects: the μ-notation. We write
(μx:a|p)
to denote the unique object x from a such that p.
Example 4.15 The phrases in Example 4.14 can be formalised as above:
•(μx:Person| xshotJohnLennon) • ( μ y : Person | y discovered radium )
4.4 / Definite description 53 • ( μz : Colleges | z is the oldest college in Oxford )
To say that y is equal to the expression ( μ x : a | p ) is to say that y is the unique element of a such that p holds.
Example 4.16 The statement that Marie Curie is the person who discovered radium could be formalised as
Marie Curie = ( μ y : Person | y discovered radium )
If it can be shown that there is exactly one element of Person with this property,
we may infer that
Marie Curie ∈ Person ∧ Marie Curie discovered radium
Such a statement makes sense only if there exists a unique object with the specified property. This requirement is reflected in the proof rules for the μ operator:
and
∃1x:a•p t∈a∧p[t/x] [μ-intro] t = ( μ x : a | p )
∃1x:a•p t=(μx:a|p) [μ-elim] t ∈a∧p[t/x]
providedthatxdoesnot appear free in t
providedthatxdoesnot appearfreeint
If there is a unique x from a such that p holds, and t is such an object, then we may infer that t is equal to the μ-expression ( μ x : a | p ). Conversely, if t is equal to this expression and uniqueness is guaranteed, then we may infer that t is an element of a such that p holds.
Example 4.17 The following proposition states that 2 is the natural number that yields a result of 6 when added to 4:
2=(μn:N|4+n=6) It may be proved by
∃1n:N•4+n=6 [arithmetic] 2∈N∧4+2=6 [arithmetic] 2=(μn:N|4+n=6) [defdesc]
54 4 / Equality and Definite Description In both left and right subtrees, the required result follows from the properties
ofNand+.
To prove that an object is not equal to a given μ-expression we must show that
the μ-expression denotes a unique object, and that this isn’t it.
Example 4.18 The following proposition states that 3 is not the natural number
that yields a result of 6 when added to 4: 3≠(μn:N|4+n=6)
It may be proved by
∃1n:N•4+n=6 [arithmetic] ⌈3=(μn:N|4+n=6)⌉[1] ∃n:N|4+n=6•3=n [μ-elim]
3∈N∧4+3=6 [one-point] 4 + 3 = 6 [∧−elim2] false [arithmetic]
3≠(μn:N|4+n=6) [¬−intro[1]]
If there is no unique object with the specified property, then our attempts at
proving equality may fail.
Example 4.19 The following proposition states that 1 is the unique natural number that satisfies n = n + 0:
1=(μn:N|n=n+0)
There is no unique number with this property—every number has it—so we should not be surprised if we encounter problems during the proof.
An application of the μ-introduction rule leaves us with two subtrees to investigate:
∃1n:N•n=n+0 1∈N∧1=1+0 [μ-intro] 1=(μn:N|n=n+0)
The right-hand subtree seems quite easy to prove, but the left-hand one is im- possible. At this point, we might decide that our proposition is false, and at-
4.4 / Definite description 55 tempt to prove its negation.
∃1n:N•n=n+0 ⌈1=(μn:N|n=n+0)⌉[1]
. [μ-elim]
.
false [¬−intro[1] ]
1≠(μn:N|n=n+0)
This proof is also problematic: we must derive a contradiction, and the only
assumption that we have is that
1=(μn:N|n=n+0)
We cannot use this assumption unless we prove that
∃1 n : N • n = n + 0
which is not true, and even if we could, it would be no use, since it does not
lead to a contradiction. In conclusion, we cannot prove that
1=(μn:N|n=n+0)
nor can we prove its negation. In this respect, our proof system is incomplete, and deliberately so.
There is no unique number n which has the property that n = n + 0, there are many; we refer to the descriptive phrase
(μn:N|n=n+0)
as being improper. We do not know what value it has, and we can prove very
little about it.
Example 4.20 The following proposition states that 1 is the unique natural
number which is equal to its own successor:
1=(μn:N|n=n+1)
No natural number has this property, and our attempts to prove this proposi-
tion or its negation will fail.
Sometimes we wish to refer not to the unique object with some property, but to some object or expression associated with it. A more general form of μ-expression allows this: we write
(μx:a|p•e)
56 4 / Equality and Definite Description to denote the expression e such that there is a unique x from a satisfying p.
Example 4.21 The date upon which University College, Oxford, was founded might be given by the expression:
( μ z : Colleges | z is the oldest in Oxford • date of foundation(z) )
The proof rules for this form of definite description are simple generalisations of those given above:
and
∃1x:a•p ∃x:a|p•t=e [defdesc] t = ( μ x : a | p • e )
∃1x:a•p t=(μx:a|p•e) [defdesc] ∃ x : a | p • t = e
providedthatxdoesnot appear free in t
providedthatxdoesnot appear free in t
Notice that since the object x is unique, so too is the value of the expression e.
Chapter 5
Sets
Mathematical objects are often seen as collections of other objects: a square is a collection of points in a plane; a function is a collection of pairs linking arguments with values. These collections are called sets, and their theory is a fundamental part of mathematics. As mathematics forms the basis of modern software engineering, we should not be surprised to find that sets are important to our understanding of formal specification and design.
The Z notation is based upon set theory; specifications in Z find their mean- ings as operations upon sets. In this chapter, we present the foundations of elementary set theory: the notions of set membership, extension, and compre- hension; the power set and Cartesian product constructors. This will be all the set theory we require for specification, refinement, and proof in Z.
At the end of the chapter we will introduce a system of types based upon maximal sets, a system used throughout the rest of the book. This will help us to ensure that expressions and variables are used consistently within a spec- ification, and will also ensure that our formal language does not support the definition of paradoxical sets such as those of Cantor and Russell.
5.1 Membership and extension
Intuitively, a set is any well-defined collection of objects; what we mean by ‘well- defined’ will be explained later. The objects in a set can be anything—numbers, people, letters, days—they may even be sets themselves.
Example5.1 Thefollowingareallexamplesofsets: • the four oceans of the world
58 5 / Sets
• the individuals who have been appointed to the post of secretary-general
of the United Nations
• the passwords that may be generated using eight lower-case letters
• the prime numbers
• the collection of programs written in C++ that halt if run for a sufficient time on a computer with unlimited storage
We impose no restriction upon the number of elements that there may be in a set. Neither do we insist upon an effective procedure for deciding whether an arbitrary object is a member; the collection of programs in the last example is a set, although no algorithm can determine whether or not an arbitrary program will halt.
If a set is sufficiently small, we may define it by extension. To do this, we produce a list of its elements; a set s containing three elements a, b, and c could be defined by
s == {a,b,c}
Whenever we write out a set in such an explicit fashion, we use commas to separate the elements of the list, and braces to mark the beginning and end. The notation n == e means that n is by definition a name for, and hence equal to, the expression e. We say that n is a syntactic abbreviation for e. This notation is fully explained in Chapter 6.
Example 5.2 The first two sets in Example 5.1 can be defined by extension:
Oceans == {Atlantic, Arctic, Indian, Pacific} Secretaries-General == { Trygve Lie, Dag Hammarskjöld, U Thant,
Kurt Waldheim, Javier Pérez de Cuéllar, Boutros Boutros Ghali, Kofi Annan }
We write x ∈ s to indicate that object x is an element of set s. This is pronounced ‘x belongs to s’, or ‘x is in s’. If x is not a member of s, then we write x ̸∈ s: clearly,
x̸∈s ¬(x∈s)
5.1 / Membership and extension 59 Example 5.3 If Primes denotes the set of all prime numbers, then the following
propositions are true:
3 ∈ Primes 5 ∈ Primes 8 ̸∈ Primes
The idea of set membership allows us to characterise equality between sets. Two sets s and t are equal if and only if they have the same elements: that is, every member of s is also a member of t and every member of t is also a member of s.
(∀x:t•x∈u)∧(∀x:u•x∈t) [ext] providedthatxis
t = u free in neither u nor t
This rule expresses an equivalence known as the axiom of extension, one of the axioms of Zermelo–Fraenkel set theory—the variety of set theory upon which the Z notation is based.
An expression belongs to a set described in extension if and only if it is equal to one of the set’s elements:
t =u1 ∨…∨t =un [ext−mem] t ∈ {u1,…,un}
Again, an inference can be made in both directions. Used in conjunction with the axiom of extension, this rule allows us to discover an important property of sets: that the order and multiplicity of listed elements is unimportant.
Example 5.4 If we define s == {2,2,5,5,3}
t == {2,3,5} then
s=t
That is, the list expressions used to define s and t denote the same set.
60
5 / Sets
This may be proved using the two inference rules given above:
⌈x ∈ t⌉[2]
x ∈ {2,3,5} [eq−sub]
⌈x ∈ s⌉[1]
x ∈ {2,2,5,5,3} [eq−sub]
x =2∨x =3∨x =5 [ext−mem] x ∈ {2, 3, 5} [ext−mem]
x =2∨x =3∨x =5 [ext−mem] x ∈ {2, 2, 5, 5, 3} [ext−mem]
x ∈ s [eq−sub] ∀x :t •x ∈s [∀−intro[2]]
(∀x : s • x ∈ t) ∧ (∀x : t • x ∈ s) [∧−intro] s = t [ext]
x ∈ t [eq−sub] ∀x :s •x ∈t [∀−intro[1]]
Notice that, having defined s and t through syntactic abbreviations, we are able to assume that they are equal and substitute accordingly.
Some sets are so useful that they are given special names, and regarded as permanent features of our formal language: one such set is N, the set of all natural numbers:
N = {0,1,2,3,4,5,…}
This is not a formal definition of the set N; such a definition is provided later in the book: see Example 6.8.
Another useful set is the set with no elements: the empty set. We write ∅ to denote such a set.
Example 5.5 If we let Rockallers be the set of people who live and work on Rockall, a small uninhabited island in the Atlantic Ocean, then
Rockallers = ∅
Another axiom of Zermelo–Fraenkel set theory states that the empty set exists, and has no elements:
∀x:a•x̸∈∅ [empty]
Whatever set a that we consider, none of the values x in a will appear in the empty set.
5.2 / Set comprehension 61 Example 5.6 Any universal quantification over the empty set is valid: that is,
∀x : ∅ • p. This follows from the empty set axiom, with a as ∅: ⌈x∈∅⌉[1] ∀x:∅•x̸∈∅ [empty]
⌈x ∈ ∅⌉[1]
¬ (x ∈ ∅) [∀−elim] [¬−elim]
false
p [false−elim]
∀x:∅•p [∀−intro[1]]
We may generalise our notion of set equality to allow us to compare two sets containing the same kind of objects. If every element from set s is also present in set t, we say that s is a subset of t, written s ⊆ t.
Example 5.7 Let Benelux denote the set of countries in the Benelux economic union, and let Europe denote the set of all countries in the European Union. Since the formation of the EU, it has been true that Benelux ⊆ Europe. There were other partners when the EU (then the EEC) was formed in 1957, so it is also true that ¬(Europe ⊆ Benelux).
We may prove that one set is a subset of another by establishing a universal quantification:
∀x:s•x∈t [subset] providedthatx s ⊆ t is not free in t
This rule may be used in both directions; it is easy to establish that
s⊆t∧t⊆ss=t
Ifs isasubsetoft andt isasubsetofs,thens andt arethesameset.
5.2 Set comprehension
Given any non-empty set s, we can define a new set by considering only those elements of s that satisfy some property p. This method of definition is called comprehension. We write
{x:s|p}
to denote the set of elements x in s that satisfy predicate p.
62 5 / Sets
Example 5.8 Suppose that a red car is seen driving away from the scene of a crime. In this case, the authorities might wish to talk to anyone who owns such a vehicle. If Person denotes the set of all people, then the set to consider is given by
{x : Person | x drives a red car}
A simple comprehension term { x : s | p } has two parts: a declaration part x : s and a predicate part p. The declaration part may be seen as a generator, providing a range s of possible values for x; the predicate part may be seen as a filter, picking out only those values of x that satisfy p.
It may be that we are interested in some expression formed from the values satisfying the predicate, and not in the values themselves. In this case, we add a term part to our set comprehension: we write
{x:s|p•e}
to denote the set of all expressions e such that x is drawn from s and satisfies
p. The expression e will usually involve one or more free occurrences of x. Example 5.9 In order to pursue their investigation of the crime, the authorities
require a set of addresses to visit. This set is given by
{x : Person | x drives a red car • address(x)}
If we have no restrictions upon the choice of values, we can still use a set comprehension to generate a set of expressions: we write
{x:s•e}
to denote the set of all expressions e such that x is drawn from s.
Example 5.10 Without the information that a red car was involved, the author- ities would be left with the following set of addresses:
{ x : Person • address(x) }
This set contains every address associated with an element of Person.
5.2 / Set comprehension 63
We may treat the short forms of comprehension as abbreviations. A compre- hension without a term part is equivalent to one in which the term is the same as the bound variable:
{x:s|p} = {x:s|p•x}
Similarly, a comprehension without a predicate part is equivalent to one with
the predicate true:
{x :s •e} = {x :s |true•e}
as the predicate true places no restriction upon the choice of values.
The declaration part of a comprehension may introduce more than one
variable: we write
{ x : a; y : b | p • e }
to denote the set of expressions e formed as x and y range over a and b, re-
spectively, and satisfy predicate p.
Example5.11 Aneyewitnessaccounthasestablishedthatthedriverofthered car had an accomplice, and that this accomplice left a copy of the Daily Mail at the scene. The authorities are now interested in tracing the following set of potential criminals:
{x : Person; y : Person | x is associated with y ∧ x drives a red car ∧
y reads the Daily Mail • x }
The variables declared in a set comprehension are bound in the same way as variables declared in a quantified expression. We may change their names provided that we choose names that are not already used in the comprehension.
Example 5.12 There is nothing special about the names chosen for the driver and his or her accomplice. The set in Example 5.11 could equally well have been written as
{v : Person; w : Person | v is associated with w ∧ v drives a red car ∧
w reads the Daily Mail • v }
64 5 / Sets If a set a has been defined by comprehension, then expression f is an
element of a if and only if there is some expression e in a such that e = f . ∃x:s|p•e=f [compre] providedthatx
f ∈{x:s|p•e} isnotfreeinf
Our use of this inference rule is supported by two axioms of Zermelo–Fraenkel set theory: the axiom of specification justifies the predicate part; the axiom of replacement justifies the term.
The one-point rule of Chapter 4 leads to a pair of derived rules for set comprehensions without a term part:
and
f ∈ s p[f / x] [compre−s] f ∈{x:s|p}
f ∈{x:s|p} [compre−s] f ∈s∧p[f/x]
provided that x isnotfreeinf
providedthatx isnotfreeinf
Example 5.13 If we replace the predicate part of a set comprehension with a weaker condition, then we obtain a larger set.
∀x:a•p⇒q {x:a|p}⊆{x:a|q}
This may be proved by
⌈y ∈ { x : a | p }⌉[1]
y ∈ a ∧ p[y/x] [compre−s]
y ∈ a
y ∈ a [∧−elim1]
y∈{x:a|q} [compre−s]
∀y:{x:a|p}•y∈{x:a|q} [∀−intro[1]] {x:a|p}⊆{x:a|q} [subset]
⌈y ∈ { x : a | p }⌉[1]
[∧−elim1]
y ∈ a ∧ p[y/x] p [y /x ]
[compre−s] [∧−elim2]
∀x:a•p⇒q p[y/x] ⇒ q[y/x]
[∀−elim] q[y/x]
[⇒−elim]
⌈y ∈ { x : a | p }⌉[1]
y ∈ a ∧ p[y/x] [compre−s]
5.3 / Power sets 65
5.3 Power sets
If a is a set, then the set of all subsets of a is called the power set of a, and written P a. For example, if a is the set {x, y} then
Pa = {∅,{x},{y},{x,y}}
This new set has four elements: the empty set, the set a itself, and the two other subsets of a. In general, if a set a has n elements, then the power set P a has 2n.
Example 5.14 Four friends have been invited to dinner: Alice, Bill, Claire, and David. If their names are abbreviated to A, B, C, and D, then the set of people that actually arrive will be an element of the power set
P{A,B,C,D} = {∅,{A},{B},{C},{D},{A,B},{A,C},{A,D}, {B, C}, {B, D}, {C, D}, {A, B, C}, {A, B, D},
{A,C,D},{B,C,D},{A,B,C,D}}
A set s belongs to the power set of a if and only if s is a subset of a:
s ⊆ a [power] s∈Pa
This inference rule corresponds to the power set axiom of Zermelo-Fraenkel set theory, which states that a power set exists for any set a.
Example 5.15 For any set a, the empty set is an element of P a: ∅∈Pa
This follows from the result of Example 5.6, that any universal quantification over the empty set is valid:
∀x:∅•x∈a [Example5.6] ∅ ⊆ a [subset]
∅∈Pa [power]
66 5 / Sets The Z notation has a second power set symbol; we write F a to denote the set
of finite subsets of a; this symbol is defined in Chapter 8. 5.4 Cartesian products
In a formal description of a software system, we may wish to associate objects of different kinds: names; numbers; various forms of composite data. We may also wish to associate two or more objects of the same kind, respecting order and multiplicity. To support this structuring of information, the Z notation includes Cartesian products. These are sets of tuples: ordered lists of elements, one drawn from each of the component sets.
If a and b are sets, then the Cartesian product a × b consists of all tuples of the form (x, y), where x is an element of a and y is an element of b. A tuple with exactly two elements is called an ordered pair; a tuple with exactly n elements, where n is greater than 2, is called an n-tuple.
Example5.16 InthegameofCluedoTM,itisassumedthatamurderhasbeen committed. The players are then invited to guess the identity of the person responsible, the room in which the crime was committed, and the weapon used. If we define the set of guests, the set of locations, and the set of potential weapons,
Guests == { Mrs Peacock, Miss Scarlett, Reverend Green, Mrs White, Colonel Mustard , Professor Plum }
Rooms == { Library, Study, Lounge, Hall, Kitchen,
Billiard Room, Ballroom, Conservatory , Dining Room }
Weapons == { Rope, Dagger , Revolver , Candlestick , Lead Pipe, Spanner }
then the set of possible solutions is given by the Cartesian product:
Guests × Rooms × Weapons and a typical guess would be
(Colonel Mustard , Library , Revolver )
It was Colonel Mustard, in the library, with the revolver.
5.4 / Cartesian products 67 An n-tuple (x1,…,xn) is present in the Cartesian product a1 × … × an if
and only if each element xi is an element of the corresponding set ai . x1 ∈a1 ∧…∧xn ∈an [cart−mem]
(x1,…,xn)∈a1 ×…×an
In the case where n = 2, this rule expresses the following equivalence:
(x , y ) ∈ a × b x ∈ a ∧ y ∈ b
The ordered pair (x, y) is an element of the product set a × b if and only if x is in a and y is in b.
The order of components in a Cartesian product is important: if a and b are different sets, then a × b ≠ b × a. A similar consideration applies to the elements of a product set: two tuples are the same if and only if they agree in every component:
x1 =y1 ∧…∧xn =yn [cart−eq] (x1,…,xn) = (y1,…,yn)
To refer to a particular component of a tuple t, we use a projection notation: the first component of the tuple is written t.1; the second component t.2, and so on.
t.1 = x1 ∧ … ∧ t.n = xn [cart−proj] t = (x1,…,xn)
Example 5.17 If guess is an element of Guests × Rooms × Weapons, then
• guess.1 is the name of the murderer • guess.2 is the suggested location
• guess.3 is the weapon used
If guess is the tuple (Colonel Mustard , Library , Revolver ) then these would be Colonel Mustard, Library, and Revolver, respectively.
The product set is so called because the size of the set a × b is the product of the size of a and the size of b.
Example 5.18 There are 6 guests, 9 rooms, and 6 weapons in CluedoTM. There are 6×9×6 = 324 elements in the set
Guests × Rooms × Weapons
68 5 / Sets There are 324 possible solutions to the mystery.
5.5 Union, intersection, and difference
If a and b are sets, then we write a ∪ b to denote the union of a and b; this is the smallest set that contains all of the elements of a and b.
x ∈ (a ∪ b) [union] x∈a∨x∈b
We may generalise the union operator as follows: if s is a set of sets {a, b, c, . . .} then we write s to denote the smallest set containing all of the elements that appear in at least one of a, b, c, …
x∈s [Union] ∃a:s•x∈a
The union axiom of Zermelo–Fraenkel set theory guarantees the existence of s for any set of sets s.
Example5.19 Edward,Fleur,andGarethhaveeachbeengivenanassignment consisting of 7 questions. Edward has attempted the questions numbered 1, 2, and 4; Fleur has attempted all but questions 5 and 6; Gareth has attempted only those questions with even numbers. We may record this information as follows:
E == {1, 2, 4}
F == {1,2,3,4,7}
G == {2,4,6}
We may discover which questions have been attempted by examining the union
of these three sets:
{E,F,G} = {1,2,3,4,6,7}
This is the set of numbers n such that question n was attempted by at least one
of the three.
We write a ∩ b to denote the intersection of two sets a and b ; this is the set that
contains only those elements that are common to a and b.
x ∈ (a ∩ b) [inter] x∈a∧x∈b
5.6 / Types 69
We may generalise the intersection operator as follows: if s is a set of sets {a, b, c, . . .}, then s denotes the set containing only those elements that appear in every one of a, b, c, …
x∈s [Inter] ∀a:s•x∈a
If s is the empty set of sets, then the universal quantification above will be true for any x ; the set ∅ contains all of the elements of the appropriate type: see Section 5.6.
Example 5.20 Using the information of Example 5.19, we may discover which questions were attempted by all three students by examining the intersection
{E,F,G} = {2,4}
This is the set of numbers n such that question n was attempted by every one
of the three.
If a and b are sets, then we write a \ b to denote the set difference a minus b;
this is the set containing only those elements that appear in a but not in b. x∈(a\b) [diff]
x ∈ a ∧ x ̸∈ b
Example 5.21 The set of questions which have been attempted by both Edward and Fleur, but have not been attempted by Gareth, is given by
(E∩F)\G = {1}
and the set of questions attempted by Fleur alone is given by
F\(E∪G) = {3,7}
5.6 Types
When people use set theory to specify software systems, they often include some notion of types. In Z, this notion is a simple one: a type is a maximal set,
70 5 / Sets
at least within the confines of the current specification. This has the effect of ensuring that each value x in a specification is associated with exactly one type: the largest set s present for which x ∈ s.
The Z notation has a single built-in type: the set of all integers Z. Any other types will be constructed from Z, or from basic types of values. A basic type is a set whose internal structure is invisible. We may introduce elements of such a set, and associate properties with them, but we can assume nothing about the set itself.
Example 5.22 A computer system used by the United States Immigration Ser- vice might store information about foreign nationals presently in the United States. In a specification of this system, the set of all people would be a good choice for a basic type. The set of all UK nationals would be a poor choice, as we are likely to consider supersets of this set.
Additional types can be created using the power set constructor P and the Cartesian product ×. If T is a type, then the power set P T is the type of all subsets of T. If T and U are types, then T × U is the type of all pairs formed from elements of T and elements of U .
Example 5.23 The power set P Z is the type of all sets of integers, {1,2,3} ∈ PZ
while the Cartesian product Z × Z is the type of all number pairs: (1, 2) ∈ Z × Z
The fact that each value in a specification is associated with exactly one type is most useful. We can apply type-checking algorithms to the mathematical text of a Z document to reveal any inconsistencies in the use of variable names and expressions. Such algorithms can verify neither the interpretation of these names nor the inferences made using them, but they are a powerful means of increasing confidence in a formal specification.
Our use of types imposes restrictions upon the ways in which we may de- fine and use sets. For example, the statement x ∈ s is valid only if the type of s is the power set of the type of x. If this is not the case, then the state- ment is meaningless and cannot be used in specifications. Such restrictions are welcome, in that they help us to avoid certain forms of logical paradox.
Example 5.24 Suppose that types were not important in the use of ∈. In this case, we could define R, the set of sets of some type T that are not members of
5.6 / Types 71 themselves:
R == {s : T | ¬ s ∈ s}
We would then be faced with a logical paradox.
R∈T ∧¬(R∈R) [compre−s] R∈{s:T |¬s∈s} [definitionofR]
R∈R
The set R is an element of itself if it isn’t an element of itself, and vice versa; to define R would be to introduce a contradiction into our specification.
Chapter 6
Definitions
A formal specification should contain a significant amount of prose; this should relate the mathematical objects to features of the design: system states, data structures, properties, and operations. Of course, if the statements in the math- ematics are to be meaningful, then we must ensure that the objects concerned are properly defined.
In the Z notation, there are several ways of defining an object. We may simply declare, we may define by abbreviation, or we may define by axiom. In addition, there are special mechanisms for free types and schemas, discussed later in the book. In this chapter, we explain the use of declarations, abbrevia- tions, and axiomatic definitions. We also present rules for reasoning with the information that they contain.
6.1 Declarations
The simplest way to define an object is to declare it. If the object is a given set, or basic type, then we do this by writing its name between brackets: for example, the declaration
[Type]
introduces a new basic type called Type. If the object is a variable, then we give
the name of a set that it comes from. The declaration
x:A
introduces a new variable x, drawn from the set A. If this set is not Z, the type of integers, then it must be defined elsewhere in the specification.
74 6 / Definitions
Example 6.1 A hotel switchboard uses a software package to maintain a record of call charges to current guests. A formal specification of this system could include the declaration
[Guest , Room]
introducing two basic types to represent the set of all guests and the set of all
rooms. A variable of the type Guest is introduced by the following declaration: x : Guest
A declaration of the form x : t, where t is a type, is called a signature: it makes explicit the underlying type of the object being introduced. Any other declaration may be replaced by a signature and a constraint, the constraint defining the subset of the underlying type that the object is drawn from. If the declaration is local—part of a set comprehension, quantification, or μ- expression—then the constraint follows a vertical bar:
x:t|x∈s
If the declaration is global—introducing a constant that may be used throughout
the specification—then an axiomatic definition is required: see Section 6.4. 6.2 Abbreviations
Another way to define an object is to exhibit an existing object and state that the two are the same. The abbreviation definition
symbol == term
introduces a new name for term, a mathematical object that must be defined elsewhere in the specification. The new name symbol is a global constant of the specification, with the same type and value as the expression term.
Example6.2 Theabbreviationdefinition Additive == {red,green,blue}
introduces a set Additive, as another name for the set described in enumeration above. The names red, green, and blue must be defined elsewhere, they are not introduced by the abbreviation. If they are declared as elements of a type Colours, then Additive is a constant of type P Colours.
6.3 / Generic abbreviations 75
Any symbol defined by abbreviation may be eliminated from a specification by replacing each instance with the expression on the right of the definition. Accordingly, the notation may not be used to make recursive definitions.
Example 6.3 The recursive acronym gnu could not be defined using the abbre- viation notation:
gnu == gnu′s not unix
This is not a valid abbreviation, as gnu appears also on the right.
An abbreviation definition is quite benign: it asserts nothing, it simply provides a more convenient way of referring to something that is already defined.
Example 6.4 Given the basic type Person, representing the set of all people, we may introduce abbreviations for the set of all people who take sugar in tea:
English == {p : Person | p drinks tea ∧ p takes sugar} and the set of all people who put salt on their porridge:
Scots == {q : Person | q eats porridge ∧ q adds salt}
Provided that the constraining predicates are properly introduced, the two sets
above are bound to be well defined. 6.3 Generic abbreviations
In the course of a formal specification, we may wish to define a family of sym- bols, one for each value of a particular index or parameter. Rather than present a series of similar definitions, we employ a generic form of abbreviation:
symbol parameters == term
This defines a global constant symbol parameterised by a list of sets, each of which may appear in the expression term.
The simplest example is the definition of the empty set symbol ∅. In a Z specification, there may be many empty sets, one for each type. We must distinguish between empty sets of different types; no expression can have a value that belongs to more than one type. To define the empty set of objects from a set S, we write
∅[S] == {x:S|false}
76 6 / Definitions
The generic parameter S may be any set, although in the case of ∅, it is likely to be a type. The parameter list may be enclosed in brackets, as above, or omitted altogether where the values chosen are obvious from the context.
Example6.5 ForanysetT,wemaydefinethesetofallnon-emptysubsetsof T as follows:
P1 T == { a : P T | a ≠ ∅ }
We are happy to omit the brackets from the parameter list in the definition and
in instantiations:
P1{0, 1} = {{0}, {1}, {0, 1}}
A second generic symbol appears in the definition above: the ∅ symbol. From
the context, it is clear that this denotes the empty set of elements from T . For the convenience of the reader, we allow the definition of infix generic
symbols. The abbreviation
parameters symbol parameters == term
defines a global constant symbol which may appear inside a list of parameters.
Example 6.6 We may define a generic symbol rel such that, for any sets s and t, the set s rel t is the power set of s × t:
srelt == P(s×t)
Each element of s rel t is a set of pairs; the first component of each pair is an
element of s; the second is an element of t.
Once an abbreviation definition has been made, we may conclude that the symbol on the left is equal to the term on the right. Each abbreviation adds an inference rule to our specification:
s = e [abbrev] given the abbreviation s == e
A generic abbreviation adds a family of rules, one for each instantiation.
Example 6.7 From the definition of the empty set symbol given in the text, we may establish that, for any number n in N, n is not an element of the empty set of
6.4 / Axiomatic definitions 77 numbers.
⌈n ∈ ∅[N]⌉[2] n∈{n:N|false} [eq-sub]
n ∈ N ∧ false [compre-s] false [∧−elim2]
n ̸∈ ∅[N] [¬−intro[2]]
∀n:N•n̸∈∅[N] [∀−intro[1]]
6.4
Axiomatic definitions
A third form of definition includes a constraint upon the object being intro- duced. Such definitions are said to be axiomatic, as the constraint is assumed to hold whenever the symbol is used: it is an axiom for the object. In the Z notation, an axiomatic definition takes the form
declaration predicate
where the predicate expresses the constraints upon the object or objects intro- duced in the declaration.
The definition
x:s p
introduces a new symbol x, an element of s, satisfying predicate p. The pred- icate part of the definition may place constraints upon the values that x can take; it may even constrain x to the point where there is only one object that x can denote.
Example 6.8 We may use an axiomatic definition to define the set of natural numbers:
N:PZ ∀z:Z•z∈Nz≥0
78 6 / Definitions
This introduces a new object N, a subset of Z, containing only those integers that are greater than or equal to zero. There is exactly one subset of Z with this property.
If this is not the case, if there are several values of the underlying type that meet the constraints, then we say that the definition is loose.
Example 6.9 We may define a constant maxsize as follows: maxsize : N
maxsize > 0
That is, maxsize is a natural number, and it is strictly greater than zero.
The declaration and predicate parts of an axiomatic definition may be used to support reasoning about the symbol they define. If the symbol x is intro- duced as above, then we are free to apply the inference rule:
x ∈s ∧p [axdef]
There will be a rule like this for each axiomatic declaration.
Example 6.10 The definition of maxsize can be used to establish the truth of the following predicate:
∃ n : N • n = maxsize − 1 The proof is as follows:
maxsize ∈ N ∧ maxsize > 0 [axdef] maxsize > 0 [∧−elim2] maxsize ≥ 1 [arith]
maxsize − 1 ≥ 0 [arith] maxsize − 1 ∈ N [arith]
∃n:N•n=maxsize−1 [one-point]
We must take care that our axiomatic definitions do not introduce incon- sistencies into a specification. Such a definition asserts that some object exists with the stated property; this may contradict other parts of the specification, or even well-known mathematical results.
6.5 / Generic definitions 79 Example 6.11 If Primes has been defined as the set of all prime numbers, then
we may define maxprime, the largest prime number, as follows: maxprime : N
∀ p : Primes • maxprime ≥ p
This would be an unfortunate definition, as it can be shown that such a number
cannot exist.
In some cases, we may wish to precede an axiomatic definition with a proof of existence: a proof of ∃x : s • p.
If the predicate part of an axiomatic definition is true, then it may be omit- ted, leaving a definition of the form
x:s
This is a declaration of a global constant x; it introduces a corresponding infer-
ence rule into the current specification:
x ∈ s [axdef]
Such a definition may still be contradictory: the set s may be empty.
6.5 Generic definitions
A generic form of axiomatic definition may be used to define a family of global constants, parameterised by some set X . The definition
[X] x:X
p
introduces a generic constant x of type X , satisfying predicate p. The set X is a formal parameter; it can be regarded as a basic type whose scope is the body of the definition.
Any value given to this parameter when the definition is used must be of set type. As in the case of generic abbreviations, the actual parameter list may be enclosed in brackets, or omitted altogether when the instantiation is obvious from the context.
80 6 / Definitions Example6.12 Thegenericnon-emptypowersetconstructordefinedusingan
abbreviation in Example 6.5 may also be defined using a generic definition: [X]
P1 : P(P X )
P1 ={s:PX |s≠∅}
In applications, the brackets around the generic parameter are optional: the forms P1[s] and P1 s are equally acceptable.
Example 6.13 We can use a generic definition to define the subset symbol: [X]
⊆ :PX↔PX ∀s,t : PX •
s⊆t∀x:X•x∈s⇒x∈t
The ⊆ symbol denotes a relation between two sets of the same type P X (re- lations are mathematical objects discussed in Chapter 7). In applications, we omit the parameter list altogether:
{2,3} ⊆ {1,2,3,4}
The rule for introducing facts about a generic definition is similar to that for axiomatic ones, with the obvious addition of a mechanism for instantiating parameters. In the general case, if S is an expression including X —P X , for example—and the specification contains the declaration
[X] x:S
p
then we may apply the following rule:
(x ∈ S ∧ p)[t,x[t]/X,x] [gendef]
where t is the value being given to the formal generic parameter X . Again, this is a family of inference rules, for each definition in the specification, and for each possible instantiation of X .
6.6 / Sets and predicates 81 Example 6.14 The definition of P1 in Example 6.12 gives us the property of its
declaration and its axiom; we can use the latter to prove that
∅[N] ∉ P1[N]
A suitable proof of this result might be
P1[N]∈P(PN)∧P1[N]={s:PN|s≠∅[N]} [gendef]
P1[N] = {s : PN | s ≠ ∅[N]} [∧−elim2]
{s : PN | s ≠ ∅[N]} = P1[N] [eq-symm] ⌈∅[N] ∈ P1[N]⌉[1]
[eq-sub]
∅[N] ∈ { s : P N | s ≠ ∅[N] }
∅[N] ∈ P N ∧ ∅[N] ≠ ∅[N] [compre-s]
∅[N] = ∅[N] [eq-ref] false
∅[N] ∉ P1[N]
∅[N] ≠ ∅[N] [¬−intro[1] ]
[∧−elim2] [¬−elim]
6.6 Sets and predicates
All of the objects that we define in Z are sets of one kind or another. A reader with some experience of mathematical logic might be excused for asking: how do we define a predicate symbol? How do we introduce a symbol such as good, so that good x is true for some values of x and false for others? The answer is simple: we define a predicate in terms of the set of objects that satisfy it.
If p is a predicate with a free variable x of type t, and c={x:t|p}
then we say that c is the characteristic set of p: it is the set of values of x for which p is true.
If we wished to define a predicate good, then we could define it as a set of values:
good : P t …
We can now write x ∈ good to represent the statement ‘x is good’.
82 6 / Definitions Example 6.15 We wish to formalise the predicate ‘is a crowd’ upon sets of peo-
ple. To do this, we introduce a set of sets:
crowds : P(P Person)
crowds = { s : P Person | #s ≥ 3 }
The expression ‘#s’ denotes the number of elements in set s—it is defined for- mally in Section 8.6. With this definition of crowds, we may make statements such as
{Alice, Bill , Claire} ∈ crowds and
{Dave,Edward} ∈ crowds
The first of these propositions is true, the second is false.
It is sometimes convenient to treat the name of a set as a unary operator: in this case, the definition will include an underscore to indicate the position of the argument.
Example 6.16 For a number of reasons, it is not a good idea to have Alice and Bill in the room at the same time. Thus, a set of people is safe if it contains Alice, or Bill, or neither, but not both. We may define safe as a property of sets of people:
safe : P(P Person)
∀s : PPerson • safe s ¬({Alice,Bill} ⊆ s)
We treat safe s as an abbreviation of s ∈ safe. We are then free to decide the truth of such statements as
safe {Alice, Claire, Dave} and
¬ (safe {Alice,Bill,Edward})
Chapter 7
Relations
In a formal specification, it is often necessary to describe relationships between objects: this record is stored under that key; this input channel is connected to that output channel; this action takes priority over that one. These rela- tionships, and others like them, can be described using simple mathematical objects called relations.
In this chapter, we explain how to define relations, and how to extract information from them. We explain that relations may be classified: as homo- geneous or heterogeneous; as reflexive, symmetric, or transitive. We describe how relations may be inverted or composed to form new objects, and explain what these objects represent.
7.1 Binary relations
Although we may define relations that express links between any finite number of objects, it is enough to employ binary relations: relations that express links between pairs of objects. In our mathematical language, a relation is a set of ordered pairs, a subset of a Cartesian product.
If X and Y are sets, then X ↔ Y denotes the set of all relations between X and Y . The relation symbol may be defined by generic abbreviation:
X↔Y == P(X×Y)
Any element of X ↔ Y is a set of ordered pairs in which the first element is drawn from X , and the second from Y : that is, a subset of the Cartesian product set X × Y .
84 7 / Relations Example 7.1 The set of relations {a, b} ↔ {0, 1} is the set of sets of pairs
{∅, {(a, 0)}, {(a, 1)}, {(b, 0)}, {(b, 1)}, {(a, 0), (a, 1)}, {(a, 0), (b, 0)}, {(a, 0), (b, 1)}, {(a, 1), (b, 0)}, {(a, 1), (b, 1)}, {(b, 0), (b, 1)},
{(a, 0), (a, 1), (b, 0)}, {(a, 0), (a, 1), (b, 1)}, {(a, 0), (b, 0), (b, 1)}, {(a, 1), (b, 0), (b, 1)}, {(a, 0), (a, 1), (b, 0), (b, 1)}}
A typical element of this set is {(a, 0), (a, 1), (b, 0)}: the relation that associates a with 0, a with 1, and b with 0.
Where ordered pairs are being used as elements of relations, we will often write them using a maplet notation. The expression x y is another way of writing (x,y).
Example7.2 Therelationdrivesisusedtorecordwhichmakesofcararedriven by the members of a small group of people. If the group of people is defined by
Drivers == {helen,indra,jim,kate} and the choice of cars is defined by
Cars == {alfa,beetle,cortina,delorean}
then drives is an element of Drivers ↔ Cars, and the statement ‘Kate drives a
cortina’ could be formalised as kate cortina ∈ drives.
We may also choose to introduce a relation as an infix symbol: a symbol that sits between its arguments. Many familiar relations are written in this way: the less-than-or-equal-to relation ≤ on numbers; the subset relation ⊆ on sets. If the pair (x,y) is an element of the infix relation R, then we may write x R y. When we define an infix relation, we include underscores to indicate where the arguments should go.
Example 7.3 The relation drives could be defined by drives : Drivers ↔ Cars
drives = {helen beetle, indra alfa, jim beetle, kate cortina} That is, Helen and Jim drive Beetles, Indra drives an Alfa, Kate drives a Cortina,
and nobody drives a DeLorean.
Simple relations can be illustrated using diagrams with arrows, or graphs. The graph of drives is shown in Figure 7.1.
7.2 / Domain and range Drivers
helen indra jim kate
Figure 7.1 Who drives what? 7.2 Domain and range
85
alfa beetle cortina
delorean
Cars
A relation may contain a great deal of information; often, we require only a small part. To enable us to extract the information that we need, a number of basic functions are included in our mathematical language. The simplest examples are the domain and range functions, ‘dom’ and ‘ran’. If R is a relation of type X ↔Y, then the domain of R is the set of elements in X related to something in Y :
dom R = { x : X ; y : Y | x y ∈ R • x }
The range of R is the set of elements of Y to which some element of X is related:
ran R = { x : X ; y : Y | x y ∈ R • y }
Example 7.4 The set of people that drive is the domain of drives: domdrives = {helen,indra,jim,kate}
The set of cars that are driven is the range:
randrives = {alfa,beetle,cortina}
86 7 / Relations
We may focus upon part of the domain, or part of the range, by considering a subset of the relation. If R is a relation of type X ↔Y, and A is any subset of X , then A ▹ R denotes the domain restriction of R to A; this is the set of pairs
{x:X;y:Y|xy∈R∧x∈A•xy}
Any maplet whose first element lies outside A is ignored.
Example 7.5 In Example 7.2, we presented information about cars driven by members of the set Drivers. If we are concerned only with Jim and Kate, then it is enough to examine the relation{jim, kate} ▹ drives, which contains the maplets jim beetle and kate cortina.
Alternatively, we may restrict our attention to part of the range. If B is any subset of Y , then R ◃ B denotes the range restriction of R to B: this is the set of pairs
{x:X;y:Y|xy∈R∧y∈B•xy}
Any maplet whose second element lies outside B is ignored.
Example 7.6 If we are interested only in sports cars, then it is enough to con- sider the relation drives ◃ {alfa, delorean} which contains the single maplet indra alfa.
The position of the arguments is different for the two forms of restriction. In domain restriction, the set argument appears to the left of the operator; in range restriction, it appears to the right. This corresponds to the position of domain and range in the Cartesian product underlying the relation.
To exclude the set A from the domain of a relation, we could consider the domain restriction (X \ A) ▹ R. However, this occurs so frequently that an abbreviated form is provided. We write A −▹ R to denote the domain subtraction of A from R, where
A−▹R = {x:X;y:Y|xy∈R∧x̸∈A•xy}
This includes only those maplets whose first element does not lie in A. Similarly, we may exclude the set B from the range of a relation. We write
R −◃ B to denote the range subtraction of B from R, where R−◃B = {x:X;y:Y|xy∈R∧y̸∈B•xy}
This includes every maplet whose second element does not lie in B.
7.2 / Domain and range Drivers
helen indra jim kate
Figure 7.2 Relational image
87
Cars
alfa beetle cortina
delorean
Example 7.7 If we are concerned only with people who are not called ‘Jim’, then the relation {jim} −▹ drives tells us all that we want to know. It is a relation with three elements:
{helen beetle, indra alfa, kate cortina}
It may be that we are interested in the effect of a relation upon a particular setofelements. IfRisanelementofX ↔Y,andAisasubsetofX,thenwe write R(| A |) to denote the relational image of A under R. This is the set of all elements in Y to which some element of A is related. We may observe that
R(|A|) = ran(A▹R)
The relational image is simply the range of R domain restricted to A.
Example 7.8 The set of all cars that are driven by either Indra or Jim is given by the relational image of the set {indra, jim} under drives. That is,
drives(|{indra,jim}|) = {alfa,beetle} as shown in Figure 7.2.
88
7 / Relations Cars
Drivers
helen indra jim kate
alfa beetle cortina
delorean
7.3
Figure 7.3 The inverse relation Relational inverse
IfRisanelementofthesetX ↔Y,thenwesaythatX andY arethesource and target sets of R. The choice of terminology reminds us that relations are directional: they relate objects of one set to objects of another. It is always possible to reverse this direction, and thus present the same information in a different way.
The relational inverse operator ∼ does exactly this. Source and target are exchanged, and so are the elements of each ordered pair; the result is an element of Y ↔X such that
∀x:X;y:Y•xy∈R∼ ⇒yx∈R
The relation R∼ maps y to x exactly when R maps x to y.
Example 7.9 The inverse of the relation drives, defined in Example 7.2, relates cars to their drivers:
drives∼ = {alfa indra, beetle helen, beetle jim, cortina kate} The graph of this relation is shown in Figure 7.3.
If the source and target of a relation have the same type, then we say that the relation is homogeneous; if they are different, then we say that the relation is heterogeneous.
7.3 / Relational inverse 89
Example 7.10 The relation < on natural numbers is homogeneous: the source and the target sets are the natural numbers N. The relation drives is heteroge- neous: the source is Drivers, the target is Cars.
An important homogeneous relation is the identity relation, defined by id X == { x : X • x x }
That is, it associates each element of X with itself, and makes no other associ- ations. The identity relation is useful in reasoning about other relations and in classifying them. If a homogeneous relation contains the identity relation, we say that it is reflexive. The set of all reflexive relations on X is given by
Reflexive[X] == {R:X ↔X |idX ⊆R} Thatis,Risreflexiveif∀x:X •xx∈R.
Example 7.11 The relation ≤ upon natural numbers is reflexive; the relation < is not.
Another useful property of homogeneous relations is symmetry: we say that a relation is symmetric if whenever it relates x to y, it also relates y to x.
Symmetric[X] == {R:X↔X|∀x,y:X•xy∈R⇒yx∈R}
Example 7.12 At a business meeting, we might use a relation to record the fact that one person shook hands with another. This relation will be symmetric: if a shook hands with b, then b shook hands with a.
A symmetric relation is its own inverse:
⌈a b ∈ S⌉[1]
S ∈Symmetric[X] .
a b ∈ S ⇒ b a ∈ S ba∈S
∀a,b:X•ab∈S⇒ab∈S∼ [∀−intro] . S = S∼
[⇒−elim] .
b a ∈ S ⇒ a b ∈ S∼ a b ∈ S∼
[⇒−elim] ab∈S⇒ab∈S∼ [⇒−intro[1]]
[ext]
90 7 / Relations
Some parts of this derivation have been omitted. To complete the proof, we would expand the definition of Symmetric, refer to the generic definition of relational inverse in Section 8.3, and construct a matching derivation of the proposition∀a,b:X •ab∈S∼ ⇒ab∈S.
A homogeneous relation may be antisymmetric. In this case, it is impossi- ble for two different elements to be related in both directions.
Antisymmetric[X] ==
{R : X ↔X | (∀x,y : X • x y ∈ R ∧ y x ∈ R ⇒ x = y)}
If a relation is antisymmetric, we may use it to prove equality between two objects; we have only to show that the relationship holds in both directions.
Example 7.13 The subset relation ⊆ is antisymmetric. For any two sets s and t, if s ⊆ t and t ⊆ s, then s = t. This fact is often used to show that two sets are equal.
A homogeneous relation R may be asymmetric. In this case, the statements x y ∈Randy x ∈Raremutuallyexclusive.
Asymmetric[X] ==
{R:X ↔X |∀x,y :X •(x y ∈R)⇒¬(y x ∈R)}
Thatis,x y ∈Randy x ∈Rcannotbothbetrue.
Example 7.14 The strict subset relation is asymmetric: it is impossible to find
two sets s and t such that s ⊂ t and t ⊂ s.
These three categories—symmetric, antisymmetric, and asymmetric—are not
exhaustive; it is quite possible for a relation to be none of the three.
Example 7.15 Three people—Louise, Martin, and Natalie—live together in a shared house. A homogeneous relation likes records their feelings for each other:
likes = {LouiseMartin,LouiseLouise, Martin Louise, Martin Martin,
Martin Natalie, Natalie Natalie}
This relation tells us that Louise likes Martin, that Martin likes Louise, and Martin likes Natalie: see Figure 7.4.
Although likes is reflexive relation, each member of the household likes him- or herself, it is not symmetric: Martin likes Natalie, but Natalie does not
7.4 / Relational composition House
louise
martin
natalie
91
House
louise martin natalie
Figure 7.4 Who likes who?
like Martin. Neither is it antisymmetric: Martin and Louise like each other, but they are not the same person.
Finally, as a reflexive relation, it cannot be asymmetric. Even if we sub- tract the identity relation, the reciprocal relationship between Louise and Mar- tin would break asymmetry.
7.4 Relational composition
If the target type of one relation matches the source type of another, then they may be combined to form a single relation. If R is an element of X ↔Y , and S is an element of Y ↔ Z , then we write R 9o S to denote the relational composition of R and S. This is the element of X ↔Z such that
x z ∈ R 9o S ∃ y : Y • x y ∈ R ∧ y z ∈ S
That is, two elements x and z are related by the composition R 9o S if there is an
intermediate element y such that x is related to y and y is related to z. Example 7.16 The relation uses of type Cars ↔ Fuels tells us which fuel is used
by each of the cars in Example 7.2: uses : Cars ↔ Fuels
uses = {alfa unleaded,alfa leaded,beetle leaded, cortina leaded,delorean electricity}
92
Drivers
Cars
alfa beetle cortina
delorean
7 / Relations Fuels
unleaded leaded diesel electricity
helen indra jim kate
drives
uses
Figure 7.5 Which fuel to buy?
An Alfa can use either leaded or unleaded petrol, the older cars—Beetles and Cortina—require leaded petrol, and the DeLorean in question runs on large amounts of electricity.
We may compose the relations drives and uses to find out which fuels a driver may purchase. If buys = drives 9o uses then buys is a relation of type Drivers ↔ Fuels such that
buys = {helen leaded,jim leaded,kate leaded, indra unleaded,indra leaded}
This composition of relations is illustrated in Figure 7.5. Note that the maplet delorean electricity makes no contribution to the new relation.
In the previous section, we presented two useful properties of homoge- neous relations: reflexivity and symmetry. A relation is reflexive if it includes the identity relation, and symmetric if it includes its own inverse. The inclusion of a relational composition is associated with a third property: transitivity.
A homogeneous relation R is transitive if every pair of connecting maplets x y andy z inRhasacorrespondingmapletx z inR.
Transitive[X] ==
{R : X ↔X | ∀x,y,z : X • x y ∈ R ∧ y z ∈ R ⇒ x z ∈ R}
7.4 / Relational composition 93 Example 7.17 The greater-than relation on natural numbers N is transitive:
whenever a > b and b > c, we know that a > c.
Example 7.18 The likes relation is not transitive: it contains louise martin and martin natalie but not louise natalie. Louise likes Martin, and Martin likes Natalie, but Louise does not like Natalie.
If a homogeneous relation is reflexive, symmetric, and transitive, then it is an equivalence relation:
Equivalence[X] == Reflexive[X]∩Symmetric[X]∩Transitive[X]
Example 7.19 The relation same sign holds between two people if and only if they have the same birth sign. Assuming that each person has exactly one birth sign, this is an equivalence relation:
• any person a has the same sign as themselves, so same sign is reflexive;
• if a has the same sign as b, then b has the same sign as a, so same sign is
symmetric;
• if a has the same sign as b, and b has the same sign as c, then a has the
same sign as c, so same sign is transitive.
An equivalence relation E upon a set X divides that set into a number of disjoint subsets, each consisting of elements that are related to one other, ac- cording to E. For each element a, the equivalence class of a is the set
{x : X | x a ∈ E}
That is, the set of elements that are related to a.
Example 7.20 The relation same sign divides Person into twelve equivalence classes, corresponding to the twelve signs of the zodiac. If Marina was born on 28th January, then the equivalence class of Marina will be the set of all Aquarians (20th January – 18th February).
94
7 / Relations House
louise martin natalie
House
louise
martin
natalie
Figure 7.6 Symmetric closure
7.5 Closures
A principle that is often useful in specification is that of closure: given a certain amount of information, we may consider what may be obtained by using this information to its fullest extent, or by adding to it in a well-defined way. When applied to relations, this principle involves adding maplets to a relation until some useful property is achieved.
The simplest form of closure is obtained by adding the identity relation. If R is a homogeneous relation, we write Rr to denote its reflexive closure, where
Rr = R∪idX
A reflexive relation is its own reflexive closure.
Example 7.21 The reflexive closure
The minimum value is the unique element x of s such that for any element y of s,ify isnotequaltox theny mustbegreaterthanx.
The constraint s ≠ ∅ restricts the domain of the function to non-empty sets of natural numbers. If we wished to define a corresponding function max to return the maximum value in a set, then we would need to add a further constraint upon its domain, restricting to finite sets of natural numbers (finite sets are explained in the next chapter).
If the declaration part of a lambda expression introduces more than one variable, then the source type of the function is given by the resulting charac- teristic tuple. For example, the source of the function
( λ a : A; b : B; c : C • . . . )
would be the Cartesian product set A × B × C; we would expect to apply this function to objects of the form (a,b,c), where a ∈ A, b ∈ B, and c ∈ C.
8.3 / Functions on relations 103
Example 8.6 The function pair takes two functions f and g as arguments, each of which must be a homogeneous relation on N. The result is a function that takes a natural number n and returns the pair formed by applying each of f and g to n:
pair :((N→ N)×(N→ N))→(N→ (N×N)) pair=(λf,g:N→ N•(λn:N|n∈domf∩domg•(fn,gn)))
Because f and g may be any partial function on the natural numbers, pair is a total function.
Functional application is left associative: the expression f g a should be read as (f g)a. The function arrow, on the other hand, is right associative: A→B →C has the same meaning as A→(B →C).
Example 8.7 Let triple be the function (λ n : N • n + n + n). The expression
pair (double, triple) 3 = (pair (double, triple)) 3
= (λn : N • (doublen,triplen))3
8.3
= (double 3, triple 3)
= ((λ n : N • n + n) 3, (λ n : N • n + n + n) 3) = (6, 9)
Functions on relations
In the previous chapter, we introduced the operators that form the basis of a calculus of relations: domain, range, inverse, composition, and closure. These may all be seen as examples of functions upon relations.
Example 8.8 The domain and range operators may be defined by
[X,Y]
dom:(X ↔Y)→PX ran:(X ↔Y)→PY
∀R:X↔Y•
domR={x:X |∃y:Y •xy∈R} ranR={y:Y |∃x:X •xy∈R}
104 8 / Functions
If a function takes more than one argument, then it may be defined as an infix symbol; we use underscores to indicate the intended position of the arguments.
Example 8.9 The restriction operators may be defined by
[X,Y]
▹ :PX ×(X ↔Y)→(X ↔Y) ◃ :(X ↔Y)×PY →(X ↔Y)
∀R:X↔Y;A:PX;B:PY• A▹R={x:X;y:Y|x∈A∧xy∈R•xy} R◃B={x:X;y:Y|y∈B∧xy∈R•xy}
In the declarations above, we have assumed an order of precedence: by convention, the Cartesian product symbol binds more tightly than the function or relation symbols.
Example 8.10 The relational composition operator may be defined by [X,Y,Z]
9o :(X↔Y)×(Y↔Z)→(X↔Z) ∀R:X↔Y;S:Y↔Z•
R 9o S = { x : X ; y : Y ; z : Z | x y ∈ R ∧ y z ∈ S • x z }
The pair x z is present in the relational composition R 9o S exactly when there
is some y such that x y ∈ R and y z ∈ S.
We may use a single underscore to indicate that a function is intended as
a suffix symbol.
Example 8.11 The relational inverse operator may be defined by [X,Y]
∼ : (X ↔ Y ) → (Y ↔ X ) ∀R:X↔Y•
R∼ = { x : X ; y : Y | x y ∈ R • y x }
Given any two sets X and Y , the inverse operator is a total function on the set X ↔Y which yields relations in the set Y ↔X.
8.4 / Overriding 105 Example 8.12 The transitive closure operators may be defined by
[X]
+ : (X ↔ X ) → (X ↔ X ) ∗ : (X ↔ X ) → (X ↔ X )
∀R:X↔X•
R+ ={T :X ↔X |R⊆T ∧(T 9o T)⊆T}
R∗ ={T :X ↔X |(R∪idX)⊆T ∧(T 9o T)⊆T}
These definitions rely upon the fact that a relation T is transitive if and only if it contains the composition T 9o T .
8.4 Overriding
To combine the information contained in functions f and g, we could simply write f ∪ g. However, there may be objects that are mapped to one value under f, and to another under g; if this is the case, then f ∪g is not a function. To ensure that the combination of two functions is also functional, we must resolve any conflicts that arise.
If f and g are functions of the same type, we write f ⊕ g to denote the relational overriding of f with g. This is a relation that agrees with f everywhere outside the domain of g; but agrees with g where g is defined:
[X,Y]
⊕ :(X ↔Y)×(X ↔Y)→(X ↔Y)
∀f,g:X↔Y•
f ⊕ g = (dom g −▹ f ) ∪ g
Although the operator is usually employed for functions, it may be applied to any two relations of the same type.
Example 8.13 Suppose that a partial update arrives from the staff location sys- tem, informing us that Rachel and Sally are in the lobby and that Tim is in the office. This update may be represented by a partial function from Person to Location:
update = {rachel lobby , sally lobby , tim office}
106
8 / Functions
meeting room
quentin
peter
lobby
sally
otto
rachel
office
tim
kitchen
Figure 8.2 Where is Rachel now?
The union of this function with our original information would not be func- tional. The expression (where is ∪ update) rachel is not defined, as there are two locations associated with rachel in this relation.
If the information obtained from the update function takes precedence, then we may use
where now = where is ⊕ update
as our new location relation. The result is shown in Figure 8.2. The information thatQuentinandPeterareinthemeetingroomcomesfromwhere is,theothers are within the domain of update.
If two functions have disjoint domains, then there is no conflict between them, and overriding behaves as the union operator:
domf ∩domg=∅⇒f ⊕g=f ∪g
In this case, the overriding operator is commutative:
domf ∩domg=∅⇒f ⊕g=g⊕f
8.5 / Properties of functions 107
Example 8.14 If we were to receive two pieces of information, one locating Quentin and Peter,
information 1 = {quentin meeting, peter meeting} and the other locating Rachel and Sally, then
information 2 = {rachel lobby , sally office} then we could combine them in either order:
information 1⊕information 2 = information 2⊕information 1 as the domains are disjoint.
8.5 Properties of functions
It is extremely helpful to categorise functions according to whether or not they are total, and whether or not they possess three key properties: injectivity, surjectivity, and bijectivity. Our mathematical language has a special symbol associated with each category:
partial, injective functions total, injective functions → partial, surjective functions → total, surjective functions → partial, bijective functions → total, bijective functions
When we introduce a function using one of these arrows, an important property is made explicit.
The characteristic property of a function is a lack of diverging arrows in its graph: no element of the source is mapped to more than one element of the target. If in addition there are no converging arrows, then the relation is said to be an injective function, or an injection. Formally, f is an injection if
∀x1,x2 :domf •f x1 =f x2 ⇒x1 =x2
108
8 / Functions
Doors
Staff
kenny peanut neville sammy animal
front
back fire exit
Figure 8.3 Covering all the exits
Example 8.15 The location function of Example 8.3 is not injective. According
to where is, there are at least two different people in the meeting room: where is quentin = meeting
where is peter = meeting and quentin ≠ peter.
If the range of a function is the whole of the target, then it is said to be a surjective function, or a surjection. If the target of function f is B, then f is a surjection if ran f = B.
Example 8.16 There are three entrances to the Pink Flamingo: the front door, the back door, and the fire exit. Kenny and Peanut are paid to stand at the front door, Neville and Sammy are watching the back, and Animal is leaning on the fire exit. This situation is represented by a surjective function,
bouncers = {kenny front,peanut front, neville back, sammy back,
animal fire exit }
in which every door is covered: see Figure 8.3.
8.5 / Properties of functions Staff
kenny peanut neville sammy animal
109
Figure 8.4 Senior Citizens Night
front
back fire exit
Doors
A bijective function, or bijection, is a function which is both injective and surjective: no two elements of the domain are mapped to the same object, and the range is the whole of the target set.
Example8.17 ItisSeniorCitizensNightatthePinkFlamingo,soRegThorpe, the owner, decides that he needs just one bouncer on each door. Peanut and Sammy are given the night off, and the relaxed state of security is described by the following mapping, pictured in Figure 8.4:
{kenny front , neville back , animal fire exit } This is a partial bijection from the set of bouncers
{kenny , peanut , neville, sammy , animal } to the set of doors
{front,back,fire exit}
110 8 / Functions We define the set of all partial injective functions by generic abbreviation:
if A and B are sets, then
A B=={f:A→ B|∀x1,x2:domf•fx1=fx2⇒x1=x2}
AB == (A→B)∩(A B)
A total injective function is any member of this set which is also a total function
from A to B.
Example8.18 Ifsandtarethetwosets{1,2}and{a,b,c}respectively,then
the set of all partial injective functions from s to t is given by:
s t = {∅,{1a},{1b},{1c},{2a},{2b},{2c}, {1 a,2 b},{1 a,2 c},{1 b,2 a},
{1 b,2 c},{1 c,2 a},{1 c,2 b}}
and the set of all total injective functions is given by
st = {{1a,2b},{1a,2c},{1b,2a}, {1 b,2 c},{1 c,2 a},{1 c,2 b}}
If A and B are sets, we define the set of all partial surjections from one to the other as follows:
A→ B=={f:A→ B|ranf=B} A→B == (A→B)∩(A→ B)
A total surjective function is any element of this set that is also a total function from A to B.
Example 8.19 If s and t are as defined in Example 8.18, then there are no sur- jective functions from s to t:
s → → t = ∅
The source s has fewer elements than the target t, and for a function to be surjective, there must be at least as many elements in the domain—a subset of the source—as there are in the target.
8.6 / Finite sets 111 Finally, if A and B are sets, we define the set of all partial bijections from A to
B by generic abbreviation:
A→ B == (A B)∩(A→ B)
A→B == (A→ B)∩(A→B)
A total bijection is any element of this set that is also a total function.
Example 8.20 As none of the functions from s and t are surjections, there can be no bijections between these two sets. If we replace t with the set {a, b}, then two bijections are possible:
s→ {a,b} = {{1a,2b},{1b,2a}}
Both of these are total: for a function to be bijective, the domain and the target
must have the same number of elements. 8.6 Finite sets
Our mathematical language can be used to talk about any set, regardless of the number of elements it contains; indeed, infinite sets are often a more con- venient abstraction. However, it is worth considering the properties of finite sets, if only because they form the basis of our theory of finite sequences—the subject of the next chapter.
A finite set is one whose elements are countable up to some natural number n: that is, a set that may be seen as the range of a total bijection from the set
1,2,…,n
Example 8.21 The set {a, b, c} is finite: it may be seen as the range of a bijection from the set {1, 2, 3},
{1 a,2 b,3 c}
in which a, b, and c, correspond to 1, 2, and 3, respectively.
Our mathematical language includes a familiar piece of notation for defin- ing finite sets of numbers. The number range operator is a function on pairs of natural numbers, defined by
112
8 / Functions
.. :N×N→PN
∀ m, n : N • m . . n = {i : N | m ≤ i ≤ n}
If m and n are natural numbers, then m . . n is the set consisting of all numbers between m and n, inclusive.
We can now introduce a second power set symbol: if X is a set, then the set of all finite subsets of X is given by
FX == {s:PX |∃n:N•∃f :1..n→s•true} If X is a finite set, then FX and PX are equal.
8.6 / Finite sets 113 Example 8.22
• There are a finite number of oceans: we can exhibit a total bijection from the range 1..4 to the set of all Oceans:
{1 Atlantic, 2 Arctic, 3 Indian, 4 Pacific}
• There is only one Jose Feliciano: we can exhibit a total bijection from the
range 1 . . 1 to the set of all Jose Felicianos: {1 jose feliciano}
• The set of all inhabitants of Rockall is finite, despite being empty. The empty function is a total bijection from the empty number range 1 . . 0 to the empty set:
∅ ∈ 1 . . 0 → Rockallers
• The set of prime numbers is not finite. Given any natural number n, any
total injection
inj ∈1..nPrimes
can be used to generate another element of Primes that is outside the range of inj. Whatever n we choose, there is no hope of finding a surjective function from 1 . . n to Primes.
If s is a finite set, we write #s to denote the number of elements in s. This operator, called size or cardinality, is defined as follows:
[X] #:FX→N
∀s:FX;n:N•
n=#s∃f :(1..n)→s•true
For any finite set s, there is exactly one natural number n such that we can define a bijection from 1 . . n to s.
114 8 / Functions Example 8.23
• #Oceans = 4
• #Jose Felicianos = 1
• #Rockallers = 0
• #Primes is undefined
If the domain of a function is a finite set, then that function is itself finite; we write A → B to denote the set of all finite functions from A to B:
A→ B == {f :A→ B|domf ∈FA}
This set is important: it corresponds to the set of all finite collections of B,
indexed by elements of A. Also of interest is the set of all finite injections, A B == A→ B∩A B
This corresponds to the set of all finite collections of B, indexed by elements of A, without repetition.
Example 8.24 The mapping from bouncers to doors described in Example 8.16 is a finite function:
bouncers ∈ Staff → Doors
Once Peanut and Sammy are given the night off, as in Example 8.17, the mapping becomes a finite injection: the entrances are indexed by bouncers, without repetition.
Chapter 9
Sequences
It is sometimes necessary to record the order in which objects are arranged: for example, data may be indexed by an ordered collection of keys; messages may be stored in order of arrival; tasks may be performed in order of importance. In this chapter, we introduce the notion of a sequence: an ordered collection of objects. We examine the ways in which sequences may be combined, and how the information contained within a sequence may be extracted. We show that the resulting theory of sequences falls within our existing theory of sets, and provide formal definitions for all of the operators used. The chapter ends with a proof method for universal statements about sequences.
9.1 Sequence notation
A sequence is an ordered collection of objects. If there are no objects in the collection, the sequence is the empty sequence, and is written ‘⟨⟩’. Otherwise, the sequence is written as a list of objects between angle brackets: for example, the expression ⟨a, b, c⟩ denotes the sequence containing objects a, b, and c, in that order.
A useful way of composing sequences is concatenation, in which two se- quences are combined in such a way that the elements of one follow the ele- ments of the other, and order is maintained. If s and t are sequences, we write s ⌢ t to denote the concatenation of s and t . For example,
⟨a,b,c⟩ ⌢ ⟨d,e⟩ = ⟨a,b,c,d,e⟩
Example 9.1 The ticket office in a railway station has a choice of two counters at which tickets may be purchased. There are two queues of people, one at each
116 9 / Sequences counter; these may be modelled as sequences:
queue a = ⟨sally,tim,ulla⟩ queue b = ⟨vicky,wilson,xavier⟩
Sally and Vicky are at the head of their respective queues, but—just as Vicky is about to be served—the ticket machine at Counter b breaks down, and the people waiting there join the end of other queue. Order is maintained, so the result is given by queue a ⌢ queue b, the sequence
⟨sally,tim,ulla,vicky,wilson,xavier⟩
A queue of six people forms at Counter a.
A sequence contains information about a collection of elements and the order in which they occur. It may be that not all of this information concerns us: we may restrict our attention to elements from a given set using the filter operator: if s is a sequence, then s A is the largest subsequence of s containing only those objects that are elements of A:
⟨a,b,c,d,e,d,c,b,a⟩ {a,d} = ⟨a,d,d,a⟩
The order and multiplicity of elements is preserved.
Example 9.2 In the station, there is a destination board displaying a list of trains, arranged in order of departure: see Figure 9.1. This may be modelled as a sequence of pairs, each recording a time and a destination:
trains == ⟨(10.15,london),(10.38,edinburgh),(10.40,london), (11.15, birmingham), (11.20, reading), (11.40, london)⟩
Sally is interested only in those trains that are going to London; she would be content with the filtered sequence
trains{t :Time•(t,london)} that is,
⟨(10.15, london), (10.40, london), (11.40, london)⟩
9.1 / Sequence notation
117
time from to
10 15 OXFORD LONDON PADDINGTON
10 38 LONDON PADDINGTON EDINBURGH
10 40 GREAT MALVERN LONDON PADDINGTON
11 15 MANCHESTER POOLE
11 20 OXFORD READING
11 40 LONDON PADDINGTON MANCHESTER
Figure 9.1 Destination board
It may be that we need to refer to the first element of a sequence, or to the part of the sequence that follows the first element; these are called the head and tail, respectively. For example,
head ⟨a,b,c,d,e⟩ = a
tail ⟨a,b,c,d,e⟩ = ⟨b,c,d,e⟩
Notice that the head of a sequence is an element, while the tail is another se- quence. If s is any non-empty sequence, then
s = ⟨heads⟩⌢tails
Neither of these operators is defined upon the empty sequence.
Example 9.3 Sally wants to take the first train to London. From the list of trains on the destination board, she knows that this is the 10:15,
head(trains{t :Time•(t,london)}) = (10.15,london)
Tim is still waiting to buy a ticket, and the first train is about to leave. If we assume that he will not reach the platform in time, then the list of available trains is given by ‘tail trains’, the sequence
⟨(10.38, edinburgh), (10.40, london), (11.15, birmingham), (11.20, reading), (11.40, london)⟩
118 9 / Sequences The number of elements in a sequence is often of interest: if s is a sequence,
then we write ‘#s’ to denote the length of s. For example, #⟨a,b,c,d,e,f⟩ = 6
Recall that the same notation was used in Section 8.6 to denote the size of a finite set.
Example 9.4 The total number of trains on the destination board is given by #trains = 6
and the total number of trains to London is given by
#(trains{t :Time•(t,london)})=3
A distributed version of the concatenation operator maps a sequence of sequences to a single sequence; this process is sometimes called flattening. For example,
⌢/⟨⟨a,b,c⟩,⟨d,e⟩,⟨f,g,h⟩⟩ = ⟨a,b,c,d,e,f,g,h⟩
When a sequence of sequences is flattened, the result consists of the constituent
sequences concatenated in order.
Example 9.5 The names and addresses of Sally’s friends are stored in 26 files, address.a, address.b, …, address.z, according to the first letter of the person’s surname. Within each file, the records are ordered alphabetically: e.g., ad- dress.h contains the records
Robert Harris, 15 Royal Crescent, … Guy Hart-Davis, 38 Bridge Street, … Alison Harvey, 56 West Street, …
Sally would prefer to have just one file containing all of the records. Using the DOS copy command, she types:
copy address.a + address.b + … + address.z address.all
If we model each file as a sequence of addresses—for example, the first file
9.2 / A model for sequences 119 might be represented by a sequence address.a, where
address.a = ⟨‘Gregory Abowd, 1126 Pacific Street, …’, ‘Laurence Arnold, 9 Acacia Avenue, …’,
…⟩
—then we may describe the effect of the copy command using distributed con-
catenation:
address.all = ⌢/⟨address.a,address.b,…,address.z⟩
The result is exactly what Sally requires: a file address.all containing all of the
names and addresses, arranged in alphabetical order. 9.2 A model for sequences
The operators introduced above have not been formally defined; we have no way of proving anything about sequences, nor can we be sure that mathematical objects exist with the specified properties. For example, we stated that for any non-empty sequence s,
s = ⟨heads⟩⌢tails
but how can we be sure that this is the case? Clearly, we must find a formal basis for our theory of sequences.
Such a basis already exists within our mathematical language. A sequence may be regarded as a function from the natural numbers to a collection of objects: the object associated with 1 comes first in the sequence, the object as- sociated with 2 comes second, and so on. Thus, in our mathematical language, a finite sequence is a function defined upon some initial segment of the natural numbers: a number range starting at 1.
If X is a set, then the set of all finite sequences of objects from X is defined by the following abbreviation:
seqX =={s:N→ X|∃n:N•doms=1..n}
This definition makes explicit an assumption about sequences: that every ele-
ment of a given sequence must share the same type. The expression
⟨1, (1, 2)⟩
120 9 / Sequences
makes no sense to us: the first element is an element of N, while the second is an element of N × N.
In this book, we will restrict ourselves to sequences with finite length. Such sequences are easier to reason about, and are sufficient for most applica- tions. However, certain properties are impossible to describe without infinite sequences; fairness is an obvious example; it is perfectly possible to add a the- ory of infinite sequences to our mathematical language.
If a sequence is to be a special kind of function, then we are free to re-use the notation introduced in Chapters 7 and 8. For example, we can use functional application to refer to objects according to their position: if s is a sequence of at least n objects, then the expression ‘s n’ denotes the nth object in s.
Example 9.6 The third person in the queue at Counter b is Wilson: queue b 3 = wilson
and the second train on the destination board is the 10.38 to Edinburgh:
trains2 = (10.38,edinburgh)
Furthermore, the practice of using ‘#’ to denote both the cardinality of a set and the length of a sequence now makes perfect sense: if we regard a sequence s as a function, then the length of s is equal to the number of maplets in s.
If s and t are sequences and i is a number in the range 1 . . #s, then the ith element of s⌢t is the ith element of s:
(s⌢t) i = s i
and if j is a number in the range 1..#t, then the (j +#s)th element of s⌢t is
the jth element of t: (s⌢t) (j + #s) = t j
As s ⌢ t is a sequence of length #s + #t, this is enough to provide a unique definition of the concatenation operator:
[X]
⌢ :seqX ×seqX →seqX
∀ s, t : seq X •
#(s⌢t) = #s + #t ∀i:1..#s•(s⌢t)i = si ∀j:1..#t•(s⌢t)(#s+j) = tj
9.2 / A model for sequences 121
The restriction operator is harder to define. Not only must we remove any maplets which point to objects outside the chosen set, but we must also make sure that the result is a sequence. The first task is accomplished using range restriction, while the second requires an auxiliary function:
s A = squash(s ◃A)
The auxiliary function squash takes a finite function defined upon the natu- ral numbers and returns a sequence. It compacts the domain to remove any spaces created by range restriction, while preserving the order of the remaining maplets: for example,
squash{1a,3c,6f} = {1a,2c,3f} = ⟨a,c,f⟩ A suitable definition of squash would be:
[X]
squash:(N1→ X)→seqX
∀ f : ( N 1 → X ) •
squashf =(μg:1..#f →domf |g∼ o ( +1)o g⊆( < ))
o 9
f
For any function f whose domain is a finite set of numbers, we consider the unique function g that enumerates the domain of f in ascending order. The composition of g with f is then the sequence we require.
Our generic definition of restriction is then:
[X]
:seqX ×PX →seqX
∀ s : seq X ; A : P X •
sA = squash(s◃A)
The head operator is easily described:
[X] head:seqX→ X
∀ s : seq X | s ≠ ⟨⟩ • head s = s 1
99
122 9 / Sequences but the tail operator requires a translation:
[X]
tail:seqX→ seqX
∀ s : seq X | s ≠ ⟨⟩ •
#tail s = #s − 1 ∀i:1..#s−1•(tails)i = s(i+1)
These definitions make it clear that ‘head’ and ‘tail’ are strictly partial: the empty sequence has neither a head nor a tail. Because this sequence is excep- tional, we give a name to the set of all non-empty sequences over X ,
seq1X == {s:seqX |s≠⟨⟩}
Observe that ‘head’ and ‘tail’ are total when defined upon this set.
Another special set of sequences is the set of all injective sequences: se- quences in which no element appears more than once. We write iseq X to denote
the set of all injective sequences over set X , where iseqX == {s:seqX |s∈NX}
Such sequences are used to represent ordered collections of distinct objects.
9.3 Functions on sequences
In the course of a specification, we may wish to describe new operations upon sequences. For example, it might be necessary to reverse the order in which objects appear, or to select every other object in a sequence. We can, of course, define these new operations in terms of their effect upon finite functions, but there is a more convenient alternative.
We may introduce an operation f by describing its effect upon the empty sequence, and also its effect upon a sequence starting with an arbitrary element:
f ⟨⟩ = k
f (⟨x⟩⌢s)=g(x,f(s))
In this description, k is a constant expression, while g may be any function of x and f s. The fact that these equations define a unique function f on finite sequences is a consequence of the recursion principle for the natural numbers, which will be discussed in Section 10.4.
9.3 / Functions on sequences 123 Example 9.7 The function ‘reverse’ returns a sequence in which the elements
appear in reverse order. The two equations
reverse⟨⟩= ⟨⟩ (reverse.1)
reverse(⟨x⟩ ⌢ s) = (reverse s) ⌢ ⟨x⟩ (reverse.2)
are enough to describe the effect of ‘reverse’ upon any finite sequence. In this case, the constant k is simply ⟨⟩, and the function g is given by
[X]
g : X × seq X → seq X
∀ x : X ; s : seq X •
g(x,s) = (reverses)⌢⟨x⟩
However an operator is defined, we will find it useful to identify a set of laws: equations that express important properties of the operator in question. For example, the restriction operator admits the law
⟨⟩A = ⟨⟩ (filter.1) which states that the empty sequence is unaffected by an application of the
filter operator, and the law
(⟨x⟩⌢s)A = ⟨x⟩⌢(sA) ifx ∈A (filter.2) s A otherwise
which describes the effect of upon an arbitrary non-empty sequence.
A proof by equational reasoning is a series of expressions, each obtained from the previous one by substitution. Each substitution is justified by an
appropriate equation or law.
Example9.8 Usinglaws‘reverse.1’and‘filter.1’,wemayconstructaproofthat ‘reverse(⟨⟩ A) = (reverse ⟨⟩) A’ for any set A. We proceed as follows:
reverse(⟨⟩ A) = reverse ⟨⟩
= ⟨⟩
= ⟨⟩ A
= (reverse ⟨⟩) A
[filter.1] [reverse.1] [filter.1] [reverse.1]
124 9 / Sequences A common property of functions on sequences is distributivity. We say
that a function f is distributive if f(s⌢t) = (fs)⌢(ft)
for any sequences s and t. That is, if it distributes through concatenation. Example 9.9 The function add one is defined on sequences of numbers by the
following pair of equations:
add one⟨⟩=⟨⟩
add one(⟨n⟩⌢s)=⟨n+1⟩⌢(add ones)
The effect of applying add one is to increase each number in the sequence
by precisely one: for example, add one ⟨2, 4, 6⟩ = ⟨3, 5, 7⟩. This distributive,asadd one(s⌢t)=(add ones)⌢(add onet).
function is
The filter operator is also distributive, but this cannot be established by equational reasoning using the laws given above. We would need to show that
(s⌢t)A = (sA)⌢(tA)
for arbitrary sequences s and t. If s is empty, or a singleton sequence, then we may construct a proof using ‘filter.1’ or ‘filter.2’, respectively. If s has two or more elements, say
s = ⟨x1,x2,x3,...⟩
then we must rewrite s as ⟨x1⟩ ⌢ ⟨x2, x3, . . . , ⟩ before we can apply ‘filter.2’. To produce a formal proof, we must write s in extension.
To establish that is distributive by equational reasoning, it seems that we require an infinite family of proofs: a proof for when s is empty, a proof for when s has length 1, a proof for when s has length 2, and so on. The proof for length n will require n applications of the law ‘filter.2’, followed by a single application of ‘filter.1’. Fortunately, there is another way.
9.4 Structural induction
The set of natural numbers N has an important property. If P is a predicate on natural numbers such that
• P0istrue,and
• if i ∈ N and P i is true, then P (i + 1) is also true
9.4 / Structural induction 125
then P n is true for all natural numbers n. This is an induction principle for the natural numbers, and it can be extremely useful in proofs of universal proper- ties.
Example 9.10 The cumulative sum of the first n natural numbers has the value x = (n2 + n) div 2. Assuming a suitable definition of the function ‘sum’, and using the induction principle as a proof rule, we define a predicate
P:PN
∀ n : N • P n sum{ i : 0 . . n } = (n2 + n) div 2
to be our inductive hypothesis. We construct a proof of the following form: . .
P 0 ∀ m : N • P m ⇒ P (m + 1)
∀n : N • P n [induction]
∀n:N•sum{i:0..n}=(n2+n)div2 [axdef]
The left-hand branch of the proof is called the base case; the right-hand branch
is called the inductive step.
The set of all finite sequences over X has a similar property. If P is a
predicate on sequences such that • P⟨⟩istrue
• if x ∈ X , t ∈ seq X , and P t is true, then P (⟨x ⟩ ⌢ t ) is also true
then P s is true for all sequences s in seq X . This is an induction principle for
finite sequences over X ; it can be written as a proof rule:
P ⟨⟩ ∀ x : X ; t : seq X • P t ⇒ P (⟨x ⟩ ⌢ t ) ∀ s : seq X • P s
[induction]
This form of reasoning is called structural induction. Our induction principle is based upon the structure of a sequence; every non-empty sequence may be built up from the empty sequence by adding the appropriate elements, one at a time. If a property is true of ⟨⟩, and remains true whatever elements we add, then it is true of every finite sequence.
We are now able to construct a proof that is distributive: we can use structural induction to show that
∀ s , t : seq X ; A : P X • (s ⌢ t ) A = (s A) ⌢ (t A)
126 9 / Sequences
There are two sequence variables in the above predicate, but we will need to consider only one of them. Our inductive hypothesis is described by the fol- lowing predicate:
P :PseqX ∀ s : seq X •
P s ∀ t : seq X ; A : P X • (s ⌢ t ) A = (s A) ⌢ (t A) and the proof proceeds as follows:
⌈x ∈ X ∧ r ∈ seq X ⌉[1] ⌈S r ⌉[2] S (⟨x⟩ ⌢ r)
[Lemma 2] S r ⇒ S (⟨x⟩ ⌢ r) [⇒−intro[2]]
∀x:X;r:seqX•Sr⇒S(⟨x⟩⌢r) [∀−intro[1]]
P ⟨⟩ [Lemma 1] ∀s:seqX•∀t:seqX;A:PX•(s⌢t)A=(sA)⌢(tA) [axdef]
∀s : seqX • P s [induction] ∀ s , t : seq X ; A : P X • (s ⌢ t ) A = (s A) ⌢ (t A) [law of ∀]
The base case and inductive step in this proof have been reduced to simpler inferences: Lemma 1 and Lemma 2. These can be established by equational reasoning, using the following laws:
⟨⟩⌢s = s (cat.1)
s⌢(t⌢u) = (s⌢t)⌢u (cat.2)
The first of these confirms that ⟨⟩ is a unit for the concatenation operator; the second states that concatenation is associative.
The first lemma can be proved using the unit law of concatenation and law ‘filter.1’, which describes the effect of applying the filter operator to the empty sequence.
(⟨⟩⌢t)A = t A
= ⟨⟩⌢(t A)
= (⟨⟩A)⌢(t A)
[cat.1]
[cat.1] [filter.1]
The inductive step—Lemma 2—depends upon the associative property of con- catenation and the law ‘filter.2’.
((⟨x⟩⌢r)⌢t)A
9.4 / Structural induction
= (⟨x⟩⌢(r ⌢t))A
=⟨x⟩⌢((r⌢t)A) ifx∈A (r ⌢ t) A otherwise
=⟨x⟩⌢((rA)⌢(tA)) ifx∈A (r A) ⌢ (t A) otherwise
=(⟨x⟩⌢(rA))⌢(tA) ifx∈A (r A) ⌢ (t A) otherwise
= ((⟨x⟩⌢r)A)⌢(t A)
The step marked P r is justified by our inductive assumption that the result
holds for sequence r.
Example 9.11 For any set A and sequence s, the sequences ‘reverse(s A)’ and
‘(reverse s) A’ are equal, provided that the types of s and A are compatible: ∀s:seqX; A:PX •reverse(sA)=(reverses)A
The order in which reverse and filter are applied makes no difference.
This result is easily established by structural induction, with the following
predicate as an inductive hypothesis:
P :seqX
∀ s : seq X •
Ps∀A:PX •reverse(sA)=(reverses)A
The base case of the induction has already been established; it was the subject
of a proof in Example 9.8.
127
[cat.2] [filter.2]
[Pr]
[cat.2]
[filter.2]
⌈x ∈ X ∧ r ∈ seq X ⌉[1] ⌈P r ⌉[2] P (⟨x⟩ ⌢ r)
[see below] P t ⇒ P (⟨x⟩ ⌢ r) [⇒−intro[2]]
∀x:X;r:seqX•Pr⇒P(⟨x⟩⌢r) [∀−intro[1]] ∀s : seqX • P s [induction]
[Example 9.8]
∀s:seqX •∀A:PX •reverse(sA)=(reverses)A [axdef]
P ⟨⟩
∀s:seqX; A:PX •reverse(sA)=(reverses)A [lawof∀]
As in the proof that the filter operator is distributive, the inductive step can be
completed using equational reasoning:
reverse((⟨x⟩ ⌢ r) A)
128
9 / Sequences [filter.2]
[reverse.2] [Pr]
[filter.2] [filter is distributive] [reverse.2]
= reverse(⟨x⟩ ⌢ (r A)) reverse(r A)
= reverse(r A) ⌢ ⟨x⟩ reverse(r A)
if x ∈ A otherwise
if x ∈ A otherwise
=((reverser)A)⌢⟨x⟩ ifx ∈A (reverse r ) A otherwise
= ((reverser) A) ⌢ (⟨x⟩ A) = ((reverse r ) ⌢ ⟨x ⟩) A
= (reverse (⟨x ⟩ ⌢ r )) A
As with ordinary formal proofs, once an equational result has been established, it may be used as a law in subsequent proofs. Here, we have been able to exploit the fact that the filter operator is distributive.
9.5 Bags
A sequence stores information about the multiplicity and ordering of its ele- ments. In the sequence ⟨a, b, c, a, b, c⟩, we can see that there are exactly two occurrences of a, and that these occupy the first and fourth positions in the sequence. Sometimes this is more information than we need.
Suppose that only the number of occurrences of a is important. If this is the case, then the sequence above contains more detail than is necessary: it is not a fully abstract representation. The set {a,b,c}, on the other hand, is not an adequate representation: it records that a is present, but does not record how many times it occurs.
If we wish to record multiplicities, but not ordering, then we may represent a collection of objects as a bag. We write a, a, b, b, c, c to denote the bag containing two copies of a, two copies of b, and two copies of c. The order in which elements are written is not important: the expression a, b, b, a, c, c denotes exactly the same bag.
Example9.12 Fourfriends—Alice,Bill,Claire,andDavid—aresittinginacafé, waiting for their drinks to arrive. Alice and Claire have asked for espresso, Bill has asked for fruit tea, and David has asked for grape juice. Their requests can be represented by a bag:
espresso,espresso,fruit tea,grape juice
The order in which these drinks are to be delivered is left unspecified; the group
9.5 / Bags 129 willbecontentwithanyorderingthatincludestwoespressos,onefruit tea,and
one grape juice.
If B is a bag of elements from set X , then B may be regarded as a partial function from X to N. Any element of X that appears in B is associated with a natural number, recording the number of instances that are present. For example, the bag a, a, b, b, c, c contains the same information as the function {a 2, b 2, c 2}, which associates each element with the number 2.
If X is a set, then the set of all bags of elements from X may be defined by the following generic abbreviation:
bagX ==X→ N\{0}
where N denotes the set of all natural numbers. A bag is a finite partial function from X to N; elements of X that do not appear in the bag are left out of the domain, rather than mapped to zero.
If we wish to know how many instances of an object there are in a given bag, then we could simply apply the bag as a function. However, if the object is not present in the bag, the effect of this functional application is undefined. To avoid this, we employ the total function count:
[X]
count B : bagX →(X →N)
∀ B : bag X •
countB=(λx:X •0)⊕B)
If B is a bag of elements from set X , then count B associates each element of X with the number of times that it occurs in B, even if that number is zero.
For convenience, we define an infix version: if x is an element of X , then B ♯ x is the number of occurrences of x in B:
[X]
♯ :bagX×X→N
∀ B : bag X ; x : X • B ♯ x = count B x
The number of occurrences of a in the bag a,a,b,b,c,c could be written either as count a, a, b, b, c, c a or as a, a, b, b, c, c ♯ a.
Example 9.13 If drinks denotes the collection of drinks requested by the four
130 9 / Sequences friends in Example 9.12, then
count drinks espresso = 2
reflecting the fact that two people have asked for an espresso. It is also possible to order decaffeinated coffee in the café, but no-one has asked for it. This information may be expressed using the prefix function count,
count drinks decaffeinated coffee = 0 or the infix function ♯,
drinks ♯ decaffeinated coffee = 0
We define bag membership and sub-bag relations, similar to the set mem- bership and subset relations introduced in Chapter 5:
[X]
− :X↔bagX
⊑ :bagX↔bagX
∀ x : X ; B : bag X •
x − B x ∈ dom B
∀ B, C : bag X • B⊑C∀x:X•B♯x≤C♯x
An element x is a member of bag B if it appears in the domain of B, considered as a function. A bag B is a sub-bag of another bag C of the same type if each element occurs no more often in B than it does in C.
Example 9.14 At least one grape juice has been requested, grape juice − drinks
and two of the group have asked for espresso,
espresso, espresso ⊑ drinks
9.5 / Bags 131
We define also bag union and bag difference operators. If B and C are bags of the same type, then their union B ⊎ C contains as many copies of each element as B and C put together:
[X]
⊎ , ∪− :bagX×bagX→bagX
∀ B, C : bag X ; x : X • B⊎C♯x=B♯x+C♯x
B∪− C♯x=max{B♯x−C♯x,0}
If there are m copies of some element in bag B, and n copies of the same element in bag C, then the bag difference B ∪− C contains m − n copies, provided that m ≥ n. If there are more copies in C than in B, then the count of this element is zero in the difference.
Example 9.15 No sooner have the drinks been asked for than two more friends arrive—Edward and Fleur—and take their places at the table. Edward asks for a cappucino; Fleur asks for a mineral water. If we define
more drinks == cappucino,mineral water then the collection of requests is a bag union:
requests == drinks ⊎ more drinks
A few minutes later, a tray of drinks is brought over. It holds a mineral
water, a grape juice, a decaffeinated coffee, and an espresso:
tray == mineral water,grape juice,decaffeinated coffee,espresso The collection of outstanding requests is a bag difference:
remainder == requests ∪− tray
No-one has asked for a decaffeinated coffee, decaffeinated coffee ̸− requests, so its inclusion on the tray has no effect upon the remainder, which is equal to the bag fruit tea, espresso, cappucino.
If s is a sequence, then we may extract the multiplicity information from s using the function items, which turns sequences into bags:
132
9 / Sequences
[X]
items : seq X → bag X
∀ s : seq X ; x : X •
(items s) ♯ x = #(s ◃ {x})
The ordering information present in the sequence is discarded.
Example 9.16 Another tray is brought over with the remaining drinks; these are placed on the table in front of our friends. The order in which the drinks are placed upon the table is recorded in the following sequence,
arrive == ⟨grape juice,mineral water,espresso,fruit tea,cappucino, cappucino, espresso⟩
but only the count of each drink is important. The group at the table will be content, as items arrive = drinks.
Chapter 10
Free Types
In the course of a specification we may define a variety of data structures: lists, arrays, or trees of elements drawn from one or more basic types. These struc- tures could be modelled using a combination of sets and relations, but the re- sulting definitions would be quite verbose. A more elegant, concise alternative is offered by free types: sets with explicit structuring information.
In this chapter we show how free types are used to model enumerated col- lections, compound objects, and recursively defined structures. We examine the motivation behind free type definitions by attempting to describe a recur- sive data structure resembling the natural numbers. We then explain the con- sequences of such definitions, giving inference rules for reasoning about the objects that are introduced.
10.1 The natural numbers
The set of all natural numbers, N, is already part of our mathematical language; it has been defined as a subset of the built-in type Z. However, the construction of a set similar to N will prove a useful illustration of the properties of a free type. Thus we attempt to define such a set, beginning with a basic type nat, a zero element, and a partial function called succ:
zero : nat
succ : nat → nat
∀ n : nat • n = zero ∨ ∃ m : nat • n = succ m
Every element n is either the constant zero or the result of applying the succes- sor function succ to an element m.
134
10 / Free Types
(a)
(b)
(c)
(d)
succ
zero
zero
zero
zero
succ
succ
succ
Figure 10.1 Four sets that are not the natural numbers
Unfortunately, this is not enough to capture the essence of N. The set pictured in Figure 10.1(a) satisfies the above definition, but is quite unlike the set of natural numbers. Accordingly, we decide to exclude zero from the range of succ; however, even this is not enough. Consider the following:
zero : nat
succ : nat → nat
∀ n : nat • n = zero ∨ ∃ m : nat • n = succ m {zero} ∩ ran succ = ∅
This definition fails to exclude the set shown in Figure 10.1(b): it is quite pos- sible to have elements of nat that have no successor. Having realised that the function used to construct the natural numbers must be total, we try again:
10.2 / Free type definitions 135 zero : nat
succ : nat → nat
∀ n : nat • n = zero ∨ ∃ m : nat • n = succ m
{zero} ∩ ran succ = ∅
And still this is not enough. We have failed to exclude the possibility that some element is the successor of two or more others: see Figure 10.1(c). There is nothing that allows us to conclude that nat is an infinite set.
We must thus add a fourth requirement: that the function used to construct the natural numbers is injective. This leads us to the following definition:
zero : nat
succ : nat nat
{zero} ∩ ran succ = ∅ {zero} ∪ ran succ = nat
With this, we are guaranteed an infinite set with the familiar structure of the natural numbers. There is one more requirement to consider; the above defini- tion fails to exclude the set shown in Figure 10.1(d). The set nat must contain a copy of the natural numbers N, or at least a set with exactly the same structure, but it may contain more besides. The final requirement is that nat should be the smallest set that meets the conditions laid down above.
10.2 Free type definitions
Our mathematical language has a special mechanism for introducing sets such as nat: the free type definition. To begin with, consider the special case in which the set to be introduced has a small, finite number of elements. An example might be the set of colours of the rainbow: red, orange, yellow, green, blue, indigo, and violet. In the programming language Pascal, this set may be introduced as an enumerated type:
Colours = {red,orange,yellow,green,blue,indigo,violet} We could take a similar approach in Z, writing
Colours == {red,orange,yellow,green,blue,indigo,violet}
However, this abbreviation does not define the constants in the set. It not only fails to introduce the names, it also fails to make them distinct: there is no guarantee that red is different from green.
136 10 / Free Types The following free type definition has a different effect; it introduces a set
Colours, and seven distinct constants:
Colours ::= red | orange | yellow | green | blue |
indigo | violet
Once this definition has been made, we may infer that Colours is the smallest set containing the seven distinct elements red, orange, yellow, green, blue, indigo, and violet. The order in which these elements are introduced is unimportant: the definition
Colours ::= violet | indigo | blue | green | yellow | orange | red would have the same effect.
Example 10.1 The people in charge of Oxford colleges are given a variety of titles. We may represent this variety as a free type:
Titles ::= dean | master | president | principal | provost | rector | warden
From this definition we can conclude that ‘dean’ and ‘warden’ are elements of the set Titles and that dean ≠ warden. A dean and a warden are quite different animals.
We may include copies of other sets as part of a free type, using constructor functions. The notation
FreeType ::= constructor ⟨⟨source⟩⟩
introduces a collection of constants, one for each element of the set source.
constructor is an injective function whose target is the set FreeType.
Example 10.2 The University of Oxford awards a number of different degrees; four of the most common are: BA, bachelor of arts; MSc, master of science; D .Phil , doctor of philosophy; MA, master of arts. For ceremonial purposes, these degrees are ordered as follows: an MA is the highest ranking; a D.Phil takes second place, followed by an MSc and a BA, in that order.
Suppose that we wish to represent this ordered collection of degrees as a free type. The ordering of elements is similar to the one imposed upon the first four natural numbers by the less-than-or-equal to relation. Importing these numbers into a free type, we define
Degree ::= status ⟨⟨0 . . 3⟩⟩
10.2 / Free type definitions 137 and give names to the four elements of the set Degree:
ba, msc, dphil, ma : Degree
ba = status 0 msc = status 1 dphil = status 2 ma = status 3
We are then free to define the University’s ordering of degrees in terms of the ≤ ordering on 0..3:
≤status : Degree ↔ Degree ∀d1,d2 :Degree•
d1 ≤status d2 status∼d1 ≤ status∼d2
Because status is an injection, we can be sure that its inverse is a function, and
hence that status∼ d is well-defined.
Constants and constructor functions may be used together in the same
definition, as in the following free type:
FreeType ::= constant | constructor ⟨⟨source⟩⟩
What is more, the source type of a constructor function may refer to the free type being defined. The result is a recursive type definition: FreeType is defined in terms of itself.
Example 10.3 The set nat discussed in the previous section could be intro- duced by the following free type definition:
nat ::= zero | succ ⟨⟨nat⟩⟩
Every element of nat is either zero or the successor of a natural number, zero is not a successor, and every element of nat has a unique successor. The set nat is the smallest set containing the following collection of distinct elements: zero, succ zero, succ(succ zero), succ(succ(succ zero)), and so on.
Example10.4 Wemaydefineafreetypeofbinarytrees,inwhicheveryelement is either a leaf or a branching point.
Tree ::= leaf ⟨⟨N⟩⟩ | branch ⟨⟨Tree × Tree⟩⟩
138 10 / Free Types branch (branch (leaf 3, leaf 5), leaf 9)
branch (leaf 3, leaf 5) leaf 9
leaf 3 leaf 5
Figure 10.2 A binary tree
Each leaf contains a number; each branching point joins a pair of sub-trees. For example, one element of Tree is given by
branch (branch (leaf 3, leaf 5), leaf 9)
in which three different leaves are joined together to form the structure pictured
in Figure 10.2.
Example 10.5 The following definition introduces a more complex free type, in which every element is a tree: a pair whose first component is a natural number and whose second component is a sequence of trees.
SequenceTree ::= tree⟨⟨N × seq SequenceTree⟩⟩
This is a particularly involved data structure, a typical element of which is
shown below:
(1, ⟨(2, ⟨⟩), (3, ⟨⟩), (4, ⟨(2, ⟨⟩)⟩)⟩)
10.2 / Free type definitions 139 Suppose that E1, E2, ..., En are expressions that may depend on set T, and
that c1, c2, ..., cm are constant expressions. The definition T ::=c1 |...|cm |d1⟨⟨E1⟩⟩|...|dn⟨⟨En⟩⟩
introduces a new basic type T , with constant elements c1 , . . . , cm and construc- tor functions d1 , . . . , dn . The same effect could be achieved by introducing T as a basic type and making the following axiomatic definition:
c1 : T .
cm : T
d1 : E1 T .
dn : En T
disjoint ⟨{c1},...,{cm},rand1,...,randn⟩ ∀S:PT•
({c1 , . . . , cm } ∪ d1 (| E1 [S / T ] |) ∪ . . . ∪ dn (| En [S / T ] |)) ⊆ S ⇒S=T
Such a definition adds two inference rules to a specification. The first states that the constants are distinct and that the ranges are disjoint:
disjoint ⟨{c1},...,{cm},rand1,...,randn⟩
Example 10.6 In the case of nat, we may infer that the constant zero is not the
successor of any natural number,
disjoint ⟨{zero}, ran succ⟩
Example 10.7 From the definition of Tree, we may conclude that leaves and branches are different objects:
disjoint ⟨ran leaf , ran branch⟩
A tree may be either a leaf or a branch, but not both.
140 10 / Free Types The second rule is an induction principle: it is essential to reasoning about
the elements of a recursive type.
S ⊆T {c1,...,cm}∪d1(|E1[S/T]|)∪...∪dn(|En[S/T]|)⊆S S=T
Any subset of T that contains all of the constants and is closed under the constructors must be the whole of T. A set S is closed under d and E if the image of E[S /T] under d is within S itself.
Example 10.8 The free type definition of nat can be used to justify the follow- ing assertion:
∀ s : P nat • ({zero} ∪ succ(| s |) ⊆ s) ⇒ s = nat
Any subset of nat which contains zero and is closed under succ must be equal
to nat itself.
10.3 Proof by induction
The second inference rule above can be rewritten to match the induction princi- ples given in the previous chapter. Suppose that P is a predicate upon elements of a free type T , and define the characteristic set
S == {t : T | P t}
that is, S is the set of elements of T that satisfy P. Since S is a subset of T, the
inference rule gives us that
({c1 , . . . , cm } ∪ d1 (| E1 [S / T ] |) ∪ . . . dn (| En [S / T ] |)) ⊆ S S=T
We may use properties of the union and subset operators to separate the an- tecedent part of the rule into a list of inequalities. Furthermore, Each of the expressions involving ⊆ may be rewritten:
d i (| E i [ S / T ] |) ⊆ S
E i [ S / T ] ⊆ d i∼ (| S |) ∀e:Ei[S/T]•e∈di∼(|S |) ∀e:Ei[S/T]•di e∈S
That is, whenever a constructor di is applied, the result is an element of S.
10.3 / Proof by induction 141
If we may replace each instance of the statement e ∈ S with the abbreviated form P e, then we obtain an induction principle that matches those given for sequences:
P c1 .
P cm
∀e : E1[S /T] • P (d1 e) .
holds for any elements of the free type used in the construction of e. Example 10.9 The definition of nat involved a single constant zero and a single
constructor function succ:
nat ::= zero | succ ⟨⟨nat⟩⟩
This type has a single constant and a single constructor function; the definition yields an inference rule of the form
S⊆nat ({c}∪d(|E[S/nat]|))⊆S S = nat
In this instance: the constant c is zero; the constructor function d is succ; and the expression E is nat itself.
If P is a predicate on nat, we may take S to be the characteristic set S == {n : nat | P n}
and obtain the following induction principle:
P zero
∀m:nat •Pm⇒P(succm)
∀ n : nat • P n
To establish that P holds of every natural number, we must show that it holds for zero and that it is preserved by the successor function: if it is true of m, then it is also true of succ m.
∀ e : En [S / T ] • P (dn e) ∀t:T•Pt
[induction principle]
The appearance of S in the source set of e corresponds to the condition that P
142 10 / Free Types Example 10.10 The definition of Tree in Example 10.4 leads to the following
induction principle:
∀n:N•P(leaf n) ∀t1,t2 :Tree•
P t1 ∧ P t2 ⇒ P (branch(t1,t2)) ∀ t : Tree • P t
To show that a property P is true of all trees, we must show that it holds for any leaf, whatever value is stored there. We must show also that the property is preserved when trees are joined using branch: if it is true of both components, then it is true of their combination.
10.4 Primitive recursion
A function defined upon the elements of a free type may have a number of different parts: one for each clause in the type definition. For example, suppose that f is a function upon elements of a free type T , introduced by
T ::= c | d⟨⟨E⟩⟩
There may be two parts to the definition of f : one explaining the effect of f upon constant c, the other explaining the effect of f upon an element of the set d (| E |) .
If the expression E contains a copy of the free type T , the function definition will be recursive. It will describe the result of applying f to an element of d(| E |) in terms of the result of applying f to one or more components.
Example 10.11 We may define a function fact upon nat by giving a case for zero and a case for successors:
fact0 = 1
fact(succn) = (n+1)∗(factn)
If + and ∗ correspond to addition and multiplication, respectively, then this defines the ubiquitous factorial function upon nat.
The fact that such functions are well defined follows from a recursion prin- ciple for the type in question. In the case of the natural numbers, this principle
10.4 / Primitive recursion 143 may be stated as follows: for every value k and operator g, there is a unique
total function f from the natural numbers such that f0=k
f(n+1)=g(n+1)(f n)
This may be used to justify the use of recursively defined functions upon N. A similar principle applies to arbitrary free types, provided that their definitions are consistent, a condition discussed in the next section.
Example 10.12 We may define a function flatten that takes a binary tree and produces a sequence by traversing the tree from left to right.
flatten : Tree → seq N
∀ n : N • flatten leaf n = ⟨n⟩
∀ t1, t2 : Tree • flatten branch (t1, t2) = flatten t1 ⌢ flatten t2
Whenever it is applied to a branch, it will produce a sequence in which all of the elements of the left branch appear before those of the right.
Furthermore, we may define a function flip which transforms on binary trees by swapping the position of any two trees that meet at the same branch.
flip : Tree → Tree
∀ n : N • flip leaf n = leaf n
∀ t1, t2 : Tree • flip branch (t1, t2) = branch (flip t2, flip t1)
In both cases, the fact that the given equations define a unique function is a
consequence of the recursion principle for binary trees.
Recursion and induction go hand-in-hand. If a function has been defined using recursion, then induction may be required when we come to reason about its properties.
Example 10.13 Using the induction principle for binary trees, we may prove that flipping and flattening is the same as flattening and then reversing. To be more precise, if we apply flip to a binary tree and then flatten the result, we obtain the same sequence that appears when we flatten the tree and apply the reverse function. Formally,
∀ t : Tree • (flip o flatten) t = (flatten o reverse) t 99
where ‘reverse’ is the function on sequences defined in Chapter 9.
144 10 / Free Types The proof of this result proceeds as follows. We begin by identifying our
inductive hypothesis:
P(t) (flip o flatten)t = (flatten o reverse)t 99
and then check that the base case is valid. For any natural number n,
(flip 9o flatten) leaf n
= flatten(flip leaf n)
= flatten(leaf n)
= ⟨n⟩
= reverse ⟨n⟩
= reverse(flatten leaf n)
[property of 9o] [definition of flip] [definition of flatten] [definition of reverse] [definition of flatten] [property of o]
= (flatten o reverse) leaf n 99
This piece of equational reasoning can be incorporated into a simple deductive proof of the base case:
⌈n ∈ N⌉[1] (flip 9o flatten) leaf n =
∀n : N • P(leaf n) [∀−intro[1]]
We then proceed to show that the inductive step is also valid:
(flatten 9o reverse) leaf n P(leaf n)
[equational reasoning] [definition of P]
(flip; flatten)branch(t1,t2)
= flatten(flip branch (t1, t2))
= flatten( branch (flipt2, flipt1))
= flatten(flipt2) ⌢ flatten(flipt1)
= (flip 9o flatten)t2 ⌢ (flip 9o flatten)t1
= (flatten 9o reverse)t2 ⌢ (flatten 9o reverse)t1 = reverse(flattent2) ⌢ reverse(flattent1)
= reverse(flattent1 ⌢ flattent2)
= reverse(flatten branch (t1, t2))
= (flatten 9o reverse) branch (t1, t2)
[definition of 9o] [definition of flip] [definition of flatten] [definition of 9o] [P t1 ∧ P t2] [definition of 9o] [property of reverse] [definition of flatten] [definition of 9o]
The property of reverse used in this proof is easy to establish.
10.5 / Consistency 145 As before, we may incorporate this reasoning into a deductive proof:
⌈t1 ∈ Tree⌉[1] ⌈t2 ∈ Tree⌉[1] ⌈P t1⌉[1] ⌈P t2⌉[1] (flip 9o flatten) branch (t1, t2) =
(flatten 9o reverse) branch (t1, t2)
[equational reasoning]
P (branch (t1 , t2 )) [definition of P ] P t1 ∧ P t2 ⇒ P (branch (t1, t2)) [⇒−intro[1]]
∀t1,t2 : Tree • P t1 ∧ P t2 ⇒ P (branch(t1,t2)) [∀−intro[1]]
The equality that we were trying to prove now follows immediately, with a single
application of the induction principle for Tree. 10.5 Consistency
It is possible to use a free type definition to introduce a contradiction into any specification. To see how it might happen, consider the following definition:
T ::=d⟨⟨PT⟩⟩
The free type T contains an element d s for each element s of P T . Since d is injective, T must be at least as big as its power set. This is impossible, as for anyα,ifT hasαelements,thenPT has2α.
The problem lies in our use of the power set construction. This generates too many new elements at each application, producing a set that is bigger than itself. The same problem may occur with any construction using the relation symbol ↔ or the function symbol →. Such constructions are not finitary, and we cannot be sure that they will produce a consistent definition.
More formal definitions of finitary can be found in the literature, but for most applications it is enough to know that any construction involving only Cartesian products and finite power sets is finitary, and that any free type def- inition that uses only finitary constructions will be consistent. That is, the free type definition
T ::=c1 |...|cm |d1⟨⟨E1⟩⟩|...|dn⟨⟨En⟩⟩ will be consistent if each of the constructions
E1,...,En
involves only Cartesian products, finite power sets, finite functions, and finite sequences.
146 10 / Free Types Example 10.14 The free type definition
Fun ::= atom ⟨⟨N⟩⟩ | fun⟨⟨Fun → Fun⟩⟩
may not be consistent, as the construction Fun → Fun is not finitary.
Example 10.15 The free type definition
List ::= nil | atom⟨⟨N⟩⟩ | cat ⟨⟨List × List ⟩⟩
must be consistent, as both constructions are finitary.
Chapter 11
Schemas
In the Z notation there are two languages: the mathematical language and the schema language. The mathematical language is used to describe various as- pects of a design: objects, and the relationships between them. The schema language is used to structure and compose descriptions: collating pieces of information, encapsulating them, and naming them for re-use.
Re-usability is vital to the successful application of a formal technique. By identifying and sharing common components, we keep our descriptions both flexible and manageable. In the schema language, we see specifications shar- ing parts, proofs sharing arguments, theories sharing abstractions, problems sharing common aspects.
We believe that the use of schemas helps to promote a good specification style. However, as with any notation, the language of schemas requires careful and judicious application if it is not to be abused. We should take care to develop simple theories and to use schemas to present them in an elegant and comprehensible fashion.
This chapter is an informal introduction to schemas: their appearance, and the information they contain. We see how they may be used as types, as declarations, and as predicates. In subsequent chapters, we present a language of schema operators, and show how schemas may be used in reasoning about formal descriptions.
11.1 The schema
The mathematical language of Z is powerful enough to describe most aspects of system behaviour. However, the unstructured application of mathematics soon results in descriptions that are difficult to understand. To avoid this, we
148 11 / Schemas
must present mathematical descriptions in a sympathetic fashion, explaining small parts in the simplest possible context, and then showing how to fit the pieces together to make the whole.
One of the most basic things that we can do to help the reader—or indeed the writer—of a specification is to identify commonly used concepts and fac- tor them out from the mathematical description of a system. In this way, we can encapsulate an important concept and give it a name, thus increasing our vocabulary—and our mental power.
In formal specifications, we see a pattern occurring over and over again: a piece of mathematical text which is a structure describing some variables whose values are constrained in some way. We call this introduction of variables under some constraint a schema.
Example 11.1 The set comprehension term, lambda expression, and quantified predicates below each exhibit this pattern of introduction and constraint:
{m, n : N | n = 2 × m • m n} (λs:seqX |s≠⟨⟩•(tail s)⌢⟨head s⟩) ∀x,y : N | x ≠ y • x > y ∨ y > x ∃z:N|z≠1•z<2
Example 11.2 A concert hall uses a software system to keep track of bookings for performances. Inside the hall is a certain amount of seating, some or all of which may be made available to customers for a given performance. At this level of abstraction, we have no need to consider the representation of seats and customers, so we introduce them as given sets:
[Seat , Customer ]
The box office maintains a record of which seats have been sold, and to whom. This relationship should be functional: that is, no seat can be sold to two dif- ferent customers:
sold ∈ Seat → Customer
To allow for the possibility that seats may be added to or removed from the hall, we introduce a set seating, a subset of Seat, to represent the seating allocated for the performance.
11.1 / The schema 149 It should not be possible to book seating that has not been allocated; the
following predicate should be true at all times
dom sold ⊆ seating
That is, the domain of sold should be a subset of seating. This property, to- gether with the declarations of sold and seating, forms a schema which we shall call BoxOffice.
A schema consists of two parts: a declaration of variables; and a predicate constraining their values. We can write the text of a schema in one of two forms: horizontally
[declaration | predicate] or vertically
declaration predicate
In the horizontal form, the declaration and predicate are separated by a vertical bar, and the schema text is delimited by brackets. In the vertical form, the declaration and predicate are separated by a horizontal bar, and the schema text is delimited by a broken box.
Example 11.3 We can write the box office schema in horizontal form, as [seating : P Seat ; sold : Seat → Customer
| dom sold ⊆ seating] or in vertical form, as
seating : P Seat ; sold : Seat → Customer dom sold ⊆ seating
In the declaration part of a schema, the order in which variables are intro- duced is unimportant. In the above example, it would make no difference if sold were to be declared before seating.
150 11 / Schemas The schema language includes a special operator for associating names
with schemas. We may name a schema by writing
Name = [declaration | predicate]
or by embedding the name in the top line of the schema box
Name declaration
predicate
In either case, we are introducing a syntactic equivalence between Name and the schema text. We may use Name to refer to this text in the remainder of a formal description.
Example 11.4 We can name the box office schema text by writing BoxOffice = [seating : P Seat ; sold : Seat → Customer |
or by writing
dom sold ⊆ seating]
BoxOffice
seating : P Seat ; sold : Seat → Customer
dom sold ⊆ seating
Two schemas are equivalent if they introduce the same variables, and place the same constraints upon them. When considering equivalence, remember that some constraints may be hidden in the declaration part.
Example11.5 Thedeclarationpartoftheboxofficeschemaincludesthecon- straint that the relation sold between Seat and Customer must be functional. The following schema, in which this constraint appears as part of the predicate, is entirely equivalent:
seating : P Seat ; sold : Seat ↔ Customer
dom sold ⊆ seating ∧ sold ∈ Seat → Customer
11.1 / The schema 151
To make a schema more readable, we may put each declaration on a new line, and leave out the semicolons. Similarly, we may put each conjunct on a new line, and leave out the conjunction symbols. For example, the predicate
a⇒b c∨d
is another way of writing (a ⇒ b) ∧ (c ∨ d). Of course, this is not the case where the line is broken with another operator: for example, the predicate
∃y:T• x
Example 12.15 If the box office is no longer in the initial state, then its state may be characterised by the conjunction
BoxOffice′ ∧ (¬BoxOfficeInit)
Notice that it is not enough to simply negate the initialisation schema. The schema ¬BoxOfficeInit describes the set of all bindings of seating and sold that do not match the initial state: this includes bindings that are not valid states of the system.
12.5 Quantification and hiding
We may quantify over some of the components of a schema while retaining the declarations of the others. If Q is a quantifier and dec is a declaration, then the quantified schema
Q dec • Schema
12.5 / Quantification and hiding 179
may be obtained from Schema by removing those components that are also declared in dec and quantifying them with Q in the predicate part. For this schema to be properly defined, every variable declared in dec must appear in Schema as a component of the same type.
For example, if S is the schema with components a and b of types A and B, introduced under the constraint P,
S a:A b:B
P
then ∀ b : B • S is the schema
a:A ∀b:B•P
and ∃ b : B • S is the schema a:A
∃b:B•P
Example 12.16 The friendly box office records the status of the current perfor- mance: if the show is a premiere, then seats are sold only to customers who are registered friends of the theatre:
FriendlyBoxOffice status : Status
friends : P Customer sold : Seat → Customer seating : P Seat
dom sold ⊆ seating
status = premiere ⇒ ran sold ⊆ friends
If we precede this schema with a universal quantification of the variable status, then we obtain a schema that no longer records the status of the current perfor- mance. The result is not the same as if this component had never been present:
180 12 / Schema Operators
the system behaves as if it is still there, universally quantified, in the predicate part of the schema.
To see why, consider the quantified schema:
∀ status : Status • FriendlyBoxOffice The predicate part insists that
∀ status : Status •
dom sold ⊆ seating
status = premiere ⇒ ran sold ⊆ friends
If this quantified expression is to be an invariant of the system, then tickets may be sold only to friends of the theatre, for else the subexpression status = premiere ⇒ ran sold ⊆ friends would be false for one of the values of status.
The quantification over status has produced a cautious version of the box office system:
CautiousBoxOffice friends : P Customer sold : Seat → Customer seating : P Seat
dom sold ⊆ seating ran sold ⊆ friends
It is as if the universal quantification over status has forced the system to take a pessimistic view as to the status of the performance: it caters for both possibilities—standard and premiere—by selling only to friends.
Example 12.17 The operation of successfully returning a ticket to the box office required the name of a customer. We may dispense with this requirement by existentially quantifying over the input component c?. The result is an anony- mous version of the return operation:
∃ c ? : Customer • Return0
The predicate part of the new schema states that
∃c?:Customer •
s? c? ∈ sold ∧
sold′ =sold\{s?c?}∧ seating′ = seating
12.5 / Quantification and hiding 181 With care, we may rewrite this predicate to make the results of the operation
more obvious:
∆BoxOffice s? : Seat
r! : Response
∃c?:Customer •
s? c? ∈ sold ∧
sold′ =sold\{s?c?}∧ seating′ = seating
It is as if the existential quantification has forced the system to take an opti- mistic view as to the identity of the customer. By the one-point rule and the properties of functions, this schema is equivalent to
AnonymousReturn0 ∆BoxOffice
s? : Seat
r! : Response
s? ∈ dom sold sold′ = {s?} −▹ sold seating′ = seating
For this operation to be properly defined, it is necessary only that the input s? is an element of the domain of sold.
Schema existential quantification is also called hiding: the quantified com- ponents are no longer visible in the declaration, yet the predicate tells us that they exist. This provides a powerful mechanism for abstraction in the schema language: we may hide any components that are not required at the current level of specification.
This mechanism has its own operator: if list is a list of component names, then the schema Schema \ list may be obtained by existentially quantifying each component in list within Schema. For example, if S is the schema introduced by
S a:A b:B
P
182 12 / Schema Operators then S \ (a) is the schema
b:B ∃a:A•P
Thus hiding is no more than a quick way of writing (and pronouncing) existential quantification over schema components.
Example 12.18 The enhanced box office system included a component that recorded the number of seats available for the current performance. We may abstract away this information by hiding available within the schema:
EnhancedBoxOffice \ (available)
The result is a schema with the same components as BoxOffice:
BoxOffice
∃ available : N • available = free θBoxOffice
Since free is a total function, the number of seats available is always uniquely determined by the values of seating and sold. This schema is equivalent to the original box office description.
12.6 Composition
The use of schemas to describe operations begs an interesting question: how does one describe the effect of one operation followed by another? Alterna- tively, we might ask: if an operation schema characterises a relation between states of the system, then how does one represent the composition of two such relations? The answer in both cases is schema composition.
If OpOne and OpTwo are operation schemas, each including primed and unprimed copies of a state schema State, then the composition OpOne 9o OpTwo describes the change in state that results when operation OpOne is followed by operation OpTwo.
In OpOne, the components of State′ represent the state of the system im- mediately after the operation. In the composition above, this is also the state of the system immediately before OpTwo. We introduce a new schema to rep- resent this intermediate state: State′′.
12.6 / Composition 183 The schema composition relates the state immediately before OpOne to the
state immediately after OpTwo, and State′′ is hidden:
OpOne9o OpTwo = ∃State′′ •
∃ State′ • [OpOne; State′′ | θState′ = θState′′]
∧
∃ State • [OpTwo; State′′ | θState = θState′′]
The relationship between the before state and the intermediate state—θState and θState′′—is described by schema OpOne; the relationship between the intermediate state and the after state—θState′′ and θState′—is described by schema OpTwo.
For the composition to be defined, both schemas must refer to the same state. For any primed component in OpOne, there must be an unprimed com- ponent of the same name in OpTwo. For example, suppose that OpOne and OpTwo are introduced by
OpOne a,a′ :A b,b′ :B
OpTwo a,a′ :A b,b′ :B
PQ
The state components in each operation are the same, so their schema compo- sition will be well defined.
The composition of OpOne and OpTwo may be calculated using schema existential quantification, as above, or by renaming the state components cor- responding to the intermediate state:
OpOne 9o OpTwo =
(OpOne[a′′/a′, b′′/b′] ∧ OpTwo[a′′/a, b′′/b]) \ (a′′, b′′)
The components representing the intermediate state, a′′ and b′′ are then hid- den. If we were to expand this schema, we would see that the composition is equivalent to:
a,a′ :A b,b′ :B
∃a′′,b′′ •
P[a′′/a′,b′′/b′] ∧ Q[a′′/a,b′′/b]
184 12 / Schema Operators
Example 12.19 If a customer successfully purchases a seat, and then returns it immediately to the box office, then the state of the system should be unaffected. The combined operation is described by
Purchase0 9o Return
where Purchase0 and Return are as defined above. The result that we might
hope to establish can be expressed as
Purchase0 9o Return ΞBoxOffice
This is an inference in which the composition is used as a declaration: intro- ducing a collection of components under the stated constraint. The schema ΞBoxOffice is used only as a predicate.
Chapter 13
Promotion
In this chapter we describe an important technique for structuring formal de- scriptions. It is called promotion, and it allows us to compose and factor spec- ifications. It has also been called framing, because it is evocative of placing a frame around part of a specification: only what is inside the frame may change; what is outside must remain unaffected.
We begin the chapter with three different examples of the technique: a game, a mail system, and a data array. We then give a formal definition of promotion, and distinguish between two varieties: free and constrained. The chapter ends with two further examples of promotion: a free promotion of a booking system, and a constrained promotion within a priority stack.
13.1 Factoring operations
Large software systems often contain multiple, indexed instances of the same component. A database may contain a number of records, a computer system may have several users, a data network may consist of a number of switching nodes. If this is the case, then there will exist a uniform relationship between the system state and the state of each indexed component.
This relationship allows us to link certain changes in system state to changes in the state of indexed components. We may factor a global operation into a local operation and a mixed operation, the latter expressing the relationship between local and global state. This is a useful separation of concerns; the two factors may be specified and analysed in isolation. We have used the structur- ing information in the design of the system to simplify our formal description.
186
13 / Promotion
local score
global score
Figure 13.1 A game in progress
Example 13.1 In the game of Trivial PursuitTM, the players collect tokens of various colours—red, green, yellow, blue, brown, and pink—the aim being to collect one token of each colour. There are no teams: each player maintains an individual score. A player’s score may be modelled using a schema type
LocalScore s : P Colour
where Colour is the set of colours mentioned above.
The overall state of play at any point during the game is given by a binding
of the following schema type:
GlobalScore
score : Players → LocalScore
Here, a partial function called score associates each player with an object of type LocalScore. Figure 13.1 shows a situation in which one of the players has collected exactly two tokens.
13.1 / Factoring operations 187
Players are awarded tokens if and when they provide correct answers to questions on various subjects; the colour awarded depends upon the choice of subject. If a player p? earns a token of colour c?, then the effect upon the state of play is described by the following operation schema:
AnswerGlobal ∆GlobalScore p? : Player
c? : Colour
p? ∈ dom score
{p?} −▹ score′ = {p?} −▹ score (score′ p?).s = (score p?).s ∪ {c?}
Provided that p? is indeed part of the current game, the function score is up- dated to reflect the new score associated with p?.
An alternative approach would involve factoring this operation into a local operation—
AnswerLocal ∆LocalScore c? : Colour
s′ =s∪{c?}
—and a schema expressing the relationship between global and local states—
Promote ∆GlobalScore ∆LocalScore p? : Player
p? ∈ dom score
θLocalScore = score p?
score′ = score ⊕ {p? θLocalScore′}
—in which a change in GlobalScore and a change in LocalScore are linked by the identity of the player involved.
If we conjoin the AnswerLocal and Promote schemas, then we obtain a schema that describes an operation upon the global state:
∃ ∆LocalScore • AnswerLocal ∧ Promote
188 13 / Promotion
The local state is uniquely determined by the function score, so there is no need to record this information at the global level. The existential quantification hides it, yielding a predicate part
∃ ∆LocalScore •
p? ∈ dom score
θLocalScore = score p?
score′ = score ⊕ {p? θLocalScore′} s′ =s∪{c?}
We may rewrite this as
∃s,s′ :PColour •
p? ∈ dom score
⟨|s s|⟩ = score p?
score′ = score ⊕ {p? ⟨|s s′|⟩} s′ =s∪{c?}
and hence as
∃ s : P Colour •
p? ∈ dom score
(scorep?).s = s
score′ = score ⊕ {p? ⟨|s s ∪ {c?}|⟩}
to obtain a schema equivalent to AnswerGlobal:
∆GlobalScore p? : Player
c? : Colour
p? ∈ dom score
{p?} −▹ score′ = {p?} −▹ score (score′ p?).s = (score p?).s ∪ {c?}
In the above example, there is little to choose between the two approaches, although the factored description makes it easier to see the effect of the op- eration upon the local state. However, as we define more operations, and add more information to the local state, the advantages of the factored approach become obvious.
13.1 / Factoring operations 189
The relationship between the global state and the collection of local states need not be functional. There may be several components with the same index, in which case the association between indices and components can be modelled as a relation.
Example 13.2 An electronic mail system consists of several instances of the component MailBox. Each instance may be associated with one or more ad- dresses from the set Address. A user of the system may have more than one address, and an address may be associated with more than one user.
MailSystem
address : User ↔ Address mailbox : Address → MailBox
The association between users and addresses is given by a relation address, and the association between addresses and mailboxes is given by the partial function mailbox.
Figure 13.2 shows a mail system with three users: Carolyn, Denise, and Edward. Each user has a personal mailbox, with an appropriate address. Car- olyn and Denise share ownership of the system administrator’s mailbox with address admin. Edward has two mail addresses, edward and edwardc, each with its own mailbox.
A mailbox is modelled by a schema type with three components. The first is a sequence of type Message, representing the mail messages stored in the box. The others are time stamps:
MailBox
mail : seq Message
new mail,last read:TimeStamp
Of these, new mail records the time of arrival of the latest mail message, and last read records the last time that mail in the box was read.
A typical object of type MailBox might be
⟨|mail ⟨m1,m2,m3⟩,,
new mail Tue 14 Feb, 11.00 a.m. , last read Sun 12 Feb, 12.30 p.m. |⟩
This tells us that the box holds three messages—m1, m2, and m3—the last of which arrived at 11.00 a.m. on Tuesday 14th February. It states also that mail in this box was last read at 12.30 p.m. on Sunday 12th February.
190
User
Address
admin carolyn denise edward edwardc
13 / Promotion Mailbox
Carolyn
Denise
Edward
address
mailbox
Figure 13.2 Addresses and mailboxes
If a message m? arrives at time t? for user u?, then it will be added to one of the mailboxes belonging to u?. These components are taken as inputs to the following operation schema, which describes the effect upon the global state:
ReceiveSystem ∆MailSystem u? : User
m? : Message t? : TimeStamp a! : Address
u? a! ∈ address
address′ = address
a! ∈ dom mailbox
{a!} −▹ mailbox′ = {a!} −▹ mailbox
(mailbox′ a!).mail = (mailbox a!).mail ⌢ ⟨m?⟩ (mailbox′ a!).new mail = t?
(mailbox′ a!).last read = (mailbox a!).last read
The address used, a!, is provided as an output to the operation. The value of address and the contents of the other mailboxes—given by {a!} −▹ mailbox—are left unchanged.
13.1 / Factoring operations 191
Again, we may choose an alternative approach, factoring global operations such as ReceiveSystem into two parts. The first part, which is the same for each operation, expresses the link between local and global changes of state:
Promote ∆MailSystem ∆MailBox
u? : User
a! : Address
u? a! ∈ address
address′ = address
a! ∈ dom mailbox
θMailBox = mailbox a!
mailbox′ = mailbox ⊕ {a! θMailBox′}
The link is made by identifying the user u? and the address a! involved in the operation. The local state is given by mailbox a!, where u? a! is an element of the address relation. This is the only part of the global state that will change; this is the frame in which the operation will take place.
The second part of the factorisation is a schema that describes the effect of adding mail to a single mailbox:
ReceiveBox ∆MailBox
m? : Message t? : TimeStamp
mail′ = mail ⌢ ⟨m?⟩ new mail′ =t?
last read′ = last read
The incoming message is added to the end of the sequence mail, and the new mail is set to t?. The other time stamp remains unchanged.
If we conjoin these two schemas, and abstract away the components of the local state, as in
∃ ∆MailBox • ReceiveBox ∧ Promote
then we obtain a schema that is logically equivalent to the global operation ReceiveSystem.
192
13 / Promotion
global state
value
value
local state
Figure 13.3 A data array
In some systems, the components may be indexed sequentially; in this case, the relationship between the global and local states may be based upon a se- quence, rather than a simple function or relation.
Example13.3 Inamodelofadataarray,eachelementmayberepresentedby an object of schema type Data, where
Data
value : Value
The state of the array is represented by an object of schema type with a single component, a sequence of Data elements:
Array
array : seq Data
The relationship between the state of the array—the global state—and the state of a data element—the local state—is illustrated in Figure 13.3.
If an operation upon the array affects but a single element, then we may express it as the product of two schemas: a local operation schema and a pro- motion schema. For example, the operation of assigning a new value to a data element could be described as
∃ ∆Data • AssignData ∧ Promote
13.2 / Promotion 193 where the local operation schema is introduced by
AssignData ∆Data
new? : Value
value′ = new?
and the promotion schema, which makes the link between global and local
states using the index of the data, is introduced by
Promote ∆Array ∆Data index? : N
index? ∈ domarray
{index?} −▹ array = {index?} −▹ array′ array index? = θData
array′ index? = θData′
Once again, the promotion schema describes the frame, while the local opera- tion schema describes the effect.
13.2 Promotion
When a global operation is defined in terms of a local operation upon an indexed component, as in each of the examples above, we say that the local operation has been promoted. Formally, suppose that we have
• a state schema Local, that describes a copy of the local state;
• a state schema Global, that describes a copy of the global state;
• a local operation schema LocalOperation, that contains decorated and un- decorated copies of the state schema Local;
• a promotion schema Promote, that contains decorated and undecorated copies of both Local and Global.
Then the promotion schema promotes the local operation to ∃ ∆Local • Promote ∧ LocalOperation
which operates on the global state Global.
194 13 / Promotion
Example 13.4 A global box office system keeps track of bookings for a number of performances. The record of seats allocated and tickets sold for each per- formance is represented by an object of schema type BoxOffice. These objects are indexed by a function on Performance, the set of all possible performances:
GlobalBoxOffice
announced : P Performance booking : Performance → BoxOffice
dom booking ⊆ announced
As well as booking, the system maintains a set called announced for reference purposes. The two components are connected: any performance for which we are booking must have been announced. On the other hand, some performances may have been announced but have not yet started booking.
A booking operation is an operation upon the global box office system that involves the sale or return of a seat. These operations may be factored using promotion. We define a promotion schema:
Promote ∆GlobalBoxOffice ∆BoxOffice
p? : Performance
p? ∈ dom booking
θBoxOffice = booking p? θBoxOffice′ = booking′ p?
{p?} −▹ booking′ = {p?} −▹ booking announced′ = announced
This tells us the relationship between the local state of a box office system and the global state in such an operation, given that we are talking about perfor- mance p?. Such local operations do not affect the list of performances that have been announced.
We may promote the local operation of buying a ticket to a global operation simply by conjoining the schema above with Purchase:
GlobalPurchase0 = ∃ ∆BoxOffice • Purchase ∧ Promote
A single box office has changed—the one identified by input p?—and the effect of this change is described by the operation schema Purchase.
13.2 / Promotion 195
The promotion schema identifies input p? with a unique performance; if we expand GlobalPurchase0, then the existential quantification can be eliminated. The result is a schema equivalent to the following:
∆GlobalBoxOffice p? : Performance s? : Seat
c? : Customer
r! : Response
p? ∈ dom booking
( ( s? ∈ booking p?.seating \ dom booking p?.sold ∧
booking p?.sold′ = booking p?.sold ∪ {s? c?} ∧
r! = okay) ∨
( s? ̸∈ booking p?.seating \ dom booking p?.sold ∧ booking p?.sold′ = booking p?.sold ∧
r ! = sorry ) )
{p?} −▹ booking′ = {p?} −▹ booking announced′ = announced
Even where the indexing relation is functional, the advantages of structuring our descriptions using promotion should be obvious.
Of course, the promotion schema is used only in factoring operations which may be described in terms of their effect within an indexed frame. Other oper- ations upon the global state will not be factorised in this way.
Example 13.5 The GlobalPurchase0 operation defined above is not total: it de- scribes only those situations in which the performance in question is already booking. We may wish to add the following alternative:
NotYetBooking ΞGlobalBoxOffice p? : Performance r! : Response
p? ∈ announced \ dom booking r! = not yet booking
This describes the situation in which—although the performance in question has been announced—the office is not accepting bookings.
196 13 / Promotion Example 13.6 We may instruct the box office system to start accepting book-
ings for a performance p?:
StartBooking ∆GlobalBoxOffice p? : Performance
p? ∈ announced
p? ̸∈ dom booking announced′ = announced ∃BoxOfficeInit •
booking′ = booking ∪ {p? θBoxOffice′}
A performance cannot start booking unless it has been announced; neither can
it start booking more than once.
13.3 Free and constrained promotion
A promotion is said to be free if and only if the promotion schema satisfies (∃ Local′ • ∃ Global′ • Promote) ⇒ (∀ Local′ • ∃ Global′ • Promote)
That is, provided that the update is possible at all, it is possible for all outcomes of the local state.
In a free promotion, neither the promotion schema nor the global state invariant should place any additional constraint upon the component variables of the local state: that is, any constraint above that provided by the local state schema itself. Then, and only then, can the quantifiers be exchanged.
Todecidewhetheragivenpromotionisfree,weexpand∃Global′ •Promote and simplify the predicate part of the resulting schema. We should be left with an expression in which θLocal appears unconstrained, other than by the predicate part of Local iself.
The exchange of quantifiers can then be justified using schema equivalents of the quantifier rules. The rule required for existential elimination is
⌈s ∈ S⌉[i]
∃S•B C C
.
⌈B[s/θS]⌉[i]
[∃−elim[i] ]
provided that s is not free
in either the other assumptions or C
13.3 / Free and constrained promotion
and the rule for universal introduction is
⌈s ∈ S⌉[i] .
B[s/θS] [i] ∀ S • B [∀−intro ]
197
provided that s is not free in the other assumptions
Notice how the decoration mechanism gives us a way of generating instances of the appropriate schema type in such a way that we are able to distinguish between them at component level: the components in S′ are associated with variables that differ from those of S.
Example 13.7 The data array description of Example 13.3 is an example of a free promotion. The schema ∃Data′ • ∃Array′ • Promote asserts that the index chosen as input is a valid index for the array—index? ∈ domarray—and does not constrain the value stored at that index, apart from identifying it as array index?. The promotion is thus independent of the actual value stored at the index; provided that the index is valid, the promotion will work: it is free.
To see this in terms of the implication that was used to characterise a free promotion, we consider the expression ∃ Data′ • ∃ Array′ • Promote. That is, there is at least one local after-state with a global after-state satisfying the promotion condition.
Consider the inner existential quantification: that beginning with ∃Array′. Replacing the Promote schema with the body of its definition, and moving the existential quantification of Array′ into the predicate part of the resulting schema, we see that
∃Array′ •Promote
[Array; ∆Data; index? : N | ∃Array′ •
index? ∈ domarray
array index? = θData
array′ = array ⊕ {index? θData′}]
[Array; ∆Data; index? : N | ∃ array′ : seq Data •
index? ∈ domarray
array index? = θData
array′ = array ⊕ {index? θData′}]
198 13 / Promotion Simplifying the predicate part using the one-point rule to eliminate the quan-
tification of array′, we obtain ∃Array′ •Promote
[Array; ∆Data; index? : N | index? ∈ domarray
array index? = θData
array ⊕ {index? θData′} ∈ seq Data]
Given that index? ∈ domarray, the last of these conditions requires only that θData′ ∈ Data. Thus
∃Array′ •Promote
[Array; ∆Data; index? : N | index? ∈ domarray
array index? = θData θData′ ∈ Data]
The predicate above places no constraint on θData′, other than the requirement that it meets the constraint of Data. It is then a simple matter to show that
∃ Data′ • ∃ Array′ • Promote ⇒ ∀ Data′ • ∃ Array′ • Promote using the rules for existential elimination and universal introduction.
A promotion that is not free is said to be constrained. In general, con- strained promotions are not as elegant: they lack the modularity that freeness implies. However, there are situations in which a constrained promotion is the natural solution.
Example13.8 Wewishtomodelastackofdataobjects,eachofwhichcontains a piece of data and a priority value:
PriData priority : N data : Data
The objects in the stack are ordered with respect to their priority values. If object a has a lower index than object b—if it is nearer the top of the stack— then it must have a higher priority value:
13.3 / Free and constrained promotion 199 Stack
stack : seq PriData
∀ i , j : dom stack | i < j • (stack i ).priority ≥ (stack j ).priority
At any time, only the data object with the highest priority may be operated upon: that is, the object at the head of the stack. Our promotion schema includes this condition:
Promote ∆Stack ∆PriData
stack ≠ ⟨⟩
θPriData = head stack
stack′ = ⟨θPriData′⟩ ⌢ tail stack
The constraint of the promotion schema states that the stack must be non- empty, and that any change is made to the object at the head of the sequence. In this description, the global state invariant refers to a component of the indexed local state: the priority value. In an arbitrary operation, there may be local after-states which violate the global state invariant. Consider the case in
which the stack contains two objects:
stack = ⟨⟨|priority 3, data a|⟩, ⟨|priority 2, data b|⟩⟩ In an operation, the state of the first object may change to
⟨|priority 3,data c|⟩
so at least one after-state exists, but after-states such as
⟨|priority 1,data c|⟩ are disallowed. Hence
∃ PriData′ • ∃ Stack′ • Promote ̸⇒ ∀ PriData′ • ∃ Stack′ • Promote
and the promotion is constrained. Having observed this, we might decide to strengthen the predicate part of Promote in the hope of achieving a free pro- motion, or we may decide that the existing promotion is an entirely suitable description of our system.
Chapter 14
Preconditions
The construction of an abstract data type presents two important proof op- portunities. The first involves a demonstration that the various requirements upon the data type are consistent and not contradictory. The second involves a demonstration that each operation is never applied outside its domain, in a situation for which the results of the operation are not defined.
If the language of schemas is used to construct the data type, then these opportunities present themselves as simple mathematical tasks. To show that the requirements are consistent, we have only to show that the constraint part of the state schema is satisfiable. This is usually achieved by proving an initial- isation theorem: we show that an initial state, at least, exists.
To show that the operations are never applied outside their domain, we must investigate their preconditions. These may be calculated from the opera- tion schemas using the one-point rule. In this chapter, we explain the procedure for calculating preconditions, and show how it may be simplified by the use of structuring techniques such as promotion.
14.1 The initialisation theorem
In the previous chapters we have seen how the behaviour of a system may be described in terms of an abstract data type. The state of the system was modelled as an object of schema type, the predicate part of which represented a state invariant: a list of requirements that should be true in any valid state.
Clearly, if this includes a contradiction, then the data type description is vacuous: it is impossible to fulfil the requirements, therefore no state exists. To check that this is not the case, and that our specification is of some use, it is enough to establish that at least one state exists.
202 14 / Preconditions
If the description is to be useful, then there must also exist an initial state. As we saw in Example 12.11, this is usually characterised by a decorated schema, representing the state after initialisation. This is an obvious candidate for our proof of consistency.
Suppose that State describes the state of the system, and that StateInit characterises the initial state. If we can prove that
∃ State′ • StateInit
then we have shown that an initial state exists, and hence also that the re- quirements upon the state components are consistent. This result is called the initialisation theorem for the data type.
Example 14.1 In the case of the box office system, the initial state was charac- terised by
BoxOfficeInit BoxOffice′
seating′ = initial allocation sold′ = ∅
The initialisation theorem is therefore
∃ BoxOffice′ • BoxOfficeInit
The initialisation theorem is an easy one to prove, unless there are compli- cated initial conditions. Most often, the initial state is described uniquely with a number of equations, so the proof strategy is simple: eliminate the quantified variables. Once this has been done, the truth of the predicate should follow immediately from the properties of the mathematical objects involved.
Example 14.2 In the case of the box office, we may proceed as follows: ∃ BoxOffice′ • BoxOfficeInit
∃ BoxOffice′ • [definition of BoxOfficeInit ] [BoxOffice′ |
seating′ = initial allocation ∧ sold′ = ∅]
14.2 / Precondition investigation
∃ BoxOffice′ •
seating′ = initial allocation ∧ sold′ = ∅
∃ seating′ : P Seat • ∃sold′:Seat→ Customer•
dom sold′ ⊆ seating′ ∧ seating′ = initial allocation ∧ sold′ = ∅
initial allocation ∈ P Seat ∧ ∅ ∈ Seat → Customer
203
[schema quantification]
[definition of BoxOffice′]
[one-point rule, twice]
The proof may be completed by recalling the axiomatic definition of constant initial allocation, which is indeed of type PSeat, and expanding the definition of the generic symbol → .
14.2 Precondition investigation
The precondition of an operation schema describes the set of states for which the outcome of the operation is properly defined. If Operation is an operation schema, then we write
pre Operation
to denote the precondition of Operation. This is another schema, and is ob- tained from Operation by hiding any components that correspond to the state after the operation, and any outputs that happen to be present.
If the state of the system in question is modelled by a schema State, and outputs is the list of outputs associated with the operation, then the following equation defines the precondition schema:
pre Operation = ∃ State′ • Operation \ outputs
This schema characterises the collection of before states and inputs for which
some after state can be shown to exist.
Example 14.3 The precondition of the operation schema Purchase0, which de-
scribes the effect of a successful purchase, is given by
pre Purchase0
= ∃ BoxOffice′ • Purchase0 [definition of pre ]
204
14 / Preconditions [definition of BoxOffice′]
[one-point rule, twice]
[property of ‘dom’]
= [BoxOffice; s? : Seat; c? : Customer | ∃seating′ :PSeat;
sold′ : Seat → Customer | dom sold′ ⊆ seating′ •
s? ∈ seating \ dom sold sold′ =sold∪{s?c?} seating′ = seating]
= [BoxOffice; s? : Seat; c? : Customer | dom(sold ∪ {s? c?} ⊆ seating ∧
s? ∈ seating \ dom sold]
= [BoxOffice; s? : Seat; c? : Customer •
s? ∈ seating \ dom sold]
The predicate part of Purchase0 identifies an after-state that satisfies the state invariant only if the chosen seat s? has been allocated and not sold. The effect of Purchase0 is defined only when
s? ∈ seating \ dom sold
Notice that the actual precondition includes additional declaration and con- straint information. The effect of the operation is properly defined only if the initial values of seating and sold satisfy the constraint of BoxOffice and s? is an element of Seat.
In many cases, the precondition for an operation may be obvious to the writer of the specification. For example, the precondition of Purchase0—see the above example—was sufficiently obvious to be included in the operation schema. In general, we might wish to concentrate upon what the operation is supposed to do, and calculate the precondition later. In the specification process, such cross-checking can be useful.
Example 14.4 A simple control system monitors the entry and exit of vehicles from a car park. It maintains a count of the number of vehicles presently inside; this count should never exceed capacity, an integer number greater than zero:
CarPark count : N
count ≤ capacity
We may define an operation Exit0 that describes the successful departure of a car from the parking area:
14.2 / Precondition investigation 205 Exit0
∆CarPark
count′ =count−1
It might seem that this schema would apply to all states of the system, in that we are not placing any explicit constraint upon count. However,
pre Exit0
= ∃ CarPark′ • Exit0
= [CarPark | ∃count′ : N |
count ′ ≤ capacity • count ′ = count − 1]
= [CarPark | count − 1 ∈ N]
[definition of Exit0] [definition of CarPark′]
[one-point rule]
Because of the state invariant, this operation should be restricted to those states in which the count variable is strictly greater than 0. The effect upon other states is undefined. By calculating the precondition, we have identified a pos- sible source of error.
To see why Exit0 alone might be an unsatisfactory description of the exit operation, suppose that there is a way for cars to enter the car park unobserved. In this case, the function that implements the exit operation may be called while the value of count is 0. The subsequent value of count, according to Exit0, conflicts with our choice of data representation: anything could happen.
Now that the problem has been detected, we may choose to totalise the operation using a second schema to describe the effect of a car leaving when the system believes that the car park is empty:
ExtraCar ΞCarPark r! : Report
count = 0
r! = extra car
Assuming that a suitable type of reports is introduced, we may define
Exit = Exit0 ∨ ExtraCar
and be sure that all of the possibilities are catered for.
206 14 / Preconditions 14.3 Calculation and simplification
The process of calculating preconditions is both straightforward and routine. Indeed, much of the hard work can be carried out using some form of theo- rem prover or mechanical proof assistant. Suppose that we wish to find the precondition of the following operation schema:
Operation Declaration
Predicate
where Declaration represents the declaration part of Operation, and Predicate
the predicate part. To calculate the precondition of Operation,
1. divide Declaration into three parts:
• Before containing only inputs and before components (unprimed state components)
• After containing only outputs and after components (primed state components)
• Mixed containing all other declarations and inclusions
2. if Mixed is not empty, expand every schema mentioned in Mixed; add all input and before components to Before; add all output and after components to After. As there may be several levels of schema inclusion, repeat this step until Mixed is empty.
3. the precondition of Operation is then Before
∃After • Predicate
Example 14.5 To see how this recipe for preconditions may be applied, con- sider the following state schema definitions:
14.3 / Calculation and simplification 207
ST a:N S b:N c:N
a≠b b≠c
and suppose that we wish to calculate the precondition of the following oper- ation schema:
Increment ∆T
in? : N out! : N
a′ =a+in? b′ = b
c′ =c
out! = c
The first step of our recipe requires that we divide the declaration part of the schema into three parts:
Before = {‘in? : N’} After = {‘out! : N’} Mixed = {‘∆T ’}
The second step requires us to empty the third part, Mixed, by expanding schema definitions and separating input, output, before and after components. The result is
Before = {‘in? : N’, ‘T ’} After = {‘out! : N’,‘T′’} Mixed = {}
The precondition of Increment is then given by
208
14 / Preconditions
T
in? : N
∃out!:N; T′ • a′ =a+in?
b′ = b c′ =c out! = c
As we can see from the last example, the precondition schema obtained after the third stage of the recipe may be quite complicated. It is usually possi- ble to simplify the predicate part of a precondition schema using the one-point rule. For a precondition schema
Before
∃After • Predicate
we may proceed as follows:
4. expand any schemas in After that contain equations identifying outputs or after components
5. expand any schemas in After that refer to outputs or after components for which we already have equations
6. if Predicate contains an equation identifying a component declared in After, then use the one-point rule to eliminate that component; repeat this step as many times as possible
7. if After1 and Predicate1 are what remains of After and Predicate, then the precondition is now
Before
∃After1 • Predicate1
14.3 / Calculation and simplification 209
Example 14.6 The precondition of Increment, calculated in the last example, can be greatly simplified using the remaining part of the recipe. Its predicate part is currently
∃out!:N; T′ • a′ =a+in?
b′ = b c′ =c out! = c
Looking at Step 5 of the recipe, we expand T′, as it contains a declaration of an after component for which we have an equation:
∃out!:N; S′; c′ :N|b′ ≠c′ • a′ =a+in?
b′ = b c′ =c out! = c
The same is true of S′, so we follow this step again:
∃out!:N; a′ :N; b′ :N; c′ :N|a′ ≠b′ ∧b′ ≠c′ • a′ =a+in?
b′ = b c′ =c out! = c
There are no more schemas to expand, so we proceed to Step 6. The one-point rule can be applied four times, yielding the predicate
a + in? ≠ b b≠c
a + in? ∈ N b∈N c∈N
This is as far as the recipe takes us. However, all but one of these conjuncts follow immediately from the declarations in the precondition schema:
in? : N T
210 14 / Preconditions Removing the redundant information from our predicate, we obtain the final
simplified form of ‘pre Increment’: in? : N
T
a + in? ≠ b
14.4 Structure and preconditions
The process of calculating preconditions can be further simplified by consid- ering the structure of an operation. If an operation schema is defined to be the disjunction of several partial operations, or if an operation is defined using promotion, then we may be able to save time and effort by factoring out part of the calculation.
The simplest case is that of disjunction. If an operation schema Op is defined to be the disjunction of two or more operation schemas, then we may make use of the fact that the precondition operator ‘pre’ distributes through disjunction. For example, if
Op = Op1 ∨ Op2 then we may conclude that
preOp = preOp1 ∨preOp2
This result follows immediately from the definition of ‘pre’, given the following
theorem of our predicate calculus:
∃A•P∨Q ∃A•P∨∃A•Q
Existential quantification distributes through disjunction.
Example 14.7 The Purchase operation was defined as a disjunction of two par- tial operations
Purchase = (Purchase0 ∧ Success) ∨
(NotAvailable ∧ Failure)
14.4 / Structure and preconditions 211 Using the distributive property of ‘pre’, we may observe that
pre Purchase = pre (Purchase0 ∧ Success) ∨
pre (NotAvailable ∧ Failure)
We may calculate the preconditions of the two partial operations—Purchase0 ∧ Success and NotAvailable ∧ Failure—separately, and combine them to obtain the precondition of Purchase.
The ‘pre’ operator does not necessarily distribute through conjunction. If Op = Op1 ∧ Op2 then pre Op may not be equivalent to pre Op1 ∧ pre Op2. However, this will be the case whenever one of the schemas contributes nothing to the precondition.
Example 14.8 In Example 12.8, the schema Success was defined to be Success
r! : Response r! = okay
This schema imposes no constraint upon the before components of the box of- fice state, neither does it describe any input. It therefore makes no contribution to the precondition of an operation, and we may observe that
pre (Purchase0 ∧ Success) = pre Purchase0
If an operation is defined using a free promotion, then its precondition may be expressed in terms of the precondition of a local operation. If Promote is a free promotion, then the equivalence
∃ Local′ • ∃ Global′ • Promote ∀ Local′ • ∃ Global′ • Promote (∗) must hold; this follows from the definition at the start of Section 13.3. Now
consider the precondition of GOp, the promotion of a local operation LOp:
pre GOp
∃Global′ • GOp
∃ Global′ • ∃ ∆Local • Promote ∧ LOp ∃ ∆Local • ∃ Global ′ • Promote ∧ LOp
[definition of ‘pre’] [definition of GOp] [property of ∃]
212
14 / Preconditions
∃ ∆Local • (∃ Global ′ • Promote) ∧ LOp
[Global′ does not appear in LOp]
∃ Local • (∃ Local′; Global′ • Promote) ∧ ∃ Local′ • LOp
[free promotion]
∃ Local • pre Promote ∧ pre LOp [definition of ‘pre’, twice]
The equivalence justified by the phrase ‘free promotion’ can be derived from the equivalence labelled ‘∗’ using the proof rules for existential introduction and universal elimination.
The result that we have established can be stated as follows: under a free promotion, the precondition of a global operation is a conjunction of two preconditions—the precondition of the local operation, and the precondition of the promotion. We might say that the precondition of the local operation has itself been promoted.
Example 14.9 The description of a data array in Example 13.3 included a global operation AssignIndex defined by
AssignIndex = ∃∆Data•AssignData∧Promote
This is a free promotion, so the precondition of AssignIndex is given by
preAssignIndex = ∃Data•prePromote∧preAssignData
The local operation AssignData is total: the constraint part of pre AssignData
is simply true precondition. The promotion schema Promote was defined by
Promote ∆Array ∆Data index? : N
index? ∈ domarray
{index?} −▹ array = {index?} −▹ array′ array index? = θData
array′ index? = θData′
The precondition of Promote adds the constraint index ? ∈ dom array . The precondition of AssignIndex is therefore
14.4 / Structure and preconditions 213
Array new? : N index? : N
index? ∈ domarray
The separation of concerns afforded by the free promotion is not possible where the promotion is constrained. In such cases, the precondition of a pro- moted operation is calculated by first conjoining the local operation and the promotion schema and then applying the existential quantifier.
Example 14.10 In the prioritised data stack of Example 13.8, we propose a local operation that sets the priority of the top element to 100:
SetPriority ∆PriData
priority′ = 100 data′ = data
We may promote this operation to the global operation
SetPriorityStack = ∃ ∆PriData • SetPriority ∧ Promote where the promotion schema Promote is defined by
Promote ∆Stack ∆PriData
stack ≠ ⟨⟩
θPriData = head stack
stack′ = ⟨θPriData′⟩ ⌢ tail stack
This insists that the stack is non-empty. We may calculate the precondition of SetPriorityStack as follows:
pre SetPriorityStack
∃ Stack′ • SetPriorityStack [definition of ‘pre’] ∃ Stack′ • ∃ ∆PriData • Promote ∧ SetPriority
214 14 / Preconditions
[definition of SetPriorityStack] ∃ ∆PriData • ∃ Stack′ • Promote ∧ SetPriority [property of ∃]
∃ ∆PriData • (∃ Stack′ • Promote) ∧ SetPriority
[Stack′ does not appear in SetPriority]
At this point, we calculate the value of ∃ Stack′ • Promote, and obtain Stack
∆PriData
stack ≠ ⟨⟩
θPriData = head stack
∀ j : dom tail stack • θPriData′.priority ≥ (stack j).priority
In conjunction with SetPriority, this yields Stack
∆PriData
stack ≠ ⟨⟩
θPriData = head stack
θPriData′.priority = 100
θPriData′.data = θPriData.data
∀ j : dom tail stack • θPriData′.priority ≥ (stack j).priority
Following on from the argument above, we may obtain the precondition of SetPriorityStack by quantifying this schema with ∃ ∆PriData, yielding
Stack stack ≠ ⟨⟩
∀ j : dom tail stack • 100 ≥ (stack j ).priority
For the operation to be defined: the stack must be non-empty; every priority value in the tail of the stack must be less than 100; the stack must be ordered according to decreasing priority values.
A very different result would be obtained by factoring the precondition calculation as if it were a free promotion. The constraint part of pre SetPriority is simply true: there is no restriction at the level of the data objects. The schema
∃ PriData′ • pre Promote ∧ pre SetPriority
14.4 / Structure and preconditions 215 is equivalent to
Stack stack ≠ ⟨⟩
This schema that omits an essential part of the precondition: the constraint that every object in the tail of the stack has a priority lower than 100.
The missing constraint appears when we combine the information from the local operation—that the new priority value is 100—with the invariant property of the global state. If we hide the new priority value before combining the two schemas, then this information is lost.
Any investigation of the initialisation and preconditions of a specification should be properly recorded. A useful convention, followed by many practi- tioners, involves tabulating the results of the investigation. In such a table, we may find related partial operations listed together: any overall precondition is then easily established.
Example 14.11 In our theatre box office system, the constraint part of the ini- tialisation schema is simply true. No initial input is required: the initial value of seating is simply that of some global variable initial allocation.
The Purchase and Return operations were both total. Each is the disjunc- tion of two partial operations, Purchase being defined by
Purchase = (Purchase0 ∧ Success) ∨ (NotAvailable ∧ Failure) and Return by
Return = (Return0 ∧ Success) ∨ (NotPossible ∧ Failure)
Each total operation involves two inputs—s? and c?—and a single output—r!. Having calculated the preconditions, we may collect the results together in a single table: see Table 14.1.
216 14 / Preconditions
Operation
Precondition
BoxOfficeInit
true
Purchase0 NotAvailable Success Purchase
s? ∈ seating \ dom sold s? ̸∈ seating \ dom sold true
true
Return0 NotPossible Failure Return
s? c? ∈ sold s? c? ̸∈ sold true
true
Table 14.1 Preconditions in the box office system
Chapter 15
A File System
In this chapter, we present the first of several case studies using Z. We show how the schema notation can be used to specify a simple file system: representing concrete data structures and a set of operations upon them. We show also how the preconditions of the various operations can be calculated, and how the description of a single file can be promoted to an indexed component of a file system.
15.1 A programming interface
We will begin by setting down exactly what it is that we intend to model. In this case, it is the programming interface to a file system. This is a list of operations upon the file system, complete with a description of their intended effects. For example: the operation create may be used to create a new file, and the operation read may be used to obtain data from an existing file.
We may divide the operations into two groups: those that affect the data within a single file, and those that affect the file system as a whole. At the file level, there are four operations:
• read: used to read a piece of data from a file;
• write: used to write a piece of data to a file;
• add: used to add a new piece of data to a file;
• delete: used to delete a piece of data from a file.
The operations add and write are quite different. The first will extend the file to accommodate the new data, while the second will overwrite an existing part of the file.
218 15 / A File System The remainder of the programming interface consists of operations upon
the file system. We will consider four of these:
• create: used to create a new file;
• destroy: used to destroy an existing file;
• open: used to make a file available for reading and writing of data; • close: used to make a file unavailable for reading and writing.
Of these, the first two may be seen as file management operations, while the others may be seen as file access operations upon the file system.
15.2 Operations upon files
We will represent each file using a relation between storage keys and data ele- ments. For the purposes of this specification, we may suppose that keys and data are drawn from basic types:
[Key,Data]
In more elaborate descriptions, there may be more to a file than simply its con- tents. To keep our specification both flexible and extensible, we use a schema to describe the structure of a file:
File
contents : Key → Data
A file should not associate the same key with two different pieces of data, hence the requirement that the relation contents should be a partial function.
When a file is initialised, it contains no data, so the value of contents should be the empty function. The following schema describes the initial state of a file:
FileInit File′
contents′ = ∅
The schema File corresponds to a set of bindings, each with a single component contents. The schema FileInit corresponds to a much smaller set of bindings, the singleton set {⟨|contents ∅|⟩}.
15.2 / Operations upon files 219 To describe an operation which may change the contents of a file, we will
include two copies of the file state:
∆File File File′
If an operation leaves the contents of a file unchanged, then we will add the condition that the binding remains the same:
ΞFile ∆File
θFile = θFile′
This schema will be included whenever an operation merely interrogates the file state.
A successful read operation requires an existing key as input and provides the corresponding datum as output:
Read0 ΞFile
k? : Key d! : Data
k? ∈ dom contents d! = contents k?
There are no side effects to this operation.
A successful write operation replaces the datum stored under an existing
key, and provides no output:
Write0 ∆File
k? : Key d? : Data
k? ∈ dom contents
contents′ = contents ⊕ {k? d?}
The old value of contents is updated with a maplet associating k? with a second input d?.
220 15 / A File System A successful add operation has a complementary precondition. This time,
the key k? must not be in the domain of contents:
Add0 ∆File
k? : Key d? : Data
k? ̸∈ dom contents
contents′ = contents ∪ {k? d?}
Again, there is no output from this operation.
Finally, a successful delete operation requires only that the key in question
exists. A single input is required, and the state of the file will change:
Delete0 ∆File k? : Key
k? ∈ dom contents contents′ = {k?} −▹ contents
The effect of removing the key is modelled using domain co-restriction: the maplet starting at k? is removed from contents.
15.3 A more complete description
Thus far, we have described only partial operations upon files. For each op- eration, there are circumstances in which the effect upon the file state is not fully defined. For example, we have not explained what happens if an attempt is made to add data using a key that is already in use. We will now extend our description to cover every eventuality.
We will add a type of reports to our formal specification, allowing us to provide some output whether or not the operation is successful:
Report ::= key in use | key not in use | okay
A failed operation upon the file state will always produce a report as output. It will prove convenient to include the following schema:
15.3 / A more complete description 221
KeyError ΞFile
k? : Key
r! : Report
An error may arise because the specified key is not in use,
KeyNotInUse KeyError
k? ̸∈ dom contents r!=key not in use
or because the specified key is in use, KeyInUse
KeyError
k? ∈ dom contents
r!=key in use
A successful operation will always produce a report of the same value:
Success
r! : Report
r! = okay
We are now ready to define a collection of total operations: schemas in which
the state before may be any valid file state:
Read = (Read0 ∧ Success) ∨ KeyNotInUse Write = (Write0 ∧ Success) ∨ KeyNotInUse
Add = (Add0 ∧ Success) ∨ KeyInUse Delete = (Delete0 ∧ Success) ∨ KeyNotInUse
The four operations Read, Write, Add, and Delete have been built up in a struc- tured fashion from small components. This avoids any duplication of effort, allowing us to factor out common aspects of the design, and results in a clearer, more comprehensible specification.
In larger case studies and industrial applications, a structured approach is essential if the reader is not to be overwhelmed by detail. As an indication
222 15 / A File System
of the amount of information that might be involved, consider the following schema, an expanded version of the operation schema used to describe the read operation:
contents, contents′ : Key → Data k? : Key
d! : Data
r! : Report
( k? ∈ dom contents ∧ d! = contents k? ∧ contents′ = contents ∧ r! = okay )
∨
( k? ̸∈ dom contents ∧
contents′ = contents ∧ r!=key not in use)
The output d! can take any value if the specified key is not in use. 15.4 A file system
A file system contains a number of files indexed using a set of names. In this specification, we will regard the set of names as a basic type:
[Name]
In our description of the system, we will consider two aspects of a file system state: the collection of named files known to the system, and the set of files that are currently open:
System
file : Name → File open : P Name
open ⊆ dom file
It is important that the system should not associate the same name with two different files: file must always be functional.
When the file system is initialised, there are no files. The partial function file is empty, as is the set open. As the state invariant insists that every open
15.4 / A file system 223 file is also recorded in file, it is enough to insist that file = ∅:
SystemInit System′
file′ = ∅
Again, the following pair of schemas will be useful when we come to describe
file system operations:
∆System = [System; System′]
ΞSystem = [∆System | θSystem = θSystem′]
Both of these schemas insist that the state invariant is preserved: file must remain functional, and open must remain within its domain.
Since the state of our file system includes indexed copies of File, we may choose to promote the operations defined above. The local state is described by File, the global state is described by System, and the promotion is characterised by the schema
Promote ∆System ∆File
n? : Name
n? ∈ open
file n? = θFile
file′ n? = θFile′
{n?} −▹ file = {n?} −▹ file′ open′ = open
which uses the indexing function file to explain the relationship between local and global states.
We define four operations using this promotion:
KeyRead0 = ∃ ∆File • Read ∧ Promote KeyWrite0 = ∃ ∆File • Write ∧ Promote KeyAdd0 = ∃ ∆File • Add ∧ Promote KeyDelete0 = ∃ ∆File • Delete ∧ Promote
Although each local operation is total, the file in question may not be open. The resulting global operations are partial.
224 15 / A File System
The operations open and close do not change the name of any file, neither do they add or remove files from the system. They may be described as file access operations, in that they may change the availability of a file for reading and writing. In the formal descriptions of these operations, we will find the following schema useful:
FileAccess ∆System n? : Name
n? ∈ dom file file′ = file
This schema describes an operation upon the file system in which the indexing function file is left unchanged. It insists also that the input component n? describes a file that is known to the system.
A successful open operation adds a name to the list of open files. Open0
FileAccess n? ̸∈ open
open′ = open ∪ {n?}
This operation is strictly partial. An open operation will fail if the name sup- plied denotes a file that is already open. This possibility is excluded above.
A successful close operation removes a name from the list of open files: Close0
FileAccess n? ∈ open
open′ = open \ {n?}
Again, this operation is strictly partial. A close operation will fail if the name supplied does not denote an open file. This possibility is excluded above.
The remaining operations, create and destroy, are file management opera- tions. They may change the list of files known to the system, but they should not affect the list of open files. As with FileAccess, we may use a single schema to describe the information that is common to both operations:
15.4 / A file system 225
FileManage ∆System n? : Name
open′ = open
This schema insists that the set of open files is preserved.
A successful create operation adds a new name to the list of files known to
the system:
Create0 FileManage
n? ̸∈ dom file ∃FileInit •
file′ = file ∪ {n? θFile′}
Immediately after this operation, the state of the file associated with name n? is described by the binding θFileInit. That is, n? is associated with a binding of schema type File in which contents is bound to the empty set.
A successful destroy operation removes a name from the list of files, do- main co-restricting the function file:
Destroy0 FileManage
n? ∈ dom file file′ = {n?} −▹ file
We require that the name n? already exists.
We might also wish to insist that n? is not an element of open, thus prevent-
ing the destruction of open files. However, this condition is already enforced by the predicate part of FileManage—which insists that this operation should not affect the list of open files—acting in combination with our state invariant open ⊆ dom file. If we cannot remove n? from open, then we cannot remove n? from the domain of file.
We will now extend our free type of report messages to take account of the errors that may occur in file access and file management operations:
Report::=key in use|key not in use|okay|file exists| file does not exist | file is open | file is not open
This definition replaces the one given earlier.
226
15 / A File System If an error occurs, then the system state will be left unchanged:
FileError ΞSystem n? : Name r! : Report
This information will be common to each of the error cases that we encounter in specifying operations at the system level.
If we attempt to create a file using a name that is already in use, we will receive a report complaining that a file with that name exists:
FileExists FileError
n? ∈ dom file r! = file exists
Conversely, if we attempt to destroy a file using a name that is not in use, we will receive a report complaining that the file does not exist:
FileDoesNotExist FileError
n? ̸∈ dom file
r! = file does not exist
Sometimes a file will be open when it should be closed,
FileIsOpen FileError
n? ∈ open r!=file is open
and sometimes a file will be closed when it should be open,
FileIsNotOpen FileError
n? ∈ dom file
n? ̸∈ open
r!=file is not open
15.5 / Formal analysis 227
We are now ready to describe the interface to the file system. There are four operations involving the contents of files: KeyRead, KeyWrite, KeyAdd, and KeyDelete. In each case, if the file exists and is open, then the effect of the operation is described by a promoted file operation:
KeyRead = KeyRead0 ∨ FileIsNotOpen ∨ FileDoesNotExist KeyWrite = KeyWrite0 ∨ FileIsNotOpen ∨ FileDoesNotExist KeyAdd = KeyAdd0 ∨ FileIsNotOpen ∨ FileDoesNotExist KeyDelete = KeyDelete0 ∨ FileIsNotOpen ∨ FileDoesNotExist
We may complete the definitions of the access and management operations using a similar combination of error cases:
Open = (Open0 ∧ Success) ∨ FileIsOpen ∨ FileDoesNotExist
Close = (Close0 ∧ Success) ∨ FileIsNotOpen ∨ FileDoesNotExist Create = (Create0 ∧ Success) ∨ FileExists
Destroy = (Destroy0 ∧ Success) ∨ FileDoesNotExist ∨ FileIsOpen This completes our formal description of the file system.
15.5 Formal analysis
A formal description of a programming interface is useful indeed: it provides a clear, unambiguous account of the operations available, and explains their ef- fects upon the state. It raises a number of important issues—can we destroy an open file?—and acts as a source document to resolve the uncertainties inherent in our natural language explanation of the file system’s behaviour.
However, there may be errors or contradictions within this formal descrip- tion. There may be conflicting assumptions about system behaviour, in which case our formal design may be impossible to implement. Alternatively, there may be hidden assumptions within an operation schema, leading to circum- stances in which the effect of the operation is not explained.
Accordingly, we should undertake some formal analysis. Without too much effort, it is possible to conduct an investigation of our formal design. We be- gin by checking that our state invariant contains no contradictions. We may establish this by proving the initialisation theorem
∃ SystemInit • true
228 15 / A File System
That is, that there exists a binding of file and open which satisfies the constraint part of SystemInit.
An outline proof of the theorem is easily constructed. Expanding the schema definition of SystemInit and applying the one-point rule to file′, we find our- selves with an existential statement concerning the empty set. This is easily divided into two statements—labelled [2] and [3] below—about ‘P’ and ‘dom’, which we may take as valid or prove at our leisure:
∅∈PName [2] ∅⊆dom∅ [3]
∃open′ : PName | ∅∈Name→ File [1] open′ ⊆dom∅•true
[∃−intro]
∃file′ :Name→ File; open′ :PName| open′ ⊆ domfile′ ∧ file′ = ∅ • true
∃ SystemInit • true
[one-point rule] [definition]
The result labelled [1] is also immediate, since we require only that file is a partial function from Name to File. This is true of the empty function, even if File is an empty set.
Since we are using File as a type, we should also prove that ∃ File′ • FileInit
This is not required for the initialisation of the system, but it will form part of the precondition for any operation that requires at least one file to exist. The proof is easy to construct:
∅ ∈ Key → Data [4]
∃ contents′ : Key → Data | contents′ = ∅ • true [one-point rule]
∃ FileInit • true
As Key and Data are basic types, we know that they cannot be empty. Hence the empty relation is an element of Key → Data, and an initial state exists.
The second part of our investigation involves calculating the precondition of each operation. As an example, consider the operation KeyRead, defined by
KeyRead = KeyRead0 ∨ FileDoesNotExist ∨ FileIsNotOpen
Since the ‘pre’ operator distributes through disjunction, we know that
preKeyRead
pre KeyRead0 ∨ pre FileDoesNotExist ∨ pre FileIsNotOpen
[definition]
15.5 / Formal analysis 229 If we recall the definition of FileDoesNotExist, we may observe that its precon-
dition is equivalent to
System n? : Name
∃r!:Report • n? ̸∈ dom file
r! = file does not exist
Using the one-point rule, we may rewrite the predicate part of this schema as n? ̸∈ domfile. Similarly, we may establish that pre FileIsNotOpen has the constraint n? ∈ dom file ∧ n? ̸∈ open.
The first disjunct requires a little more work. The operation KeyRead0 was defined by promoting the local operation Read:
KeyRead0 = ∃ ∆File • Read ∧ Promote
The combination of System, File, and Promote makes for a free promotion. We
can prove this by starting with the schema
∃ File′ • ∃ System′ • Promote
and applying the definition of Promote to yield
[ n? : Name; File; System | ∃File′ •∃System′ •
n? ∈ open ∧
file n? = θFile ∧
file′ n? = θFile′ ∧
{n?} −▹ file = {n?} −▹ file′ ∧ open′ = open ]
We can rewrite this expression to obtain equalities for both file′ and open′ are both uniquely defined:
∃File′ •∃System′ • n? ∈ open ∧
file n? = θFile ∧
file′ =file⊕{n?θFile′}∧ open′ = open ]
230 15 / A File System Applying the existential one-point rule to the components of System′, we obtain
∃File′ •
open ⊆ dom file ⊕ {n? θFile′} ∧
n? ∈ open ∧
file n? = θFile ∧
file ⊕ {n? θFile′} ∈ Name → File ∧ open ∈ P Name ]
Using the properties of → and ⊕, we may rewrite the predicate within the quantifier to obtain:
∃File′ •
open ⊆ dom file ∧
n? ∈ open ∧
file n? = θFile ∧
file ∈ Name → File ∧ θFile′ ∈ File ∧
open ∈ P Name ]
It is now clear that there is no constraint upon θFile′ except that it is an element of File. Since this is the case, we can replace the existential quantification with a universal quantification over the same schema name:
∀File′ •∃System′ • n? ∈ open
file n? = θFile
file′ n? = θFile′
{n?} −▹ file = {n?} −▹ file′ open′ = open
This establishes the truth of the schema implication
∃ File′ • ∃ System′ • Promote ⇒ ∀ File′ • ∃ System′ • Promote and confirms that the promotion is free.
The precondition of KeyRead0 is given by
pre KeyRead0 = ∃ Local • pre Read ∧ pre Promote
Expanding the precondition schema ‘pre Read’, we find that its predicate part
15.5 / Formal analysis 231 is simply true. The remaining predicate information is contributed by the pro-
motion schema, which insists that the file in question is listed as open:
pre KeyRead0 n? ∈ open The precondition of KeyRead0 is then
System n? : Name
n? ∈ open
and the precondition of KeyRead is
System n? : Name
That is, KeyRead is a total operation.
We may document the results of our analysis in a table of preconditions:
see Table 15.1. For each operation, we list the partial operations used in its definition, together with their preconditions. In every case, the disjunction of these preconditions is true; our operations are total.
232
15 / A File System
Operation
Precondition
KeyRead KeyRead0 FileIsNotOpen
FileDoesNotExist KeyRead
n? ∈ open
n? ∈ (dom file) \ open n? ̸∈ dom file
true
KeyWrite KeyWrite0 FileIsNotOpen
FileDoesNotExist KeyWrite
n? ∈ open
n? ∈ (dom file) \ open n? ̸∈ dom file
true
KeyAdd KeyAdd0 FileIsNotOpen
FileDoesNotExist KeyAdd
n? ∈ open
n? ∈ (dom file) \ open n? ̸∈ dom file
true
KeyDelete KeyDelete0 FileIsNotOpen
FileDoesNotExist KeyDelete
n? ∈ open
n? ∈ (dom file) \ open n? ̸∈ dom file
true
Open Open0 FileIsOpen
FileDoesNotExist Open
n? ∈ (dom file) \ open n? ∈ open
n? ̸∈ dom file
true
Close Close0 FileIsNotOpen
FileDoesNotExist Close
n? ∈ open
n? ∈ (dom file) \ open n? ̸∈ dom file
true
Create Create0 FileExists
Create
n? ̸∈ dom file n? ∈ dom file true
Destroy Destroy0 FileIsOpen
FileDoesNotExist Destroy
n? ∈ (dom file) \ open n? ∈ open
n? ̸∈ dom file
true
Table 15.1 Summary of results
Chapter 16
Data Refinement
Writing a formal specification is a worthwhile activity in its own right: there is much to be gained from a good understanding and a simple description. However, we may also wish to develop a specification in such a way that it leads us towards a suitable implementation. This process of development is called refinement.
We may refine a formal specification by adding more information. For ex- ample, we might be more precise about how data is to be stored, or about how certain calculations are to be carried out. Clearly, it is important that our new, more detailed description is consistent with our original specification: the re- finement must be correct.
In this chapter we explain what it means for one partial relation to refine another. Then, using the concepts of forwards and backwards simulation, we develop a theory of refinement for abstract data types, including a set of rules for proving correctness.
16.1 Refinement
The Concise Oxford Dictionary (8th edition) contains the following definition:
refinement n. Refining or being refined; fineness of feeling or taste, polished manners etc.; subtle or ingenious manifestation of, piece of elaborate arrangement, (all the refinements of reasoning, torture; a countermine was a refinement beyond their skill); instance of improvement (up)on; piece of subtle reasoning, fine distinction.
234 16 / Data Refinement
Although the bit about subtle reasoning is amusing, the relevant words here are ‘instance of improvement upon’. For us, refinement is all about improving specifications.
The process of improvement involves the removal of nondeterminism, or uncertainty. An abstract specification may leave design choices unresolved; a refinement may resolve some of these choices, and eliminate some of the nondeterminism. Several refinement steps may be performed, each removing another degree of uncertainty, until the specification approaches executable program code.
Example16.1 Aresourcemanagerallocatesidenticalbutnumberedresources to client programs or users. Using a set of numbers to describe the free re- sources, the state of the system is characterised by the following schema:
ResourceManager free : FN
Any resource that is currently free may be allocated. The effect of an allocation is described by the following operation schema:
Allocate ∆ResourceManager r! : N
r!∈free ∧ free′ =free\{r!}
If there is more than one resource free, then this specification is nondetermin- istic. It is also partial: we have not explained what is to be done if there are no resources left to be allocated.
This specification may be refined by another in which we decide that, should there be more than one resource free, the resource with the lowest number should be allocated first. In this new specification, the effect of an allocation is described by
Allocate1 ∆ResourceManager r! : N
r! = minfree ∧ free′ = free \ {r!}
This specification is deterministic, provided that there is at least one resource to allocate. It is still partial.
16.1 / Refinement 235
A further refinement might explain that the resources are modelled by an array of bits, one bit per resource. A resource is free if the corresponding bit is set to 0. Assuming a suitable definition for ‘array of’, we may define
ResourceManager2 free2 : array of Bit
where Bit is the set containing just 0 and 1.
The effect of an allocation is determined by searching for the first bit that
is set to 0, starting from the lowest position. When this bit is found, it is set to 1 and its index is returned. If there are no 0 bits, an error report is generated. This specification respects the decision made in the previous refinement step: that the lowest numbered resource should be allocated. It is also total: the effect of an allocation is described in all circumstances.
Any client who is happy with the first specification will also be happy with the third. Of course, this two-step development could have been performed in a single, more complicated step in which the free set was implemented by the array directly, an allocation used the lowest index with an unset bit, and the specification was strengthened to add the error-handling.
Example 16.2 When the Parliament of the European Union passes legislation, it does so in the form of a European directive. Each of the member countries is then required to enact the legislation, and in the United Kingdom this is done by passing an Act of Parliament. Regulatory authorities, such as the Health and Safety Executive, produce regulations, which they then seek to enforce. These legal instruments are so arranged that compliance with the regulations implies compliance with the Act, and compliance with the Act implies compliance with the directive. It is usually the case that the regulations are rather more strict than the original directive, because the legislation has been through two stages of interpretation, each taking into account considerations peculiar to the United Kingdom. We might say that the Act is a refinement of the directive, and that the regulations are a refinement of the Act.
Example 16.3 For reasons that we are unable to explain, we would like to raise a million pounds sterling. One way to do this would be to raise the money in the United States of America. However, there is a problem with exchange rate fluctuations. At the time of writing, the exchange rate was £1.00 = $ 1.45, so we would need to raise $1,450,000 in the United States. If the exchange rate changes so that there is parity between the currencies, then we would have to
236 16 / Data Refinement
raise only $1,000,000; and if it changes so that there are two US dollars for each pound sterling, then we would need to raise $2,000,000.
To place a bound on the amount of US dollars we need to raise, we place a bound on the exchange rate. In our lifetime, the pound has never exceeded $2.40 in value. We can safely assume that, in the week in which we need to earn the money, £1.00 ≤ $2.40. A suitable refinement of our plan, therefore, might involve raising $2,400,000: we are then sure to achieve our target.
This particular form of refinement is called data refinement, in that we are changing the representation of data (money) from pounds to dollars. In the specification, any amount over £1,000,000 is acceptable; the implementation is stronger in insisting on over $2,400,000. It may be that this implementation is infeasible, in that it requires too much.
16.2 Relations and nondeterminism
We obtain a simple definition of refinement if we restrict our attention to total relations. If R and S are total relations, then R refines S exactly when R ⊆ S. Wherever S relates the same element x to two distinct elements y1 and y2, R may remove a degree of uncertainty by omitting either x y1 or x y2.
To decide if one partial relation refines another, we may consider their totalised versions. To do this, we augment the source and target of each relation with a distinguished element ⊥, denoting undefinedness. We may then add a set of pairs to any partial relation ρ, associating any element outside the domain of ρ with every element of the augmented target.
If ρ is a partial relation between types X and Y , then we may totalise ρ by adding the following set of pairs:
{x : X⊥; y : Y⊥ | x ̸∈ domρ • x y}
where X ⊥ and Y ⊥ denote the augmented versions of the source and target. For convenience, we will use the expression s to denote the complement of
a set s in its type. For example, if s is a set of type P X , then s={x:X|x∉s}
We will write ρ• to denote the totalised form of ρ, where ρ• ∈ X ⊥ ↔ Y ⊥
and
ρ• =ρ∪(domρ⊥×Y⊥)
16.2 / Relations and nondeterminism 237
aa bb cc
d
The expression ρ• can be pronounced ‘ρ-dot’. Example16.4 IfwedefineafreetypeLby
L ::= a | b | c | d and a relation ρ by
ρ == {aa,ab,bb,bc} then the totalised version of ρ is given by
•
ρ == {aa,ab,bb,bc,
c ⊥, c a, c b, c c, c d,
d ⊥, d a, d b, d c, d d, ⊥ ⊥, ⊥ a, ⊥ b, ⊥ c, ⊥ d}
This extension is shown in Figure 16.1.
d
Figure 16.1 Totalisation
Totalising relations in this way captures the view of operations that we have described in this book: an operation ρ behaves as specified when used within its precondition—its domain; outside its precondition, anything may happen. The role of ⊥ is to ensure that undefinedness is propagated through relational composition. To see this, suppose that κ0 denotes the constant function that maps every number to 0:
κ0 =={z:Z•z0}
238 16 / Data Refinement and consider the relational composition
•
∅ 9o κ 0
The first component—a lifted version of the empty relation—represents unde- finedness by associating every number with every other number: in computing terms, this might correspond to a run-time error being encountered whatever the initial value. If this is our intention, then the composition should have the same effect.
With the augmented types, the relational composition has precisely this interpretation:
•
•
∅ 9o κ 0
= (∅ ∪ (dom∅⊥ × Z⊥)) 9o (κ0 ∪ (domκ0⊥ × Z⊥)) [dot] = (∅⊥ × Z⊥) 9o (κ0 ∪ (Z⊥ × Z⊥)) [properties of ∪ and dom]
•
= (Z⊥ × Z⊥) 9o (κ0 ∪ (∅⊥ × Z⊥))
=((Z⊥ ×Z⊥)9o κ0)∪((Z⊥ ×Z⊥)9o ({⊥}×Z⊥)) = κ0 ∪ (Z⊥ × Z⊥)
= Z⊥ × Z⊥
[properties of ] [propertyof×] [properties of ×] [property of ∪]
Without the addition of an undefined element, we find that the composition recovers from the original undefinedness and behaves exactly as κ0:
•
∅ 9o κ 0
=(∅∪(dom∅×Z))9o (κ0 ∪(domκ0 ×Z)) =(∅×Z)9o (κ0 ∪(Z×Z))
=(Z×Z)9o (κ0 ∪(∅×Z))
=(Z×Z)9o (κ0 ∪∅)
=(Z×Z)9o κ0 = κ0
•
[dotwithout⊥] [propertiesof∪anddom] [propertiesof ] [propertyof×] [propertyof∪] [property of 9o]
With our interpretation of operations, this is overly generous; it suggests that a run-time error can be avoided by adding a subsequent operation.
Having decided upon totalisation using ⊥, we may derive the conditions for one partial relation to be a correct refinement of another. If σ and ρ are two partial relations of the same type, then σ refines ρ precisely when σ• is a subset of ρ•. This is true if and only if the domain of σ is at least as big as that of ρ and σ agrees with ρ on domρ.
16.2 / Relations and nondeterminism 239
The first of these conditions insists that σ is at least as defined as ρ, while the second insists that σ respects the information contained in ρ. Thus we may refine a relation by enlarging the domain, or by removing alternatives.
Example 16.5 If ρ is as defined in Example 16.4, and σ is defined by σ =={aa,bb,bc,cc}
then σ is a refinement of ρ. It has both extended the domain and resolved some of the nondeterminism. That is,
domσ = {a,b,c} ⊇ {a, b}
and
= dom ρ
domρ▹σ ={aa,bb,bc,} ⊆ρ
Equivalently,wemightobservethatσ• ⊆ρ•,since •
σ = {aa,bb,bc,cc,d⊥,da,db,dc,dd, ⊥ ⊥, ⊥ a, ⊥ b, ⊥ c, ⊥ d}
and each of these pairs is present in ρ• .
Example 16.6 If the relation τ is defined by τ == {aa,cc}
then τ is not a refinement of ρ, as
domρ = {a,b,c} ̸⊆ {a,c} = domτ
We can remove pairs to reduce nondeterminism, but not at the expense of restricting the domain.
Example16.7 Wemaycorruptabit—anelementoftheset{0,1}—bychanging its value:
240
16 / Data Refinement
∼ : Bit → Bit ∼0=1
∼1=0
The relation corruptsto associates two sequences of bits if the second is no
longer than the first, and no two adjacent bits have been corrupted:
corruptsto : seq Bit ↔ seq Bit
∀bs,bs′ :seqBit •
bs corruptsto bs′
#bs′ ≤ #bs ∧ ∀ i : 1 . . #bs′ − 1 •
bs i ≠ bs′ i ⇒ bs(i + 1) = bs′(i + 1)
For example,
⟨1,1,0,1,1,1,0,0⟩corruptsto⟨0,1,0,0,1⟩ ⟨1,0,0,0,1,1⟩corruptsto⟨1,0,1,0,0,1⟩
The relation changesto associates two sequences of bits if the second is no longer than the first and every bit with an odd index has been corrupted:
changesto : seq Bit ↔ seq Bit
∀bs,bs′ :seqBit •
bs changesto bs′
#bs′ ≤ #bs ∧ ∀ i : 1 . . (#bs′ − 1) •
i ∈ { n : N1 • 2 ∗ n } ⇒ bs i = bs′ i ∧
i ∈ { n : N • 2 ∗ n + 1 } ⇒ bs i ≠ bs′ i ⟨1,1,0,1,1,1,0,0⟩changesto⟨0,1,1,1,0⟩
⟨1,0,0,0,1,1⟩changesto⟨0,0,1,0,0,1⟩
In moving from corruptsto to changesto, we have traded the fact that in every output pair of bits, at least one is correct, for the fact that in every output pair of bits exactly one is correct.
The second relation is a refinement of the first: both are total relations on seqBit, and changesto resolves all of the nondeterminism present in the definition of corruptsto. If we are content with the behaviour of corruptsto, then we will be content with that of changesto. Indeed, we may be more so, as every bit with an even index is guaranteed to be correct.
For example,
16.3 / Data types and data refinement 241
16.3 Data types and data refinement
For our purposes, a data type comprises a space of values—or states—and an indexed collection of operations. Any use of the data type in a global state G must start with an initialisation and end with a matching finalisation. A data type X is thus a tuple (X , xi , xf , { i : I • xoi }), where
• X is the space of values;
• xi ∈ G ↔ X is an initialisation;
• xf ∈ X ↔G is a finalisation;
• {i : I • xoi } is an indexed collection of operations, such that xoi ∈ X ↔X
Both xi and xf are total, but each xoi may be partial.
For our purposes, a program is a sequence of operations upon a data type.
It may be seen as a relation between input and output, recorded by the initial- isation and finalisation steps at the beginning and end of this sequence. For example, the sequence di 9o do1 9o do2 9o df is a program that uses the data type D = (D, di, df , {do1, do2}).
The choice of data representation within the data type is not relevant to the overall behaviour of the program; it is encapsulated by initialisation and finalisation. Thus programs may be parameterised by data types: the above example could be written as P(D), where
P(X) = xi 9o xo1 9o xo2 9o xf
and X is a variable data type with a suitable index set.
If two abstract data types A and C use the same index set for their opera-
tions, then they will support the same selection of programs: for every program P(A), there must be a corresponding program P(C). What is more, any two pro- grams P(A) and P(C) will be comparable, since they have the same source and target sets.
We may find that the effect of P(C) is defined whenever the effect of P(A) is defined. We may find also that P(C) resolves some of the nondeterminism present in P(A). If this is the case for every choice of P, then it is reasonable to say that C is a refinement of A.
As in our theory of refinement for relations, we will find it convenient to consider totalisations. An abstract data type X may be totalised by augmenting each component:
••••
X = (X⊥,xi,xf,{i:I•xoi})
242 16 / Data Refinement
Since xi and xf are total, the process of totalisation does nothing but augment each of them with the set of pairs {⊥} × X ⊥.
We are now able to present a suitable definition of refinement for abstract data types. If data types A and C share the same indexing set, then A is refined by C if and only if for each program P(A)
•• P(C) ⊆ P(A)
If A and C are both indexed by the set I, then this definition requires us to prove that, for sequences ⟨s1,s2,...sn⟩ in seqI,
••• ••••• •• cioco oco o···oco ocf ⊆ aioao oao o···oao oaf
9 s19 s29 9 sn9 9 s19 s29 9 sn9
In practice, this may be a difficult result to establish. In the next section, we will see how this requirement may be simplified by considering the relationship between abstract and concrete values.
Example 16.8 We may define two data types for handling sequences of bits, A and C. Each will accept a sequence of bits at initialisation, and deliver another sequence at finalisation. In each case, the state space is defined as a collection of tuples:
A == seq Bit × Action × seq Bit C == seq Bit × Action × seq Bit
where Bit is the set containing just 0 and 1, and Action is defined by Action ::= yes | no
The first component of the state tuple represents the unconsumed part of the input sequence, the second indicates whether or not the next bit must be faith- fully reproduced, and the third represents the accumulated output.
The initialisation and finalisation operations are the same for both data types. Initially, the whole of the input sequence waits to be consumed, the output sequence is empty, and the next bit may be corrupted.
ai :seqBit↔A ci :seqBit↔C
∀ bs : seq Bit ; a : A; c : C • bs ai a a = (bs, no, ⟨⟩) bs ci c c = (bs, no, ⟨⟩)
16.3 / Data types and data refinement 243 Finally, any remaining input is discarded, as is the action component. The
accumulated output sequence is all that remains:
af :A↔seqBit cf :C↔seqBit
∀ bs : seq Bit ; a : A; c : C • a af bs bs = a.3
c cf bs bs = c.3
The effect of this operation is simply to project out the third component of the current state tuple.
Each data type has a single operation. That of A is nondeterministic: it may choose to act faithfully, appending the next input bit b to the output sequence. However, if the last bit was faithfully reproduced, it may choose to append the corrupted bit ∼b instead.
ao :A↔A
∀a,a′ :A•
aaoa′ a′.1=taila.1
a.2 = yes ⇒
a′.3 = a.3 ⌢ ⟨head a.1⟩ ∧ a′.2 = no
a.2 = no ⇒
a′.3 = a.3 ⌢ ⟨∼head a.1⟩ ∧ a′.2 = yes ∨
a′.3 = a.3 ⌢ ⟨head a.1⟩ ∧ a′.2 = no
Whenever a bit is corrupted, the action component of the next state is set to yes, indicating that the next bit must be appended faithfully.
In contrast, the operation of C is completely deterministic. It alternates between corruption and fidelity, changing the value of the action component each time it is applied. This has the effect of removing the disjunction from the above definition, leaving the state after fully determined by the state before.
co :C↔C
∀c,c′ :C •
ccoc′ c′.1=tailc.1
c.2 = yes ⇒
c′.3 = c.3 ⌢ ⟨head c.1⟩ ∧ c′.2 = no
c.2 = no ⇒
c′.3 = c.3 ⌢ ⟨∼head c.1⟩ ∧ c′.2 = yes
244 16 / Data Refinement
The relationship between A and C is the same as that between corruptsto and changesto in Example 16.7. That is, C is a refinement of A. To prove this, we must show that
ci o cf ⊆ ai o af 99
ci o co o cf ⊆ ai o ao o af 99 99
ciocoocoocf ⊆aioaooaooaf 999 999
.
It is easy to show that this reduces to the requirement that co ⊆ ao. The result then follows from the definitions of the two operations.
16.4 Simulations
We obtain a simpler characterisation of refinement if we consider the values produced at each step of a program’s execution. If data types A and C share the same indexing set, then the programs P(A) and P(C) will have the same number of steps: one for each operation involved. We may therefore compare the two programs on a step-by-step basis.
To do this, we must describe the relationship between the representation of data in A and that in C. We define a relation between the two sets of states: an element of either A↔C or C ↔A. If ρ is a relation of type A↔C, then we may ask the following questions:
• Is ci a subset of ai 9o ρ? That is, can any initialisation of C be matched by taking an initialisation of A and following it with ρ?
• Is ρ 9o cf a subset of af ? That is, can any finalisation of C be matched by preceding it with ρ and comparing it with a finalisation of A?
• Is ρ 9o coi a subset of aoi 9o ρ, for each index i? That is, can any operation in C be matched by the corresponding operation in A?
If the answer to each question is yes, then we say that ρ is a simulation for the two data types. The effect of any program step in C can be simulated by a step in A. Therefore, for any program P,
P(C) ⊆ P(A)
and we are safe to conclude that C is a refinement of A.
16.4 / Simulations
245
aa bb cc dd
Figure 16.2 Lifting
To ensure that this definition is applicable to data types with partial opera- tions, we require that the relations and state spaces are augmented to allow for undefinedness. It is not necessary to totalise the relation ρ, but it is necessary to propagate undefinedness. We add ⊥ to its domain and associate it with every element of the target type. If ρ is a relation of type X ↔ Y , then
ρ◦ ∈ X ⊥ ↔ Y ⊥
ρ◦ =ρ∪({⊥}×Y⊥)
We say that ρ◦ is the lifted form of ρ. Example 16.9 If we define a free type L by
L ::= a | b | c | d and a relation ρ by
ρ == {aa,ab,bb,bc} then the lifted version of ρ is given by
◦
ρ == {aa,ab,bb,bc,
⊥ ⊥, ⊥ a, ⊥ b, ⊥ c, ⊥ d} This extension is shown in Figure 16.2.
246
16 / Data Refinement
Figure 16.3 Forwards simulation
If data types A and C share the same indexing set, and r is a relation of
type A ↔ C , then r is a forwards simulation if ••◦
foreachindexi
These requirements are illustrated in Figure 16.3. The first insists that the effect of ci can be matched by ai followed by r, a two-step path around the diagram; the second that the effect of r followed by cf , another two-step path, can be matched by af ; the third that the effect of moving downwards and then across can be matched by moving across and then downwards.
The lower path in the diagram corresponds to a program using data type C. The upper path corresponds to the same program using data type A. Since the effect of each program step can be simulated, it is easy to see that C is a refinement of A.
Valid moves in the concrete data type may be simulated by moves in the abstract data type. The relation r is said to be a forwards simulation because, if we consider similar concrete and abstract states, then any valid move forwards to a new concrete state can be matched by a move to a similar abstract state. Since r relates abstract values down to concrete ones—see Figure 16.3—such a relation is sometimes called a downwards simulation.
• ci ⊆ ai 9o r ◦••
• r 9o cf ⊆ af ◦••◦
• r 9o coi ⊆aoi 9o r
16.4 / Simulations
247
Figure 16.4 Backwards simulation
If data types A and C share the same indexing set, and s is a relation of
type C ↔ A concrete and abstract states, then s is a backwards simulation if •◦•
• ci 9o s ⊆ ai •◦•
The requirements are similar to those for a forwards simulation, except that the position of the simulation is reversed. The first insists that the effect of ci followed by s can be matched by ai; the second that the effect of cf can be matched by s followed by af ; the third that the effect of moving across and then upwards can be matched by moving upwards and then across.
As before, the lower path in the diagram—Figure 16.4—corresponds to a program using data type C, and the upper path corresponds to the same pro- gram using data type A. We have that C is a refinement of A.
Again, valid moves in the concrete data type may be simulated by moves in the abstract data type. The relation r is said to be a backwards simulation because, if we consider similar concrete and abstract states, then any valid move to this concrete state from an old concrete state can be matched by a move from a similar abstract state. Since r relates concrete values up to abstract ones—see Figure 16.4—such a relation is sometimes called an upwards simulation.
• cf ⊆ s 9o af •◦◦•
for each index i
• co o s ⊆ s o ao i99i
248 16 / Data Refinement
16.5 Relaxing and unwinding
The definitions of forwards and backwards simulation presented above are given in terms of totalised operations and lifted relations. By considering do- main and range restrictions, we can obtain an equivalent set of requirements that mention neither totalisation nor lifting. These requirements constitute a more relaxed set of rules for data refinement.
We begin with the requirements for forward simulation. Our first relax- ation uses the fact that, for a total relation ρ, the totalised and lifted forms are identical; there is nothing outside the domain of ρ, so each extension adds the product of {⊥} with the target type. Because initialisation is always total, we can argue as follows:
••◦ ci ⊆ ai 9o r
◦◦◦ ci⊆ai9o r
[aiandciarebothtotal] [propertyofsubset] [⊥̸∈domci] [lifting] [⊥∈rana◦i]
ci⊆a◦i9o r◦ ∧ {⊥}×C⊥ ⊆a◦i9o r◦
ci⊆ai9o r ∧ {⊥}×C⊥ ⊆a◦i9o r◦
ci⊆ai9o r ∧ {⊥}×C⊥ ⊆a◦i9o (r∪{⊥}×C⊥) ci⊆ai9o r
A similar argument shows that the requirement upon the two finalisation op- erations can be relaxed to
r 9o cf ⊆ af
In each case, the ‘dot’ of totalisation and the ‘spot’ of lifting can be safely re- moved from the defining condition.
To obtain a suitable relaxation of the third requirement, we consider the following result: if ρ, σ, and τ are relations of type X ↔Z, X ↔Y, and Y ↔Z, respectively, then
ρ⊆σ•oτ◦ (domσ)▹ρ⊆σoτ 99
This may be proved as follows:
•◦ ρ ⊆ σ 9o τ
ρ⊆(σ∪(domσ⊥×Y⊥))9o τ◦ ρ⊆(σ9o τ◦)∪((domσ⊥×Y⊥)9o τ◦)
[totalisation] [distribution]
16.5 / Relaxing and unwinding
ρ⊆(σ9o τ)∪((domσ⊥×Y⊥)9o τ◦) ρ⊆(σ9o τ)∪(domσ⊥×Y⊥)9o (τ∪{⊥}×Z⊥)
249
[⊥̸∈ranσ] [lifting]
ρ⊆(σ9o τ)∪(domσ⊥×Z⊥)
(domσ) ▹ ρ ⊆ σ 9o τ [property of relations]
[propertyof9o] We will call this result ‘spot-dot elimination’. Returning to the third requirement
for simulation, we proceed as follows:
◦• •◦ r o co ⊆ ao o r
99
◦•
dom ao ▹ (r o co) ⊆ ao o r
[spot-dot elimination] [propertyof▹ando]
◦• (domao▹r)o co ⊆ aoo r
• (domao▹r)o co ⊆ aoo r
[⊥̸∈domao] [totalisation] [propertyof⊆]
99
999
99
(domao▹r)9o (co∪domco⊥ ×C⊥) ⊆ ao9o r
(domao▹r)o co ⊆ aoo r 99
∧
(domao▹r)9o (domco⊥×C⊥) ⊆ ao9o r
The first conjunct insists that the effect of co is consistent with that of ao, wherever ao is defined. The second conjunct requires further investigation: since ⊥ is outside the range of ao 9o r, it is equivalent to the condition that
ran(domao▹r) ⊆ domco
Informally, this requires that the operation co is defined for every value that can be reached from the domain of ao using relation r.
We may also derive a set of relaxed requirements for proving backwards simulation. The requirements upon initialisation and finalisation lose their spots and dots,
ci 9o s ⊆ ai cf ⊆ s 9o af
and the third requirement becomes
dom(s−◃(domao))−▹coo s⊆so ao 99
∧ domco⊆dom(s−◃(domao))
The first conjunct insists that the effect of co must be consistent with that of ao. The second insists—somewhat awkwardly—that the set of values for which co is not defined must be a subset of those for which ao is not defined.
250
16 / Data Refinement
F-init-rel-seq F-fin-rel-seq F-corr-rel-seq
B-init-rel-seq B-fin-rel-seq B-corr-rel-seq
ci ⊆ ai 9o r
r 9o cf ⊆ af
(dom ao) ▹ r o co ⊆ ao o r 99
ran((dom ao) ▹ r ) ⊆ dom co
ci 9o s ⊆ ai
cf ⊆ s 9o af
dom(s −◃ (dom ao)) −▹ co o s ⊆ s o ao 99
dom co ⊆ dom(s −◃ (dom ao)) Table 16.1 Relaxed rules for simulations
These results yield a collection of relaxed proof rules for simulations, col- lected in Table 16.1. The rules are named according to the type of simulation—F for forwards, B for backwards—and the type of rule: init for initialisation; fin for finalisation; corr for correctness of operations. We add an additional qualifier rel to indicate that we are working within a theory of relations.
These rules may be applied to operations involving input and output only by providing all inputs at initialisation, and delaying all outputs until finalisa- tion. The initial state of a program would include a sequence of inputs—the input values required during execution—and the final state a sequence of out- puts. Each rule in Table 16.1 is labelled with the suffix seq to indicate that input and output must be represented in this way.
It is possible to derive an equivalent set of rules in which inputs and outputs may occur at each program step. Suppose that op is an operation that involves input and output: a relation of type
(State × Input ) ↔ (State × Output )
In this case, there exists a corresponding operation ops of type
State × (seq Input × seq Output ) ↔ State × (seq Input × seq Output )
16.5 / Relaxing and unwinding 251
that behaves as follows: the effect of ops upon the state is that of op, given the head of the first sequence as input. Any output from op is added to the end of the second sequence. That is,
∀s,s′ : State; is : seqInput; os : seqOutput • ∀i : Input; o : Output | (s,i) op (s′,o) •
(s,(⟨i⟩⌢is,os))ops (s′,(is,os⌢⟨o⟩))
In our use of ops , we may regard the input and output sequences as part of the state information.
To obtain ops from op, we must extract the next value from the input se- quence. We define a function that takes a state and a pair of sequences and returns a state, an input, and a new pair of sequences:
[State, Input , Output ]
split : State × (seq Input × seq Output ) →
(State × Input ) × (seq Input × seq Output ) ∀ s : State; is : seq Input ; os : seq Output •
split (s , (is , os )) = ((s , head is ), (tail is , os ))
When we apply split , the first input is selected, and the results are assembled in a useful combination. The state and next input are presented as a pair, ready for consumption by an operation.
To simplify the process of reasoning about split, we derive an equivalent definition that avoids mentioning the arguments of the function. This will re- quire three new operators for manipulating pairs and sequences. The first is a form of parallel composition:
[W,X,Y,Z]
∥ :(W↔Y)×(X↔Z)→W×X↔Y×Z
∀ρ : W ↔Y; σ : X ↔Z; w : W; x : X; y : Y; z : Z • (w,x) (y,z) ∈ ρ ∥ σ w y ∈ ρ ∧ x z ∈ σ
This allows us to relate a pair of arguments to a pair of results, applying two operations separately and simultaneously.
The second is an operator which duplicates its input:
[X]
cp : X X × X
∀x:X •cpx=(x,x)
252
16 / Data Refinement
Figure 16.5 split data flow
The third operator takes a value–sequence pair and appends the value to the
end of the sequence:
[X]
ap : X × seq X seq X
∀ x : X ; xs : seq X • ap(x, xs) = xs ⌢ ⟨x⟩
Using these combinators, we can define split as:
id ∥ (first 9o head) split = cp 9o ∥
second 9o (tail ∥ id)
This definition may be explained in terms of data flow, as in the diagram of Figure 16.5. The first operator, cp, makes two copies of the input pair. One copy is fed into the parallel combination of ‘id’ and first 9o head, yielding the first component of the output. The other copy is fed through second into the parallel combination of tail and ‘id’, yielding the second component of the output.
16.5 / Relaxing and unwinding 253
Figure 16.6 merge data flow
We will also need a function that adds to the sequence of outputs:
[State, Input , Output ]
merge : (State × Output ) × (seq Input × seq Output ) →
State × (seq Input × seq Output )
∀ s : State; o : Output ; is : seq Input ; os : seq Output •
merge((s, o), (is, os)) = (s, (is, os ⌢ ⟨o⟩))
To simplify the process of reasoning, we observe that
merge = cp o first o first 99
∥
cp o second o first 99
∥
(second ∥ second) 9o ap
A data flow diagram for this construction is given in Figure 16.6.
254 16 / Data Refinement
We may use split and merge to translate an operation that involves input and output to one that expects these values to be present as sequences. If ρ is such an operation, then we may define
ρ = splito (ρ∥id)o merge s99
The operation ρ acts on a pair—a before-state, and an input—to produce an- other pair—an after-state, and an output. The split and merge operators act as translators between the two representations of input and output.
If we wish to compare ρ with another operation σ, in order to verify a proposed refinement, then we might decide to translate σ to a ‘sequenced’ operation σs and compare σs with ρs. However, the definitions of split and merge support a direct comparison between ρ and σ : we may unwind the rules for simulation so that input and output occur at each step.
Suppose that ao and co are operations that consume input and produce output. To compare these operations using the existing rules, we must define equivalent operations aos and cos that expect input and output in the form of sequences. We may define these operations using split and merge:
ao =splito (ao∥id)o merge s99
co =splito (co∥id)o merge s99
where ‘id’ is the identity relation on pairs of input and output sequences. Furthermore, since r is a relation between states without input and output sequences, we must construct an equivalent relation that acts on the enhanced
form of the state. If r is a relation of type AState ↔ CState
then we require a relation rs of type
AState × (seq Input × seq Output ) ↔ CState × (seq Input × seq Output )
in order to compare aos and cos .
For our comparison to make sense, the two operations must have the same
type of input and output values. The relation rs between enhanced states is then defined by
rs = r ∥ id
The rules for the correctness of a forwards simulation—given in Table 16.1—
require that
(domaos)▹rs 9o cos ⊆aos 9o rs
16.5 / Relaxing and unwinding 255
F-init-rel F-corr-rel
B-init-rel B-corr-rel
ci ⊆ ai 9o r (domao)▹(r∥id)o co⊆aoo (r∥id)
ran((dom ao) ▹ (r ∥ id)) ⊆ dom co ci 9o s ⊆ ai
dom((s∥id)−◃(domao))−▹coo (s∥id)⊆(s∥id)o ao 99
dom co ⊆ dom(s −◃ (dom ao)) Table 16.2 Unwound rules for simulations
99
The operations cos and aos have the same effect upon the two sequences: they remove a value from one and append a value to the other. The relation rs has no effect upon the sequences, so this requirement is equivalent to
(domao)▹(r∥id[Input])o co ⊆ aoo (r∥id[Output]) 99
Where ao is defined, the effect of applying co can be matched by applying ao and then moving from one state space to the other.
The other condition—that cos is defined everywhere that aos is defined— leads to a second constraint:
ran((domao) ▹ (r ∥ id[Output])) ⊆ domco
The presence of the identity relation reflects the fact that output is no longer treated as part of the state.
A set of unwound rules for forwards and backwards simulation is presented in Table 16.2. Finalisation is no longer a special case—any program step may produce output—so there are only two rules for each form of simulation. Be- cause these rules may be applied directly, without regarding input and output as special components of the state, we drop the suffix seq from the name of each rule.
Chapter 17
Data Refinement and Schemas
In the previous chapter we presented a theory of data refinement for partial and total relations. In this chapter we see how this theory may be extended to cover specifications written in the schema notation. Each operation schema corresponds to a relation on states, and an operation is correctly refined exactly when that relation is correctly refined. In this way, our existing refinement rules can be restated in terms of schemas.
17.1 Relations and schema operations
An operation schema defines an operation upon the state of a system. It does this by describing how the state after the operation is related to the state before. The meaning of an operation schema, for our purposes, is thus a relation upon states. This relation need not be total: if the precondition of the schema is not true, then there will be states outside the domain.
Where the precondition is not satisfied, the result of the operation is left undefined: anything may happen. For example, an operation that takes the reciprocal of a real number r is specified by the following operation schema:
Recip = [∆S|r≠0∧r′=1/r]
where S = [r : R]. This is a partial operation: when r is zero, it may fail to terminate, and if it does, then the value of r ′ may be any real number. Ignoring the question of input and output for the moment, the relation corresponding to Recip is the totalisation—in the sense of the previous chapter—of the relation:
{Recip • θS θS′ }
258 17 / Data Refinement and Schemas
If we totalise this, and then simplify the resulting expression, then we get to the true specification of Recip (‘true’ in the sense that it describes all the behaviour of Recip, including what happens outside the precondition):
•
{r,r′ : R | r ≠ 0 ∧ r′ = 1/r • θS θS′ }
which is the relation:
{r,r′ : R⊥ | r ≠ 0 ∧ r ≠ ⊥ ∧ r′ = 1/r ∨ r = 0 ∨ r = ⊥ • θS θS′ }
This relates any state in which r is non-zero to one in which it has the reciprocal value. A state in which r is zero, or is undefined, is related to all possible states. An operation schema may also include input and output components. To represent these, the domain of the corresponding relation will be a Cartesian product of states and inputs, and the range will be a product of states and outputs. If Op describes an operation on a state S, then the corresponding
relation will be a lifted, totalised version of
{Op • (θS,i?) (θS′,o!)} That is,
•
split 9o ({Op • (θS,i?) (θS′,o!)} ∥ id) 9o merge
Using this correspondence, we may translate between the language of schemas and the language of relations. A schema specification S is really a relaxed and unwound relational specification on a data type D.
Suppose now that data types A and C are described using schemas, the two state schemas being A and C respectively. A proposed simulation between the two data types can itself be expressed as a schema:
R A C
.
The relationship that this schema records is called a retrieve relation: it shows how the representation of data in A—which may be more abstract—can be retrieved from the representation of data in C.
17.2 / Forwards simulation 259
To decide whether or not R is a simulation, we will need to compare oper- ations with the same index; let us consider two such operations, AO and CO, each with a single input i? and a single output o!. We will also need to exam- ine the initialisations of A and C; let us suppose that these are described by schemas AI and CI , respectively.
17.2 Forwards simulation
To apply the existing rules for forwards simulation, we consider the relations that correspond to the retrieve and operation schemas:
r = { R • θA θC }
ao = {AO • (θA,i?) (θA′,o!)}
co = {CO • (θC,i?) (θC′,o!)}
We consider also the sets of states produced at initialisation:
ai = { AI • θA′ } ci = {CI • θC′ }
To simplify the process of reasoning about ai and ci, we will regard each as a trivial form of relation, in which the first component of each pair is ignored.
The unwound rules for forwards simulation, presented towards the end of the last chapter, insist that the following condition must hold for the two initialisations:
ci ⊆ ai 9o r
We may express this condition in terms of schemas:
ci ⊆ ai 9o r ∀c:C•c∈ci⇒c∈ai9o r ∀C•θC∈ci⇒θC∈ai9o r ∀C •θC ∈ci ⇒
∃A•θA∈ai ∧θAθC ∈r
∀C • θC ∈ {CI • θC′ } ⇒ ∃A•θA∈{AI •θA′}∧
θAθC ∈{R•θAθC} ∀C′ • CI ⇒ ∃A′ • AI ∧ R′
[bypropertyof⊆] [byschemacalculus] [bypropertyof9o]
[by definition]
[by comprehension]
260
17 / Data Refinement and Schemas
∀C′ •CI ⇒∃A′ •AI ∧R′
∀ A; C • pre AO ∧ R ⇒ pre CO
∀A; C; C′ •preAO∧R∧CO⇒∃A′ •AO∧R′
Table 17.1 Rules for forwards simulation
F-init F-corr
The unwound rules insist also that
(dom ao) ▹ (r ∥ id) o co ⊆ ao o (r ∥ id) 99
and that
ran((dom ao) ▹ (r ∥ id)) ⊆ dom co
for every pair of operations ao and co. These requirements lead to a pair of conditions upon the corresponding operation schemas.
The first condition is that the concrete operation CO must be defined in any state whose abstract equivalent satisfies the precondition of AO.
∀ A; C • pre AO ∧ R ⇒ pre CO
This tells us that the development step has—if anything—weakened the pre- condition of the operation.
The second condition tells us that the concrete operation produces results that are consistent with those of the abstract:
∀A; C; C′ •
preAO∧R∧CO⇒∃A′ •AO∧R′
Suppose that two concrete states C and C ′ are related by the concrete operation CO. Suppose also that A, the abstract equivalent of C, lies within the precon- dition of AO. Then for CO to be a correct refinement of AO, there must be an abstract state A′, corresponding to C′, that can be reached from A by applying AO. The three conditions are presented together in Table 17.1.
17.2 / Forwards simulation 261
Example17.1 Werequireasystemthatwillmonitortheaccesstoabuilding. The system should keep track of the people who are inside the building, and should forbid entry by more than a specified number of people at any time. Let Staff be the set of all members of staff:
[Staff ]
and let maxentry be the maximum number of people that may enter the building
at any time:
maxentry : N
We can model the state of our system by recording the names of those cur- rently inside the building; the state invariant restricts the number of people accordingly:
ASystem = [s : PStaff | #s ≤ maxentry ]
Initially, there is no-one in the building; this satisfies the invariant, no matter
what the value of maxentry: ASystemInit = [ ASystem′ | s′ = ∅ ]
A person who is not already recorded as being inside the building may enter it, providing there is enough room:
AEnterBuilding ∆ASystem
p? : Staff
#s < maxentry p? ∉ s
s′ =s∪{p?}
A person who is in the building may leave it:
ALeaveBuilding ∆ASystem
p? : Staff
p? ∈ s
s′ =s\{p?}
262 17 / Data Refinement and Schemas
A more concrete specification might model the state of the system as an injective sequence: a sequence with no repetitions. The length of this sequence must be less than maxentry:
CSystem = [ l : iseq Staff | #l ≤ maxentry ]
where the generic symbol ‘iseq’ is as defined in Section 9.2.
The length of l represents the number of people inside the building, since
l contains no duplicates. Initially, there is no one in the building: CSystemInit = [ CSystem′ | l′ = ⟨⟩ ]
A person who is not already inside the building may enter it, providing there is enough room:
CEnterBuilding ∆CSystem
p? : Staff
#l < maxentry p? ∉ ranl
l′ =l⌢⟨p?⟩
A person who is in the building may leave it:
CLeaveBuilding ∆CSystem
p? : Staff
p? ∈ ranl
l′ =l(Staff \{p?})
Although both specifications describe the same system, the first is more ab- stract: it doesn’t record the order in which people enter the building. The use of a sequence certainly makes the second specification a bit more awkward: we have to say that it contains no duplicates. The second specification also makes certain design decisions: for example, new people are appended to the end of the sequence.
We regard the first description as an abstract specification, and the second as a step on the way to producing a design. We intend to implement the set of names using an array, in which the elements will be ordered. We take a design decision to record the names in order of arrival. This decision may be documented using a retrieve relation:
17.2 / Forwards simulation 263
ListRetrieveSet ASystem CSystem
s = ran l
This is a formal record of the design step. It will help us to demonstrate that the second specification is a correct implementation of the first.
In order to prove that this refinement is correct, we must establish that each of the following statements is a theorem:
∀ CSystem′ • CSystemInit ⇒
(∃ ASystem′ • ASystemInit ⇒ ListRetrieveSet′)
∀ ASystem; CSystem; p? : Staff • pre AEnterBuilding ∧ ListRetrieveSet ⇒ pre CEnterBuilding
∀ ASystem; CSystem; CSystem′; p? : Staff •
pre AEnterBuilding ∧ ListRetrieveSet ∧ CEnterBuilding ⇒
(∃ASystem′ •ListRetrieveSet′ ∧AEnterBuilding)
∀ ASystem; CSystem; p? : Staff • pre ALeaveBuilding ∧ ListRetrieveSet ⇒
pre CLeaveBuilding
∀ ASystem; CSystem; CSystem′; p? : Staff •
pre ALeaveBuilding ∧ ListRetrieveSet ∧ CLeaveBuilding ⇒
(∃ASystem′ •ListRetrieveSet′ ∧ALeaveBuilding)
Example17.2 Wearerequiredtoproduceaprogramthatfindstheaverageof some numbers. We decide that the program should find the arithmetic mean of some natural numbers. Our specification describes a simple interface consist- ing of two operations: an operation AEnter that adds a number to our data set and an operation AMean that calculates the arithmetic mean of the numbers entered thus far.
The state of the program is modelled using a sequence of natural numbers to represent the data set:
AMemory = [s:seqN]
The use of a sequence or a bag—rather than a set—is important here, as we may be faced with many copies of the same natural number.
264
17 / Data Refinement and Schemas
Precondition
true
true s ≠ ⟨⟩
Operation
AMemoryInit AEnter AMean
Table 17.2 Specification of the Mean Machine
In the initial state, the sequence of numbers is empty:
AMemoryInit = [AMemory′ | s′ = ⟨⟩]
As each number is entered, it is added to the end of the sequence:
AEnter ∆AMemory n? : N
s′ =s⌢⟨n?⟩
The arithmetic mean of a series is its sum divided by its length. The following
schema makes it clear exactly what is to be calculated:
AMean ΞAMemory m! : R
s≠⟨⟩#s (si) m! = i=1
#s
The result makes sense only if the length of the sequence is strictly positive: this leads us to the precondition recorded in Table 17.2.
It is not necessary to keep the entire sequence of numbers that has been input; there is another way to compute the mean. In a specification we are more concerned with clarity than with efficiency, so the summation over a series is entirely appropriate. We will now consider a design in which only two numbers are stored: the running total and the sample size.
17.2 / Forwards simulation
Operation
CMemoryInit CEnter CMean
265
Table 17.3 Design of the Mean Machine
The state comprises two numbers: one natural, one real.
CMemory = [sum : N; size : N]
In the initial state, both of these are zero.
Precondition
true
true size ≠ 0
CMemoryInit = [CMemory′ | sum′ = 0 ∧ size′ = 0]
When a number is entered, it is added to the running total, and the sample size
is increased by one:
CEnter ∆CMemory n? : N
sum′ =sum+n? size′ = size + 1
If at least one number has been entered, then the mean may be obtained by dividing the running total by the sample size. In our design, the effect of this operation is described by
CMean ΞCMemory m! : R
size ≠ 0 m! = sum
size
The precondition for this schema is recorded in Table 17.3.
266 17 / Data Refinement and Schemas
To understand what is being computed by CMean, we must consider what happens if we enter a sequence of numbers and divide their sum by the num- ber of entries. The relationship between specification and design should be obvious:
SumSizeRetrieve AMemory CMemory
#s sum= (si)
i=1 size = #s
The retrieve relation is not functional from concrete to abstract, as it was in Example 17.1. Instead, it is functional from abstract to concrete.
The correctness of the design should also be obvious: if we take CEnter and CMean, and replace sum and size by the expressions that Retrieve gives us for them in terms of s, then we obtain the abstract descriptions of these operations. In order to prove this, we must prove that the following are theorems:
∀ CMemory ′ • CMemoryInit ⇒
(∃AMemory′ • AMemoryInit ⇒ SumSizeRetrieve′)
∀AMemory; CMemory; n? : N • pre AEnter ∧ SumSizeRetrieve ⇒ pre CEnter
∀ AMemory; CMemory; CMemory′; n? : N • pre AEnter ∧ SumSizeRetrieve ∧ CEnter ⇒
(∃AMemory′; m! : R • SumSizeRetrieve′ ∧ AEnter)
∀AMemory; CMemory; n? : N • pre AMean ∧ SumSizeRetrieve ⇒ pre CMean
∀ AMemory; CMemory; CMemory′; n? : N • pre AMean ∧ SumSizeRetrieve ∧ CMean ⇒
(∃ AMemory′; m! : R • SumSizeRetrieve′ ∧ AMean)
We may now translate our design into the refinement calculus—the sub- ject of the next chapter—using a mixture of program code and specification statements. Briefly, the specification statement w : [ pre, post ] describes a pro- gram that must terminate if started in any state satisfying pre, yielding a state satisfying post, while changing only those variables mentioned in w.
The result of our translation is shown below. The body of the procedure enter comprises a specification which insists that the global variable sum must
17.2 / Forwards simulation 267 be increased by the value of the n?, and that size must be incremented.
var sum,size:N•
...
proc enter (val n? : N);
sum,size:[true,sum′ =sum+n?∧size′ =size+1]; proc mean (res m! : R);
m! : [size ≠ 0,m! = sum/size]
The body of the procedure mean comprises another specification that insists that m! must have the final value sum/size. In this case, the implementor may assume that the value of size is not 0.
We may fill in some detail by refining the specification statements into a target programming language: in this case, Pascal. The result is a program that correctly implements our original specification:
PROGRAM MeanMachine(input,output);
VAR
n,sum,size: 0..maxint;
m: real;
PROC Enter(n: 0..maxint);
BEGIN
sum := sum + n;
size := size + 1
END;
PROC Mean(VAR m: real);
BEGIN
m := sum / size
END; BEGIN
sum := 0;
size := 0;
WHILE NOT eof DO
BEGIN
read(n);
Enter(n)
END;
Mean(m);
write(m)
END.
268 17 / Data Refinement and Schemas
Example 17.3 We wish to use a dictionary to check the spelling of words. If the word is in the dictionary, then it is considered to be spelt correctly; if not, then it is considered to be spelt incorrectly. Abstractly, the dictionary is simply a set of words
ADict = [ad:PWord]
The task of implementing the dictionary efficiently is a searching problem. One solution is to keep the dictionary in a sorted order, and employ a binary search method. This design is recorded by the following schema:
CDict1
cd1 : iseq Word
∀i,j :domcd1 |i ≤j •(cd1i)≤W (cd1j)
The words are kept (without duplicates) in a sequence in ascending order. We havetakenthat≤W istheorderingonWord.
Alternatively, we could divide the words according to length, and a search would proceed by looking at only those words of the same length as the word we are checking, thus cutting down the search space.
CDict2
cd2 : seq(P Word)
∀i : domcd2 • ∀w : (cd2 i) • #w = i
This design starts by introducing a sequence of sets of words, with each of the sets containing only words of a particular length: the first set has words of length 1, the second of length 2, and so on.
As a third alternative, suppose that we are more interested in space effi- ciency. In this case, we might choose to exploit the common prefixes in the dictionary. As an example, suppose that our dictionary were rather sparsely filled with the following words: and, ant, bee, can, and cat. Instead of storing all 15 letters, we need store only 11 of them. The data structure that we have in mind is a tree. At its root there are three branches, one for a, one for b, and one for c. Below each of these branches, there is another prefix tree.
If X → 1 Y denotes the set of all non-empty functions between X and Y , then the free type of prefix trees is given by
WordTree ::= tree⟨⟨Letter → 1 WordTree⟩⟩ | treeNode⟨⟨Letter → WordTree⟩⟩
17.2 / Forwards simulation
269
Figure 17.1 A word tree
The use of two injections—tree and treeNode—means that we can capture proper prefixes.
With this definition, the design of the dictionary can be described by the following schema:
CDict3 = [ cd3 : WordTree ]
Our five-word dictionary—illustrated in Figure 17.1—may be expressed for-
mally as a WordTree:
tree {a tree{n tree{d treeNode ∅, t treeNode ∅}}, b tree{e tree{e treeNode ∅}},
c tree{a tree{n treeNode ∅, t treeNode ∅}} }
As a final example, consider a little dictionary which contains only the words tin and tiny. This has the representation as a word tree which is linear:
tree{t tree{i tree{n treeNode{y treeNode ∅}}}}
The injection treeNode is used to mark a node that contains the end of a word, even if it is a proper prefix of another word.
Each of the three designs—CDict1, CDict2, and CDict3—forms the basis for a correct data refinement of ADict.
270
17 / Data Refinement and Schemas
∀A′; C′ •CI ∧R′ ⇒AI
∀C •(∀A•R⇒preAO)⇒
∀A′; C′ • CO ∧ R′ ⇒ ∃A • R ∧ AO ∀C •(∀A•R⇒preAO)⇒preCO
B-init B-corr
17.3
Table 17.4 Rules for backwards simulation
Backwards simulation
Some valid refinements cannot be proved correct using forwards simulation. We may characterise these as refinements in which the resolution of nonde- terminism is postponed. Where this is the case, backwards simulation should be used instead. In backwards simulation, it is as if the abstract system can simulate the concrete one by being able to anticipate its actions.
As in the case of forwards simulation, the rules for the refinement of relations—presented at the end of the previous chapter—give rise to a corre- sponding set of conditions for the refinement of specifications. For any initial concrete state, the equivalent abstract state(s) must be initial abstract states
∀A′; C′ •CI ∧R′ ⇒AI
Whatever abstract equivalent A′ we choose, it must meet the constraints of initialisation AI .
If operation CO is to correctly implement abstract operation AO, then it must work whenever AO is guaranteed to work.
∀C •(∀A•R⇒preAO)⇒preCO
Finally, for any abstract equivalent A′ of the after-state C′, there must be an abstract equivalent A of the before-state C such that A and A′ are correctly related: that is, related by AO.
∀C • (∀A • R ⇒ pre AO) ⇒ (∀A′; C′ • CO ∧ R′ ⇒ (∃A • R ∧ AO)) These rules are summarised in Table 17.4.
17.3 / Backwards simulation 271
Example 17.4 The Phoenix is a cinema whose box office works as follows. A customer may telephone and ask for a ticket. The box office clerk decides if there is an unsold ticket so as to accommodate the request. If there is, then a note is made to reserve a ticket for the caller. When the customer arrives, the box office clerk allocates an unsold ticket which identifies the seat.
We contrast this procedure with that of the Apollo theatre. At the Apollo, a customer may telephone and ask for a ticket. The box office clerk decides if there is an unsold ticket so as to accommodate the request. If there is, then one is allocated and put to one side for the caller. When the customer arrives, the clerk presents the allocated ticket which identifies the seat.
The customer cannot tell the difference between the two booking proce- dures. The point at which the ticket is allocated—and a nondeterministic choice of seat number is made—cannot be detected by the caller. The transaction ap- pears the same in each case: the customer telephones the box office, arrives at the place of entertainment, obtains a ticket, and takes the indicated seat.
The Phoenix maintains a pool of tickets, drawn from a given set
[Ticket ]
We will concentrate on the activities of a single customer, keeping track not only of the pool of unused tickets, but also of whether or not this customer has booked a ticket. The state of the Phoenix box office is then
Phoenix
ppool : P Ticket bkd : Booked
where Booked is the free type Booked ::= yes | no
The booking operation requires that the customer has not already booked, and that there is a ticket to be allocated:
PBook ∆Phoenix
bkd = no ppool ≠ ∅ bkd′ = yes ppool′ = ppool
272 17 / Data Refinement and Schemas A successful arrival requires that the customer has booked and that a ticket
has been left for them:
PArrive ∆Phoenix t! : Ticket
bkd = yes
ppool ≠ ∅
bkd′ =no
t! ∈ ppool
ppool′ = ppool \ {t!}
Afterwards, the record is updated to say that there is no booking, a ticket is allocated, and the pool of tickets is updated accordingly.
Our model of the Apollo system requires a more sophisticated form of ticket. We employ a free type with a constant null:
ATicket ::= null | ticket⟨⟨Ticket⟩⟩
The state of the Apollo box office contains a pool of ordinary tickets, and a
possibly-null ticket:
Apollo
apool : P Ticket tkt : ATicket
tkt ≠ null ⇒ ticket∼ tkt ∉ apool
The booking operation requires that no ticket has already been reserved by the
customer, and that the pool is not empty.
ABook ∆Apollo
tkt = null
apool ≠ ∅
tkt′ ≠ null
ticket∼ tkt′ ∈ apool
apool′ = apool \ {ticket∼ tkt′}
Afterwards, a single ticket is removed from the pool and reserved in the state component tkt.
17.3 / Backwards simulation 273 A successful arrival operation requires that the customer has reserved a
ticket. This ticket is then issued, and the pool remains unchanged.
AArrive ∆Apollo t! : Ticket
tkt ≠ null
tkt′ = null
t! = ticket∼ tkt apool′ = apool
The relationship between the two systems may be documented by the fol- lowing retrieve relation:
ApolloPhoenixRetr Phoenix
Apollo
bkd = no ⇒ tkt = null ∧ ppool = apool
bkd = yes ⇒ tkt ≠ null ∧ ppool = apool ∪ {ticket∼ tkt}
We put forward two conjectures:
• The Phoenix system is data refined by the Apollo system.
• The Apollo system is data refined by the Phoenix system.
The first of these can be proved using forwards simulation; the second cannot.
To see why, consider the following statement:
pre AArrive ∧ ApolloPhoenixRetr ∧ PArrive ⇒ ∃Apollo′ •ApolloPhoenixRetr′ ∧AArrive
To prove this, we must show that t! = ticket∼ tkt: one of the predicates of AArrive. The most that we can deduce from the antecedents is that t ! ∈ apool ∪ {ticket∼ tkt }. This is not enough. Notice that when we prove the refinement the other way around, the proof will work as expected.
As the reader will have guessed, we need the backwards simulation rules in order to be able to prove the second conjecture. Our troublesome predicate asks the very question that backwards simulation sets out to answer: that is, is there a state that the abstract operation could have started in that would have led to this situation?
274 17 / Data Refinement and Schemas
Example 17.5 The game of MastermindTM was popular some twenty years ago. In this game, one player chooses a code of six coloured pegs, and the other tries to guess what this code is. The guesser is allowed a number of attempts; the setter replies to each attempt by stating how many of the guess’s pegs are of the correct colour, and how many of these are in the correct order.
In the specification of an electronic version of MastermindTM, we might state that a random sequence is chosen when the system is switched on. An implementation may do exactly this, or it may postpone the choice until the first attempt is made. Since there is no way to detect that the choice has not already been made, this would be a valid refinement of the specification, provable using backwards simulation.
An implementation might also choose to postpone the choice until the last possible moment. The system could then maintain a set of codes—consistent with the answers it has given the user thus far—and leave the decision about the ‘real’ code until it has no room left to manoeuvre. Of course, delaying the choice of code is against the spirit of the game, but with this interface there is no way to detect the ‘fraud’: our cheating implementation is a correct refinement of the specification.
Example 17.6 Here is another example of a refinement which requires the back- wards rules; it also has a novel twist. It concerns a greatly simplified model of a vending machine, which dispenses drinks in response to three-digit codes typed in by its users. The specification abstracts from the detail of the digits being input one-by-one, and requires instead that the sequence is entered atomically. This kind of abstraction, where the level of atomicity in the system is changed, is useful in describing many similar interfaces, such as that used in telephone systems.
We begin with a few global definitions. The free type Status is used to signal the success or failure of the current interaction with the machine, and to keep track of whether a transaction is in progress; Digit s are those numbers between 0 and 9; and seq3[X ] is the set of sequences of X s whose length is exactly 3.
Status ::= yes | no
Digit == 0 . . 9 seq3[X]=={s:seqX |#s=3}
The state of our specification contains two boolean variables; these indicate
17.3 / Backwards simulation 275 whether it is in use, and whether the current transaction will be successful.
VMSpec = [ busy , vend : Status ] Initially, both variables are set to no:
VMSpecInit = [ VMSpec′ | busy′ = vend′ = no ]
A user interacts by inputting a three-digit sequence, and then collecting the drink, if the numbers were correctly chosen. We have abstracted from the need to pay, and even from the kind of drink that gets dispensed. The first part of the transaction is to choose the drink.
Choose ∆VMSpec
i? : seq3 Digit
busy = no busy′ = yes
Note that the value of vend is left undetermined by the operation: its value is nondeterministically chosen. The end of the transaction simply signals whether the transaction is successful or not:
VendSpec ∆VMSpec o! : Status
busy′ =no o! = vend
At the design level, digits are entered separately. All we actually need to record is the number of digits entered. Initially, there is no transaction in progress:
VMDesign= [digits:0..3]
VMDesignInit = [ VMDesign′ | digits′ = 0 ]
A transaction starts with a user punching in the first digit:
276
17 / Data Refinement and Schemas
FirstPunch ∆VMDesign d? : Digit
digits = 0 digits′ = 1
and continues with the user punching in further digits:
NextPunch ∆VMDesign d? : Digit
(0
Given the new representation, we can calculate the refinement. The calculation is straightforward, although the results may need to be simplified before they are used; this is typical of the calculational approach.
18.4 Refining promotion
Promotion is a powerful tool for structuring specifications; it allows us to con- struct multi-layer descriptions of large systems. An important feature of pro- motion, one not discussed in Chapter 13, is that it is monotonic with respect to refinement. This result may be summarised as ‘the refinement of a promotion is the promotion of the refinement’. If our specification includes a promoted abstract data type, we can refine this data type independently, while preserving its relationship with the rest of the system.
The simplest form of promotion uses a function to index a data type S, whose operations are then promoted. Suppose that the enclosing data type is P, and that the state of P is described by
P = [ f : I → S ]
292 18 / Functional Refinement A suitable promotion schema might be
Promote ∆S
∆P
i? : I
i? ∈ domf
θS = f (i?)
f′ =f ⊕{i?θS′}
If SO is an operation of S, then it may be promoted in the usual way: that is, PO = ∃∆S•Promote∧SO
To model this form of promotion in the relational calculus, we define three operators. The first applies a function to an argument; the second is a prefix version of overriding; the third is a curried version of relational image:
[X,Y]
apply : (X → Y ) × X → Y
ovr :((X →Y)×X)×Y →X →Y img : (X ↔ Y ) → P X → P Y
∀ f : X → Y ; x : X • apply (f , x ) = f (x )
∀ f : X → Y ; x : X ; y : Y • ovr ((f , x ), y ) = f ⊕ {x y } ∀R:X ↔Y; S :PX •(imgR)S =R(|S |)
If op is an operation on a data type D, then we can promote it to an operation Φ(op) on a data type Φ(D) whose space of values is I → D, for some indexing set I. The definition of Φ(op) is given by
id
Φ(op) == cp o ∥ o ovr 99
apply 9o op
where cp and ∥ are as defined in Chapter 16.
If the data types A and C are linked by a forwards simulation ρ, then the
retrieve relation between promoted data types Φ(A) and Φ(C) is identified by the following equation:
r = img(id∥ρ)
18.4 / Refining promotion 293
We will now demonstrate that r defines a forwards simulation from A to C, and thus that Φ(C) refines Φ(A). Consider the correctness condition for a matching pair of operations ao and co:
(r ∥id)o Φ(co) ⊆ Φ(ao)o r 99
Observe that each side is a relation drawn from A × I ↔ A; we require the index of that part of the state which is being updated.
We may rewrite the left-hand side of this inequation using the laws of the relational calculus, the definitions of apply and ovr, and the properties of our retrieve and promotion relations.
(r ∥ id) 9o Φ(co)
id
=(r ∥id)o cpo ∥ o ovr 999
apply 9o co r∥id id
⊆cpo ∥ o ∥ oovr 999
r∥id apply9oco (r ∥ id) 9o id
= cp o ∥ o ovr 99
(r ∥id)o apply o co 99
[bydefinitionofΦ(co)]
[propertyofcp]
[abiding property]
[idunit]
[property of apply]
[sinceA⊑C]
[idunit]
[abiding property]
r ∥ id =cpo ∥
oovr 99
(img(id∥ρ)∥id)o apply o co 99
r ∥ id
= cp o ∥ o ovr
99
r ∥ id ⊆cpo ∥
applyo ρo co 99
oovr 99
applyo aoo ρ 99
id 9o (r ∥ id)
=cpo ∥ oovr
99
applyo aoo ρ 99
id r ∥ id
= cp o ∥ o ∥ 999
apply9oao ρ
o ovr
294
18 / Functional Refinement
id
Figure 18.1 Refining promotion img(id ∥ ρ) ∥ id
o ∥ oovr apply9oao ρ
[definitionofr]
[propertyofovr]
[definitionofr] [definition of Φ(ao)]
=cpo ∥ 999
id
=cpo ∥ o ovro img(id∥ρ)
999 apply 9o ao
id
=cpo ∥ oovror 999
apply 9o ao = Φ(ao) 9o r
This shows that the promotion of co correctly refines the promotion of ao, as in Figure 18.1. The application of this should be obvious: we may specify an abstract data type, and then calculate its promotion. When we come to refine the abstract data type, the same calculation promotes the more concrete data type into a correct refinement of the promoted system.
18.4 / Refining promotion 295
Example 18.5 The simple temperature sensor may be used in situations where there is more than one temperature to record. As a specification, we may take the obvious promotion of the Fahrenheit data type. If Ind represent the set of indices used to refer to the individual temperatures, then the state consists of a total function:
FTDisplay = [ fd : Ind → FTemp ]
The promotion of each operation is simple:
FTPromote ∆FTDisplay ∆FTemp
i? : Ind
θFTemp = fd i?
fd′ = fd ⊕ {i? θFTemp′}
The promoted operations are
FTDisplayInc = ∃∆FTemp•FTPromote∧FTInc FTDisplayDec = ∃ ∆FTemp • FTPromote ∧ FTDec
The concrete state of the new system is described by
CTDisplay = [ cd : Ind → CTemp ] with the following promotion:
CTPromote ∆CTDisplay ∆CTemp
i? : Ind
θCTemp = cd i?
cd′ = cd ⊕ {i? θCTemp′}
The refined, promoted operations are
CTDisplayInc = ∃ ∆CTemp • CTPromote ∧ CTInc CTDisplayDec = ∃ ∆CTemp • CTPromote ∧ CTDec
Chapter 19
Refinement Calculus
We have seen that an abstract specification may be refined until a suitable concrete design is reached. Such a design may be translated into an abstract programming notation and then refined further, to yield a description in the language of guarded commands. This description may be translated into a standard programming language.
Specification (schemas)
refinement Design (schemas)
translation Algorithm (abstract program)
refinement
Code (guarded commands)
translation
Code (programming language)
The abstract programming notation that we will use is a refinement calculus for the schema language. In this chapter, we will see how to translate schemas into specification statements, and how to refine these statements towards exe- cutable program code.
298 19 / Refinement Calculus
19.1 The specification statement
In our formal specifications, we use schemas to describe operations upon an abstract data type. An alternative approach involves the use of specification statements: abstract programs consisting of a precondition, a postcondition, and a list of variables.
If frame is a list of variables, and precondition and postcondition are both predicates upon the state, then
frame : [precondition, postcondition]
is a specification statement. It describes an operation that begins in a state satisfying precondition and ends in a state satisfying postcondition. Only those variables listed in frame are affected.
Example 19.1 In Example 12.10, we used a schema to describe an operation with a single output: the number of free seats remaining in the box office. This operation could also be described by the following specification statement:
available! : [ true, available! = free(θBoxOffice) ]
The operation changes the value of available! so that it is equal to the value of
free(θBoxOffice).
If a specification statement refers to a variable that is not declared in its
frame, then it must leave the value of that variable unchanged.
Example 19.2 The following specification statement describes the operation of finding an approximate root for a function—a value m such that f (m) is close to zero—within a particular interval [a, b]. It will fail if no such value exists:
f(a)∗f(b)≤0 −0.1
end ; begin
con X • x : [x = X, x′ > X ] end
The scope of each logical constant is important. The following statement de- scribes a program with quite different behaviour:
begin
con X •x:[x=X,x′ >X]; x:[x=X,x′ >X]
end
Logical constants are used to give names to things that already exist. A simple example is the way in which they may be used to fix the before value of a variable: for example,
begin con X •x:[x=X,x′ >X]end
The variable X takes a value that makes subsequent preconditions true, if pos- sible. Within the scope of X , there is only one precondition, x = X , and X takes
19.3 / Logical constants 305 on this value: namely, the value of x before the specification statement. This
particular statement is equivalent to
begin con X •x:[true,x′ >x]end
More generally, we can introduce a logical constant in much the same way as
we would introduce an existential quantifier.
Law 19.6 (introduce logical constant) If pre1 ⇒ (∃ C : T • pre2 ), and C is a fresh name, then
w:[pre1,post]
begin
⊑ con C:T •w:[pre2,post] end
Conversely, if a logical constant is no longer mentioned in a program, then we can eliminate its declaration. This corresponds to the elimination of an existential quantifier.
Law 19.7 (eliminate logical constant) If C occurs nowhere in prog, then
begin conC:T•prog ⊑ prog
end
Logical constants are rarely found in programming languages, and are cer- tainly not the kind of constant that one finds in C. In order to declare a more conventional constant, one can introduce a state variable which has an invari- ant that says that it never changes. For example, one might wish to declare a constant whose value is a fixed approximation to π . This is done by introducing a variable, and then constraining it to be constant:
begin
var pi:R|pi=22/7•
.
end
306 19 / Refinement Calculus
19.4 Sequential composition
A specification statement describes a task: change the values of the variables in the frame so that the postcondition is achieved. It is often possible to di- vide this task into two smaller tasks, to be performed sequentially. Instead of proceeding directly from pre to post, we use one program to move from pre to an intermediate result mid. A second program can then be used to move from mid to post.
The intermediate result mid is characterised by a predicate upon the vari- ables in the frame. Without loss of generality, suppose that x is the only variable that is changed during the first task. The first program is then
x : [ pre, mid ]
To obtain the precondition and postcondition for the second program, some substitutions are necessary.
In the precondition of the second program, we use x to refer to the value of x when that program starts. This is precisely the value of that variable when the first program finishes, represented by x′ in mid. The precondition might also make reference to the value of x when the first program starts, represented by x in mid. To avoid confusion, we will replace this value with a logical constant X.
The postcondition is similar to post, except that we can no longer use x to refer to the value of x when the first program starts. We must replace x with the same logical constant X . The second program is then
w,x : [mid[X/x,x/x′], post[X/x]]
Notice that the second task may involve changing variables other than x.
Law 19.8 (sequential composition introduction) For fresh constants X ,
begin
con X •
The predicate mid must not contain before variables other than x.
w,x:[pre,post] ⊑
x : [ pre, mid ] ; ′
w,x : [mid[X/x,x/x ], post[X/x]] end
19.4 / Sequential composition 307 Example 19.10
x:[true,x′ =x+2]
⊑ (sequential composition introduction)
con X •
x:[true,x′ =x+1];
x : [ x = X + 1, x′ = X + 2 ]
Example 19.11 Suppose that we want to swap two variables without using a third variable to store the intermediate value. Suitable code might be developed as follows:
x,y:[true,x′ =y∧y′ =x]
⊑ (sequential composition introduction) con X1,Y1 :Z•
x,y:[true,x′ =x−y∧y′ =x]; [▹]
x=X −Y x′=Y
x,y: 1 1 1 [†]
y = X1 , y′ = X1
⊑ (sequential composition introduction) con X2,Y2 •
x,y:[true,x′ =x−y∧y′ =y]; [▹]
x=X −Y x′=X −Y
x,y: 2 2 2 2 [‡]
y=Y2 , y′=X2 ⊑ (assignment introduction)
x := x − y
‡
⊑ (assignment introduction) y := x + y
†
⊑ (assignment introduction) x := y − x
308 19 / Refinement Calculus
Note the use of marginal markers. The ▹ symbol always points to the next part of the program to be refined. Other marginal markers refer to parts of the program whose development proceeds at a later point.
The development is recorded as a flattened tree of refinements. It is not difficult to see how the tree may be walked in order to extract the code from the development. If we do this, we obtain
x,y : [x = X ∧ y = Y, x = Y ∧ y = X ]
⊑
begin con X1,Y1 : Z •
begin con X2, Y2 • x := x − y ;
y := x + y end ;
x := y − x end
⊑
x := x − y ; y := x + y ; x := y − x
If we want to introduce a sequential composition where the mid and post predicates make no reference to the before variables, then a simpler version of the rule may be used:
Law 19.9 (simple sequential composition) If the predicates mid and post make no reference to before variables, then
w,x:[pre,post] ⊑ x:[pre,mid]; w,x:[mid[x/x′],post]
We will often wish to introduce a sequential composition and then reduce one of the two statements to an assignment. There are two ways in which this can be done, corresponding to the following pair of derived rules.
Law 19.10 (leading assignment)
w,x : [pre[E/x], post[E/x]] ⊑ x := E ; w,x : [pre, post ]
19.5 / Conditional statements 309
Law 19.11 (following assignment)
w,x:[pre,post] ⊑ w:[pre,post[E/x′]] ; x:=E
These rules are easy to apply. First we decide upon the assignment that is to be performed, then we calculate the new specification statement.
19.5 Conditional statements
In our abstract programming notation, the language of guarded commands, a conditional statement takes the following form:
if G1→com1 G2 →com2
.
Gn →comn fi
Each branch Gi → comi is a guarded command: Gi is the guard, and comi is the command. When this conditional is activated the guards G1 , G2 , . . . , Gn are evaluated, and one of the commands whose guard is true is executed. If no guard is true, then the program aborts.
Law 19.12 (conditional introduction) If pre ⇒ (G1 ∨ G2 ∨ . . . ∨ Gn ) then
if G1 →w:[G1 ∧pre,post]
G2 →w:[G2 ∧pre,post]
. . .
w:[pre,post] ⊑
fi
If the specification is required to terminate, then the conditional must not abort: the precondition must establish that at least one guard is true. Furthermore, whichever branch is taken must implement the specification, under the assump- tion that the corresponding guard is true.
Gn →w:[Gn ∧pre,post]
310 19 / Refinement Calculus We will also employ a generalised form of the conditional statement, in
which the indexing variable may take any finite range:
if i : S Gi → comi fi where S is a finite set.
Law 19.13 (generalised conditional introduction) If pre ⇒ ∃ i : S • Gi and S is a finite set, then
w:[pre,post] ⊑ if i:S Gi →w:[Gi ∧pre,post]fi
Example 19.12 Given two variables x and y , we may develop a program that will ensure that x ≤ y, by preserving their values, or swapping them if necessary:
x ≤ y ∧ x′ = x ∧ y′ = y x , y : ∨
true , y ≤ x ∧ x′ = y ∧ y′ = x ⊑ (conditional introduction)
if x≤y→x,y:
x ≤ y ∧ x′ = x ∧ y′ = y ∨
x ≤ y , y ≤ x ∧ x′ = y ∧ y′ = x
x ≤ y ∧ x′ = x ∧ y′ = y
[▹]
[ † ]
y ≤ x → x , y : ∨
y ≤ x , y ≤ x ∧ x′ = y ∧ y′ = x)
fi
⊑ (strengthen postcondition) x,y:[x≤y,x≤y∧x′ =x∧y′ =y]
⊑ (skip introduction) skip
We complete the development with
†
⊑ (strengthen postcondition)
19.6 / Iteration 311 x,y:[y≤x,y≤x∧x′ =y∧y′ =x]
⊑ (assignment introduction) x,y := y,x
Notice that the disjunction of the guards is true, thus validating the introduction of the conditional. The program is
if x≤y→skip
y≤x→x,y:=y,x fi
To end this section, we present a pair of laws for manipulating the frame in a specification statement. If we drop the name of a variable from the frame, then it cannot change; thus, we may remove the after decoration from any of its occurrences in the postcondition.
Law 19.14 (contract frame)
w,x : [pre, post ] ⊑ w : [pre, post[x/x′]]
Conversely, we can expand the frame of a statement by adding additional vari- ables. These new variables may not be changed by the postcondition.
Law 19.15 (expand frame) w:[pre,post]=w,x:[pre,post∧x′ =x]
19.6 Iteration
In our language of guarded commands, the iteration construct is similar in form to the conditional statement:
doG1 →com1 G2 →com2
.
Gn →comn od
312 19 / Refinement Calculus
When this statement is reached, the guards are evaluated and one of the com- mands whose guard is true is executed. This is repeated until no guard is true, at which point the statement terminates.
To see how a refinement law for this construct may be formulated, suppose that inv is an invariant property of the loop: that is, a predicate that must be true before and after every iteration. Suppose further that G represents the disjunction of guards: the condition that must be true if the statement is not to terminate immediately. Such a loop may refine a specification statement that includes inv in the precondition, and inv ∧ ¬G in the postcondition.
For the refinement to be correct, the loop must be guaranteed to terminate. It is enough to identify a variant for the loop: an integer-valued function that must decrease with each iteration, but which never passes zero. If V is such a function, then the loop
do G → w : [ inv ∧ G, inv[w′/w] ∧ 0 ≤ V [w′/w] < V ] od
will refine the statement w : [inv, inv[w′/w] ∧ ¬G[w′/w]]. More formally,
we have the following law:
Law 19.16 (loop introduction)
do
w :
G
inv , 0≤V[w /w]
20.3 / Relationship between external and sectional views 327
The sectional view is more detailed than the external view, and the above result helps to demonstrate that it is in some way a refinement. The proof of the theorem is simple, increasing our confidence in our abstractions. We can explain the refinement by documenting the retrieve relation:
RetrieveExtSection Ext
Section
in = head rec out = last sent
This may be used to prove that the various operations on the concrete sectional view are correct with respect to their corresponding abstractions. Notice that the retrieve relation is actually functional from concrete to abstract. We must prove that the retrieve relation is a total function:
∀ Section • ∃1 Ext • RetrieveExtSection
We must prove that the initialisation is correct,
∀ Ext′; Section′ • SectionInit ∧ RetrieveExtSection′ ⇒ ExtInit that the transmit and receive operations are correct,
∀ Ext ; Section • pre Transmit ∧ RetrieveExtSection ⇒ pre STransmit
∀Ext; Ext′; Section; Section′ •
pre Transmit ∧ RetrieveExtSection ∧ STransmit ∧
RetrieveExtSection′ ⇒ Transmit
∀ Ext ; Section • pre Receive ∧ RetrieveExtSection ⇒ pre SReceive
∀Ext; Ext′; Section; Section′ •
pre Receive ∧ RetrieveExtSection ∧ SReceive ∧ RetrieveExtSection′ ⇒
Receive
and that the daemon is correct:
∀ Ext ; Section • pre ΞExt ∧ RetrieveExtSection ⇒ pre Daemon
∀Ext; Ext′; Section; Section′ •
pre ΞExt ∧ RetrieveExtSection ∧ Daemon ∧ RetrieveExtSection′ ⇒
ΞExt
328 20 / A Telecommunications Protocol
20.4 Enriching the model
The additional detail in the sectional view allows us to introduce concepts that were not relevant in the external view. For example, we may wish to add a new signalling point to the route. This operation has no relevance at the higher level, and cannot be expressed in terms of the abstract model.
To describe such an operation, we require an operator on sequences that allows us to insert an additional element after a given point: for example,
⟨a,b,d,e,f⟩insert (2,c) = ⟨a,b,c,d,e,f⟩ Such an operator may be defined by
[X]
insert :seqX ×(N×X)→seqX
∀ s : seq X ; i : N; x : X •
s insert (i, x) = (1 . . i) ▹ s ⌢ ⟨x⟩ ⌢ squash((1 . . i) −▹ s)
where squash takes a function and yields a valid sequence, as in Chapter 9. The InsertSection operation inserts a new SPC after a given point in the route. The new section has no messages in it, but it is glued into the route by making its input stream the output stream of the preceding section, and its
output stream the input stream of the following section:
InsertSection ∆Section s?,new? : SPC
s? ∈ ran(front route) new? ∉ ranroute
∃ i : 1 . . (#route − 1) | i = route∼ s? •
route′ = routeinsert (i,new?) rec′ = rec insert (i, sent i)
ins′ = ins insert (i, ⟨⟩)
sent′ =sentinsert(i,reci+1)
To end the chapter, we prove a useful result about our design: messages in transit are unaffected by the insertion of a new section. If ins and ins′ are
20.4 / Enriching the model 329 related according to the definition of InsertSection above, then
⌢/ins′
= ⌢/(ins insert (i, ⟨⟩))
= ⌢/((1 . . i ▹ ins) ⌢ ⟨⟨⟩⟩ ⌢ (squash(1 . . i −▹ ins)))
= ⌢/(1 . . i) ▹ ins ⌢
⌢/⟨⟨⟩⟩ ⌢
⌢/ squash((1 . . i) −▹ ins)
= ⌢/(1..i ▹ins)⌢ ⟨⟩⌢
⌢/ squash(1 . . i −▹ ins)
= ⌢/(1..i ▹ins)⌢
⌢/ squash(1 . . i −▹ ins)
= ⌢/((1..i ▹ins)⌢squash(1..i −▹ins))
= ⌢/ ins
[InsertSection] [definition of insert] [definition of ⌢/]
[definition of ⌢/] [property of ⟨⟩]
[property of ⌢/] [properties of ▹ and −▹]
This shows that messages in transit are not affected by the insertion of a new signalling point in the route. That is, the lower-level operation of manipulating the route in this way is invisible at the higher level of abstraction. The operation is therefore a daemon; this is important for the integrity of the abstraction.
Chapter 21
An Operating System Scheduler
In this chapter we describe a case study in the specification and design of a piece of software. The accent is on rigorous development, and we try to keep the overt formality to a minimum. An important aspect is the use of an auxiliary data type and its refinement; this is a common practice in large projects, where re-use is important.
The subject of the study is a scheduler: the component of an operating system that determines which process should be run, and when. We describe the service that the scheduler provides to the remainder of the operating sys- tem: the way in which it controls access to a processor. We then describe an implementation that provides this service.
21.1 Processes
The purpose of an operating system is to allow many processes to share the resources of a computer. In our system, there is a single processor to be shared, and this is made available to one process at a time. We say that a process is running when it is making use of the processor. The purpose of a scheduler is to determine which process is running, and when.
Processes must be created before they may be scheduled, and may be de- stroyed after they have served their purpose. While they exist, they may occupy one of three states:
Current Since there is a single processor, at any time, there will be at most one process running. We will call this the current process.
Ready There may be several processes that are waiting to use the processor. These processes are said to be ready.
332 21 / An Operating System Scheduler
Blocked There may be some processes that are waiting, not for the proces- sor, but for a different resource or event. These processes are said to be blocked.
While a process is running it has exclusive use of the processor. At some point, control will be passed to the kernel. This may happen because the current process has issued a service call, or it may be that the kernel interrupts it. Whatever, the scheduler will be asked to dispatch another process.
21.2 Specification
Our system will deal with up to n processes, where n is a natural number. n:N
Each process will be associated with a process identifier, or pid. For our pur- poses, a pid can be represented by a number between 1 and n.
PId == 1..n
Zero is used to represent the ‘null process’: a marker that says that there is no
process where this value is found.
nullPId == 0
An ‘optional pid’ can be either a true pid or the null pid:
OptPId == PId ∪ {nullPId}
The abstract state of the scheduler classifies every process in one of four ways: a process is either the current process, or it is ready, blocked, or free. There might not be a current process:
AScheduler current : OptPId ready : P PId blocked : P PId free : P PId
⟨{current} \ {nullPId}, ready ,
blocked ,
free⟩ partition PId
21.2 / Specification 333 The free set describes those process identifiers that are not currently in
use. Initially, all process identifiers are free, and there is no current process:
ASchedulerInit AScheduler ′
current′ = nullPId ready′ = ∅ blocked′ = ∅ free′ = PId
If there is no current process, then any process that is ready may be dispatched to the processor:
ADispatch ∆AScheduler p! : PId
current = nullPId
ready ≠ ∅
current′ ∈ ready
ready′ = ready \ {current′} blocked′ = blocked
free′ = free p! = current′
Any process which is dispatched is permitted to execute for a period of time before being interrupted. When this time period expires, it is returned to the set of ready processes:
ATimeOut ∆AScheduler p! : PId
current ≠ nullPId
current′ = nullPId
ready′ = ready ∪ {current} blocked′ = blocked
free′ = free
p! = current
The role of the nullPId value as place-holder should now be obvious.
334 21 / An Operating System Scheduler If the current becomes blocked, it is removed and added to the set of
blocked processes:
ABlock ∆AScheduler p! : PId
current ≠ nullPId
current′ = nullPId
ready′ = ready
blocked′ = blocked ∪ {current} free′ = free
p! = current
A blocked process may be woken up. This is the system signalling that the required resource is now available. The woken process must wait its turn for scheduling, so it is added to the set of ready processes:
AWakeUp ∆AScheduler p? : PId
p? ∈ blocked
current′ = current ready′ = ready ∪ {p?} blocked′ = blocked \ {p?} free′ = free
When a process is created, an identifier must be assigned from the set of free identifiers. Clearly, the free set must be non-empty for this to be possible:
ACreate ∆AScheduler p! : PId
free ≠ ∅
current′ = current ready′ = ready ∪ {p!} blocked′ = blocked free′ = free \ {p!}
p! ∈ free
At the end of its life, a process may be destroyed. If the designated process
21.2 / Specification 335 is the current process, then afterwards there is no current process, and the
process identifier becomes available for further use.
ADestroyCurrent ∆AScheduler
p? : PId
p? = current current′ = nullPId ready′ = ready blocked′ = blocked free′ = free ∪ {p?}
If the process is ready, it is destroyed and the identifier becomes available for further use:
ADestroyReady ∆AScheduler p? : PId
p? ∈ ready
current′ = current ready′ = ready \ {p?} blocked′ = blocked free′ = free ∪ {p?}
The designated process might be a blocked process; again, it is destroyed, and the identifier becomes available again:
ADestroyBlocked ∆AScheduler
p? : PId
p? ∈ blocked
current′ = current ready′ = ready
blocked′ = blocked \ {p?} free′ = free ∪ {p?}
The destroy operation comprises these three cases:
ADestroy = ADestroyCurrent ∨ ADestroyReady ∨ ADestroyBlocked
336 21 / An Operating System Scheduler
21.3 Chains
Our scheduler is a piece of low-level system software, and its implementation may use only very simple facilities. We intend to write a program with a simple data structure using an array and a few counters. If we were using a high- level programming language, we might well use a linked list implemented with pointers. As it is, we must implement our linked list directly.
A chain is a finite injection from PId to PId with a unique start and a unique end. The start of a chain is a pid that is in the domain of the injection but not the range; the end is a pid that is in the range but not the domain. We will include both the start and the end of a chain as components in a schema that characterises the data type of chains. For convenience, we will include another component, set , to identify the set of all pids that appear in the chain, including the start and the end:
Chain
start , end : OptPId links : PId PId set : F PId
set = dom links ∪ ran links ∪ ({start } \ {nullPId }) links = ∅ ⇒ start = end
links ≠ ∅ ⇒
{start } = (dom links ) \ ran links
{end } = (ran links ) \ dom links ∀e:set |e≠start •start e∈links+
The final part of the data type invariant insists that the elements of the chain are connected, in the sense that every one may be reached from the start pid by applying the function links a finite number of times. This is enough to guarantee the uniqueness of the start and end elements.
For convenience, we use the null pid to represent the start and end points of an empty chain. With the above invariant, it is the case that
set = ∅ ⇒ start = nullPId ∧ end = nullPId
The initial state of a chain is described by the following schema:
ChainInit Chain′
start′ = nullPIdend′ = nullPId
21.3 / Chains 337
We will define three operations on elements of this data type. The first describes the effect of pushing an element onto the end of a chain. There are two cases to consider. If there is no end point, then the injection must be empty, and the new element will become the end point:
PushEmpty ∆Chain
p? : PId
end = nullPId end′ =p? links′ = links
If there is an end point, then we update the chain so that the end points to the new element:
PushNonEmpty ∆Chain
p? : PId
end ≠ nullPId
links′ = links ∪ {end p?}
A successful push operation is then
Push = PushEmpty ∨ PushNonEmpty
Our second operation describes the effect of popping an element from the front of a chain; this will be successful if there is at least one element present. Again, there are two cases to consider. If the chain has only one element—if links must be empty but start is not null—then the new start will be null:
PopSingleton ∆Chain
p! : PId
start ≠ nullPId links = ∅ start′ = nullPId links′ = links p! = start
338 21 / An Operating System Scheduler
Notice that the new value of end is determined by the state invariant.
If there is more than one element in the chain, then the start element is
provided as output, and the start point moved along the chain.
PopMultiple ∆Chain
p! : PId
links ≠ ∅
start′ =linksstart links′ = {start} −▹ links p! = start
A successful pop operation is then
Pop = PopSingleton ∨ PopMultiple
Our third operation describes the effect of deleting an element from a chain. If this element is the first element in the chain, then the delete operation has an effect that is similar to Pop:
DeleteStart ∆Chain
p? : PId
p? = start
∃ p! : PId • Pop
Notice how we simply ignore the popped element, hiding the output from the Pop operation within an existential quantification.
If the designated element is at the end of the chain, then the effect is dif- ferent. The last link in the chain simply disappears:
DeleteEnd ∆Chain p? : PId
p? ≠ start
p? = end
links′ = links −◃ {end}
The disappearance is described by range subtraction; the data type invariant is enough to determine the new value of end.
21.4 / Design
339
Figure 21.1 A middle element
If the designated element is in the chain, but at neither end, then the effect is different again. Consider the situation pictured in Figure 21.1. The previous element—which is identified as links∼ p?—will be mapped to the next element— which is identified as links p?. In the following schema, p? itself is removed using domain restriction:
DeleteMiddle ∆Chain
p? : PId
p? ≠ start
p? ≠ end
p? ∈ set
links′ = {p?} −▹ links ⊕ {links∼ p? links p?}
A successful delete operation is then
Delete = DeleteStart ∨ DeleteMiddle ∨ DeleteEnd 21.4 Design
We will now formulate a design for the scheduler based upon the chain data type. Our design will involve three chains: one each for the sets of ready, blocked, and free processes.
ReadyChain =
Chain[rstart/start, rend/end, rlinks/links, rset/set]
BlockedChain =
Chain[bstart/start, bend/end, blinks/links, bset/set]
FreeChain =
Chain[fstart/start, fend/end, flinks/links, fset/set]
340 21 / An Operating System Scheduler The initial states of the ready and blocked chains are defined in terms of
the initialisation schema ChainInit: ReadyChainInit =
ChainInit [rstart ′ /start ′ , rend ′ /end ′ , rlinks ′ /links ′ , rset ′ /set ′ ] BlockedChainInit =
ChainInit [bstart ′ /start ′ , bend ′ /end ′ , blinks ′ /links ′ , bset ′ /set ′ ] The free chain, however, is initially full:
FreeChainFull FreeChain
fset′ = PId
We will require push and pop operations on the ready and free chains, and push and delete operations on the blocked chain. We may define these by renaming the components of the corresponding operations on Chain:
PushReadyChain =
Push[rstart/start, rend/end, rlinks/links, rset/set,
rstart′/start′, rend′/end′, rlinks′/links′, rset′/set′]
PopReadyChain =
Pop [rstart /start , rend /end , rlinks /links , rset /set ,
rstart′/start′, rend′/end′, rlinks′/links′, rset′/set′]
DeleteReadyChain =
Delete[rstart /start , rend /end , rlinks /links , rset /set ,
rstart′/start′, rend′/end′, rlinks′/links′, rset′/set′]
PushBlockedChain =
Push[bstart/start, bend/end, blinks/links, bset/set,
bstart′/start′, bend′/end′, blinks′/links′, bset′/set′]
DeleteBlockedChain =
Delete[bstart /start , bend /end , blinks /links , bset /set ,
bstart′/start′, bend′/end′, blinks′/links′, bset′/set′]
PushFreeChain =
Push[fstart/start, fend/end, flinks/links, fset/set,
fstart′/start′, fend′/end′, flinks′/links′, fset′/set′]
21.4 / Design 341
PopFreeChain =
Pop [fstart /start , fend /end , flinks /links , fset /set ,
fstart′/start′, fend′/end′, flinks′/links′, fset′/set′]
The state of the concrete scheduler comprises the three chains, together
with an optional current process:
CScheduler
ReadyChain BlockedChain
FreeChain
current : OptPId chainstore : PId → OptPId
⟨{current } \ {nullPId }, rset , bset , fset ⟩ partition PId rlinks = rset ▹ chainstore ◃ rset
blinks = bset ▹ chainstore ◃ bset
flinks = fset ▹ chainstore ◃ fset
current ≠ nullPId ⇒ chainstore current = nullPId
It is also useful to identify the working space used: the component chainstore
is the union of the three chain functions, plus an optional map to nullPId. Initially, there is no current process, and all chains are empty:
CSchedulerInit CScheduler ′ ReadyChainInit BlockedChainInit FreeChainFull
current′ = nullPId
When a process is dispatched to the processor, the ready chain is popped; the result becomes the current process.
342
21 / An Operating System Scheduler
CDispatch ∆CScheduler p! : PId ΞBlockedChain ΞFreeChain
current = nullPId rset ≠ ∅ PopReadyChain current′ = p!
When the current process times out, it is pushed onto the ready chain. If there is no such process, this is impossible.
CTimeOut ∆CScheduler p! : PId ΞBlockedChain ΞFreeChain
current ≠ nullPId PushReadyChain[p!/p?] current′ = nullPId
p! = current
When the current process is blocked, it is pushed onto the blocked chain. Again, if there is no such process, this is impossible.
CBlock ∆CScheduler p! : PId ΞReadyChain ΞFreeChain
current ≠ nullPId PushBlockedChain[p!/p?] current′ = nullPId
p! = current
When a blocked process is woken up, it is pushed onto the ready chain:
21.4 / Design 343
CWakeUp ∆CScheduler p? : PId ΞFreeChain
p? ∈ bset DeleteBlockedChain PushReadyChain current′ = current
For this operation to be successful, it must be applied only when the process identifier in question is present in the blocked chain.
When a process is created, an identifier is popped off the free chain and pushed onto the ready chain.
CCreate ∆CScheduler p! : PId ΞBlockedChain
fset ≠ ∅
current′ = current PopFreeChain PushReadyChain[p!/p?]
Since PushReadyChain expects an identifier as input, we use schema renaming to capture the effect of process creation: the identifier in question is not chosen by the environment of the scheduler, but is instead supplied as output.
If the current process is destroyed, then the ready and blocked chains are unaffected. The process identifier is pushed onto the free chain:
CDestroyCurrent ∆CScheduler
p? : PId ΞReadyChain ΞBlockedChain
p? = current current′ = nullPId PushFreeChain
If a process is destroyed when ready, then the current process and the blocked chain are unaffected. The appropriate identifier is deleted from the ready chain
344 21 / An Operating System Scheduler and pushed onto the free chain:
CDestroyReady ∆CScheduler p? : PId ΞBlockedChain
p? ∈ rset
current′ = current DeleteReadyChain PushFreeChain
If a process is destroyed when blocked, then the current process is again unaffected. The identifier is deleted from the blocked chain and pushed onto the free chain:
21.5
CDestroyBlocked ∆CScheduler
p? : PId ΞReadyChain
p? ∈ bset
current′ = current DeleteBlockedChain PushFreeChain
Correctness of the design step
To see how the abstract and concrete descriptions are related, consider the following abstract state:
current = 3 ready = {2, 4, 6} blocked = {5, 7} free = {1, 8, 9, 10}
There are many concrete states that correspond to this; one possibility is
current = 3
21.5 / Correctness of the design step 345
Figure 21.2 Chains chainstore = {1 8, 2 6, 3 0, 4 2, 5 0,
6 0, 7 5, 8 9, 9 10, 10 0} rlinks = {4 2, 2 6}
rset = {2, 4, 6}
bstart = 7
bend = 7
blinks = {7 5} bset = {5, 7}
fstart = 1
fend = 10
flinks = {1 8, 8 9, 9 10} fset = {1, 8, 9, 10}
This configuration is illustrated in Figure 21.2.
The connection between the concrete and abstract descriptions is described
by the following schema:
rstart = 4 rend = 6
346
21 / An Operating System Scheduler
RetrScheduler AScheduler CScheduler
ready = rset blocked = bset free = fset
This is a functional refinement: the retrieve relation is functional from concrete to abstract.
To show that this refinement is correct, we have only to confirm the func- tionality of the retrieve relation,
CScheduler ⊢ ∃1 AScheduler • RetrScheduler
and then check the simplified requirements for initialisation and correctness:
CSchedulerInit ∧ Retr′ ⊢ ASchedulerInit preAOp∧Retr∧COp∧Retr′ ⊢AOp
The correctness requirement should be checked for every pair of abstract and concrete operations.
Chapter 22
A Bounded Buffer Module
In this chapter we present a rigorous development of a bounded buffer: a finite data store that behaves as a first-in first-out queue. We begin by describing the behaviour of the module as an abstract data type, using the language of schemas. This is refined to another description that is more suggestive of a programming language implementation. This description is then translated into the refinement calculus and refined to code.
22.1 Specification
A bounded buffer is a data store that may hold a finite number of values. It behaves as a first-in first-out queue: values leave in the order in which they arrive. We will develop a programming language implementation of a bounded buffer with three operations:
• BufferInit, an initialisation
• BufferIn, providing input to the buffer
• BufferOut, accepting output from the buffer
Each of these operations will be described at three levels of abstraction: as part of a specification, as part of a design, and as part of an implementation.
At the specification level, the state of a bounded buffer will include three components:
• buffer: a sequence of values
• size: the number of values present
• max size: an indication of the buffer’s capacity
348 22 / A Bounded Buffer Module The sequence buffer , and the state itself, will use a generic parameter X to
refer to the type of values to be stored:
Buffer [X ] buffer : seq X size : N
max size:N
size = #buffer size ≤ max size
The number of values present is equal to the length of the sequence, and must never exceed the maximum buffer size.
At initialisation, the bounded buffer is empty: buffer is equal to the empty sequence and size is zero:
BufferInit [X ] Buffer′[X]
buffer′ =⟨⟩
The value of max size is left unconstrained: a suitable value should be chosen when the buffer is instantiated.
The capacity of the buffer cannot be changed after instantiation; this fact is recorded as an invariant in the following schema:
UpdateBuffer [X ] Buffer [X ] Buffer′[X]
max size′ = max size
If the buffer is not full, an item may be inserted:
BufferIn0[X ] UpdateBuffer [X ] x? : X
size < max size buffer′ =buffer⌢⟨x?⟩
The new value is appended to the end of sequence buffer.
22.1 / Specification 349 Extracting an item is possible only if the buffer is not empty; the value
obtained is the one at the head of buffer:
BufferOut0[X ] UpdateBuffer [X ] x! : X
buffer ≠ ⟨⟩
buffer′ =tailbuffer x! = head buffer
These schemas represent partial operations: they describe the effect of a suc- cessful insertion and a successful extraction, respectively.
To provide a more informative interface to our data type, we consider a pair of error cases, each with its own report. We introduce a free type of reports with three elements:
Report ::= ok | full | empty
ok will be used to indicate a favourable outcome to an operation, full will be used to indicate that the buffer is full, and empty will be used to indicate that the buffer is empty.
We include a successful report as the single output component in a schema with no constraint:
Success
report! : Report
report! = ok
while the other reports are associated with predicates upon the current state.
The error report full may be obtained only if size is equal to max size:
BufferInError [X ] ΞBuffer [X ] report! : Report
size = max size report! = full
The inclusion of ΞBuffer [X ] indicates that the state of the buffer is unchanged by this operation.
350 22 / A Bounded Buffer Module
Operation
Precondition
BufferInit
true
BufferIn0 BufferInError BufferIn
size < max size size = max size true
BufferOut0 BufferOutError BufferOut
buffer ≠ ⟨⟩ buffer = ⟨⟩ true
Table 22.1 Preconditions in the bounded buffer specification
The report empty may be obtained only if the sequence buffer is equal to the empty sequence:
BufferOutError [X ] ΞBuffer [X ]
report! : Report
buffer = ⟨⟩ report! = empty
Again, the state of the buffer is left unchanged.
We may define total versions of the input and output operations:
BufferIn[X] =
(BufferIn0[X] ∧ Success) ∨ BufferInError[X]
BufferOut[X] =
(BufferOut0[X] ∧ Success) ∨ BufferOutError[X]
A simple precondition analysis will confirm that the input operation will be suc- cessful unless the buffer is full, and that the output operation will be successful unless the buffer is empty.
The preconditions associated with these operations are summarised in Ta- ble 22.1. Notice that the input operation is total on valid states of the system, as the remaining possibility—that the current buffer size is greater than the capacity—is outlawed by the state invariant.
22.2 / Design 351
22.2 Design
We may now present a more concrete description of the bounded buffer: a design for implementation. Our description is based upon the idea of a circular array: an array in which the two ends are considered to be joined. We will maintain two indices into this array, a bottom and a top, to delimit the values that are of interest. This part of the array is then a concrete representation of the bounded buffer.
The size of the array will correspond to the capacity of the bounded buffer that it represents. Because of this, we need some way of distinguishing between the case in which the buffer is empty—the two indices coincide—and the case in which the buffer is full—again, the two indices coincide. Accordingly, we maintain a separate record of the number of values stored.
At the design level, there are five components in the state schema:
• array: a sequence of values
• max size: the capacity of the buffer
• bot: the index of the first value stored
• top: the index of the last value stored
• size: the number of values stored
Although the circular array is modelled as a sequence, this sequence will be used in a way that reflects our design intentions:
Array [X ] array : seq X max size:N bot,top : N size : N
bot ∈1..max size
top∈1..max size
size∈0..max size
#array = max size
sizemodmax size=(top−bot+1)modmax size
When the buffer is full, we have size = max size; when the buffer is empty, we have size = 0. In either of these two extremes, it is the case that
top+1modmax size=bot
352 22 / A Bounded Buffer Module As in the specification, we will insist that the capacity of the buffer cannot
be changed after installation:
UpdateArray [X ] Array [X ] Array′[X]
max size′ = max size
Since max size is included as part of the design state, the invariant property is
exactly the same.
22.3 A retrieve relation
The connection between concrete and abstract states is a simple one. If we cut the circular buffer immediately below the bot mark, and then straighten it out, we will find that the first size elements are the same as those in the abstract buffer. Alternatively, if we shift the circular buffer so that bot occurs at position 1, then trim away the waste, then we have the abstract buffer.
To help us in writing the retrieve relation, we introduce a shift operator on sequences: ≪ . We can shift an empty sequence indefinitely, but it will still be empty.
n ≪ ⟨⟩ = ⟨⟩
If we shift a sequence by no places at all, then we leave it unchanged:
0≪s=s
If we shift a non-empty sequence by one place, the first becomes the last:
1 ≪ (⟨x⟩ ⌢ s) = s ⌢ ⟨x⟩
A suitable generic definition would be
[X]
≪ :N×seqX →seqX
∀ n : N; x : X ; s : seq X •
n≪⟨⟩=⟨⟩ ∧
0≪s=s∧
(n + 1) ≪ (⟨x⟩ ⌢ s) = n ≪ (s ⌢ ⟨x⟩)
22.3 / A retrieve relation 353
Figure 22.1 A circular array with pointers
Returning to the retrieve relation, consider the circular buffer shown in Figure 22.1. To extract the abstract object represented by this buffer, we may shift the concrete sequence by two places, and then restrict the result to the indices 1 . . 4. That is, we extract
(1 . . 4) ▹ (2 ≪ ⟨1, 2, 3, 4, 5, 6, 7, 8⟩) = (1..4)▹⟨3,4,5,6,7,8,1,2⟩
= ⟨3,4,5,6⟩
In general we have the retrieve relation
RetrieveBuffer [X ] Buffer [X ]
Array [X ]
buffer =(1..size)▹((bot−1)≪array)
Notice that the retrieve relation is a total, surjective function, so that we can calculate the data refinement.
354
22 / A Bounded Buffer Module The successful part of the input operation may be calculated as
ArrayIn0[X ] UpdateArray [X ] x? : X
#((1..size)▹((bot−1)≪array))
bot′ =(botmodmax size)+1∧ array′ = array
[property of equality]
The right-hand side of the third predicate can be rewritten as follows:
head (1 . . size ▹ (bot − 1 ≪ array )) = (1 . . size ▹ (bot − 1 ≪ array )) 1 = (bot − 1 ≪ array) 1
= array bot
[provided that size ≠ 0] [provided that size ≠ 0] [property of shifting]
Provided that the buffer is not empty, we should decrement the size; increment bot; leave top alone; and output the element that was indexed by bot.
Using these calculations to simplify the operation schema that describes the concrete output operation, we obtain
ArrayOut0[X ] UpdateArray [X ] x! : X
size ≠ 0
size′ = size − 1
bot′ = (bot mod max size) + 1 array′ = array
x! = array bot
The error case is easily calculated:
ArrayOutError [X ] ΞArray [X ]
report! : Report
(1 . . size) ▹ ((bot − 1) ≪ array ) = ⟨⟩ report! = empty
Again, this may be simplified:
360
22 / A Bounded Buffer Module
ArrayOutError [X ] ΞArray [X ]
report! : Report
size = 0
report! = empty
The robust version of the concrete output operation is then
ArrayOut[X] = ArrayOut0[X]∧Success ∨
ArrayOutError [X ] 22.4 Implementation
Our implementation of the design will be parameterised by the maximum size of the buffer. The global declarations for our bounded buffer module will be
var ibuffer :array [1..max size]of X ; bot,top:1..max size; size:0..max size;
andsizemodmax size=(top−bot+1)modmax size We will begin with the concrete input operation:
ArrayIn0[X ] ∧ Success IBufferIn[X ] = Array′[X ] : true , ∨
The derivation of code is quite simple:
IBufferIn[X] ⊑
if size < max size →
ArrayInError [X ]
Array′[X ] : [ size < max size, ArrayIn0[X ] ∧ Success ] [▹] size = max size →
Array′[X]:[size=max size,ArrayInError[X]] [†] fi
We refine the first alternative
▹
22.4 / Implementation
⊑ (strengthen postcondition)
Array′[X ] :
size < max size , ⊑ (assignment introduction)
size := size + 1; top:=(topmodmax size)+1; ibuffer := ibuffer ⊕ {top x} ; report! = ok
and then the second alternative:
†
⊑ (strengthen postcondition)
361
size′ = size + 1 bot′ = bot
Array′[X ] : size = max size , report! = full ⊑ (assignment introduction)
report! := full
top′ = (top mod max size) + 1 ibuffer′ = ibuffer ⊕ {top′ x?}
report! = ok
Collecting the code, and encapsulating the input operation as a parameterised procedure with value and result parameters—with the usual programming lan- guage interpretation—we have
procedure BufferIn[X]
(val x : X ; res report ! : Report ) ; if size < max size →
size := size + 1; top:=(topmodmax size)+1; ibuffer[top] := x ;
report! = ok
size = max size → report! := full
fi
The following specification statement corresponds closely to the concrete
362 22 / A Bounded Buffer Module output operation:
ArrayOut0 [X ] ∧ Success IBufferOut[X] = Array′[X] : true , ∨
This may be refined as follows:
IBufferOut [X ]
⊑ (conditionalintroduction)
if size≠0→
Array′[X ] : [ size ≠ 0, ArrayOut0[X ] ∧ Success ]
size=0→
Array′[X] : [size = 0, ArrayOutError[X]]
We may refine the first alternative:
▹
⊑ (strengthen postcondition)
Array′[X]:
size ≠ 0 ,
⊑ (assignment introduction)
[▹] [†]
fi
ArrayOutError [X ]
size′ = size − 1
bot′ =(botmodmax size)+1
array′ =array report! = ok
size := size − 1; bot := (bot mod max size) + 1; report! := ok and the second alternative:
†
⊑ (strengthen postcondition)
Array′[X] : [size = 0, report! = empty ]
⊑ (assignment introduction)
report! := empty
We may collect the code and encapsulate the output operation as a parame-
22.5 / Executable code 363 terised procedure:
procedure IBufferOut
(res report : ReportType) ; if size≠0→
size := size − 1;
bot := (bot modmax size)+1; report! := ok
size=0→ report! := empty
fi
Similarly, we may derive a procedure that accepts a single value and resets the buffer to hold just that value:
procedure ResetBuffer[X] (val x : X ) ;
bot,top,size,ibuffer[1] := 1,1,1,x
A suitable initialisation for the buffer module is described by the following
assignment:
initially bot,top,size:=1,max size,0 22.5 Executable code
We may now translate our refinement calculus implementation into executable code. The language chosen is Modula2:
MODULE Buffer;
EXPORT
max_size, ReportType, ResetBuffer,
BufferIn, BufferOut;
CONST
max_size = N;
TYPE
ReportType = ( OK, Full, Empty );
VAR
364
22 / A Bounded Buffer Module
ibuffer: ARRAY [ 1 .. max_size ] OF X;
bot, top: 1 .. max_size;
size: 0 .. max_size;
PROCEDURE ResetBuffer ( x: X );
BEGIN
bot := 1;
top := 1;
size := 1;
ibuffer[1] := x
END;
PROCEDURE BufferIn ( x: X; VAR report: ReportType );
IF size < max_size THEN
BEGIN
size := size + 1;
top := ( top MOD max_size ) + 1;
ibuffer[top] := x;
report = OK
END
ELSE report := Full;
PROCEDURE BufferOut ( VAR report: ReportType );
IF size <> 0 THEN
BEGIN
size := size – 1;
bot := ( bot MOD max_size ) + 1;
report := OK
END
ELSE report := Empty;
BEGIN
bot := 1;
top := max_size;
size := 0
END Buffer;
Chapter 23
A Save Area
In this chapter we present the specification and development of a save area, a module in an operating system with two operations, Save and Restore, by means of which records are stored and retrieved in a last-in first-out manner. Such a module may be useful in a check-pointing scheme, for instance, where the current state of a record structure is saved. At a later time, the system can be restored to this state.
Our specification is nondeterministic, delaying a key design decision until a more appropriate stage of development is reached. The development itself is in two parts: a decision is taken to introduce a two-level memory; a representation is chosen for the data structure used in main memory.
The design is produced using calculation. A concrete state is proposed, and its relation to the abstract state is documented. The concrete operations are then calculated from the abstract operations and the retrieve relation. The lowest level of design provides the starting point for the calculation of the code using the refinement calculus.
23.1 Specification
Our specification of the save area will leave abstract the details of the records being manipulated. We introduce a basic type
[Record ]
to represent the set of all records. Each operation will return a status report;
the free type of reports is defined by
Status ::= ok | full | empty
366 23 / A Save Area The state of the system comprises a sequence of records:
SaveArea
save area : seq Record
Initially, no records have been stored and this sequence is empty:
InitSaveArea SaveArea′
save area′ = ⟨⟩
We will use the sequence as a stack, with the last element as the top of the
stack. When a record is stored, it is placed at the end:
Save0 ∆SaveArea record? : Record status! : Status
save area′ = save area ⌢ ⟨record?⟩ status! = ok
It is easy to see that Save0 is total, but the Save operation may fail: there may not always be enough room to store the new record. We do not have enough state information to predict when this may happen.
We could remedy this by adding a component to describes the amount of store left; this value would be updated every time save area was modified. However, the amount of free space left in the system is influenced by factors other than the size of the records and the number stored. We would need to model the rest of the system in some way.
Following this path leads us away from abstraction and modularity. It is better to admit that we do not know the circumstances—at this level of abstraction—that determine the amount of free space and hence the success or failure of the Save operation. Thus the error case for Save is described by
SaveFullErr ΞSaveArea status! : Status
status! = full
23.1 / Specification 367
The complete description of Save is then Save = Save0 ∨ SaveFullErr
This is a nondeterministic specification: whenever the operation is used, it may succeed in appending the record and report ok, or it may leave the state unchanged and report full.
It is useful at this point to draw a distinction between a nondeterministic specification, such as this, and a loose specification. A loose specification is one in which a constant is introduced with a range of values: for example, we may declare a constant n thus
n:N
This constant is then a parameter to the specification.
Suppose that we have another parameterised specification, identical in ev-
ery way except for the fact that the range of n is restricted: n : 1 . . 10
Although we have been more precise about the value of n, this restriction is not a refinement in the sense described above: it is merely a tighter version of the same specification.
A loosely-specified constant is there to be instantiated at any stage of devel- opment: we may make this choice during specification, or retain the constant as a parameter of the design. A nondeterministic operation—such as Save— involves an internal choice of behaviours: we must propose an implementation that will behave accordingly.
The Restore operation is wholly deterministic. We can restore a record whenever there is at least one record in save area:
Restore0 ∆SaveArea
r! : Record status! : Status
save area ≠ ⟨⟩
save area = save area′ ⌢ ⟨r !⟩ status! = ok
The last record in the save area is removed from the stack and provided as output; the success of the operation is reported.
368
23 / A Save Area
Operation
Precondition
Save Save0 SaveFullErr
Save
true true true
Restore Restore0 RestoreEmptyErr
Restore
save area ≠ ⟨⟩ save area = ⟨⟩ true
Table 23.1 Preconditions for the save area
However, if save area is empty, then we must return an error message:
RestoreEmptyErr ΞSaveArea status! : Status
save area = ⟨⟩ status! = empty
The complete description of Restore is then Restore = Restore0 ∨ RestoreEmptyErr
The preconditions for the operations in this interface are collected in Table 23.1. 23.2 Design
Our first design decision involves the introduction of a two-level memory. Large amounts of data will be saved, and this will quickly exhaust the main memory available to our program. Accordingly, we will employ secondary memory; once the main memory is exhausted, we will copy it here.
Let n be the number of records that we can save in main memory. We insist that the value of n—a parameter to the specification—is at least 1:
n:N n≥1
23.2 / Design 369 We define two sets of sequences: a bounded sequence is one whose length does
not exceed n; a full sequence is one whose length is exactly n.
[X]
bseq : P(seq X ) fseq : P(seq X )
bseq = { s : seq X | #s ≤ n } fseq = { s : seq X | #s = n }
Our concrete design employs main and secondary memory: main memory is a bounded sequence of records; secondary memory is a list of full sequences:
CSaveArea
main : bseq[Record] secondary : seq(fseq[Record])
We can extract our abstract description using distributed concatenation:
Retrieve SaveArea CSaveArea
save area = (⌢/ secondary ) ⌢ main
For a given value of n, there is only one way in which the save area sequence can be split into main and secondary. Similarly, there is only one way that main andsecondarycanbecombinedtomakesave area,iforderistobemaintained.
The retrieve relation described by this schema is a total bijection, and we may use it to derive an initialisation:
CSaveArea′ (⌢/secondary′)⌢main′ =⟨⟩
There is a unique solution to the equation in the predicate part:
(⌢/secondary′)⌢main′ =⟨⟩
⌢/secondary′ = ⟨⟩ ∧ main′ = ⟨⟩ [catenation] secondary′ = ⟨⟩ ∧ main′ = ⟨⟩ [distributed catenation]
370 23 / A Save Area The initialisation of the two-level system is given by
InitCSaveArea CSaveArea′
main′ = ⟨⟩ secondary′ = ⟨⟩
The concrete version of Save0 may be obtained using substitution:
∆CSaveArea record? : Record status! : Status
(⌢/ secondary′) ⌢ main′ = (⌢/ secondary) ⌢ main ⌢ ⟨record?⟩ status! = ok
The first equation in the predicate part of this schema describes the concrete state change associated with this operation. It has two solutions in terms of main and secondary: either
⌢/ secondary′ = (⌢/ secondary) ⌢ main ∧ main′ = ⟨record?⟩ or
⌢/ secondary′ = ⌢/ secondary ∧ main′ = main ⌢ ⟨record?⟩ From the properties of distributed concatenation, it is easy to see that
⌢/secondary′ =(⌢/secondary)⌢main⇐ secondary′ = secondary ⌢ ⟨main⟩
The concrete version of Save0 is thus described by
∆CSaveArea record? : Record status! : Status
(main′ = ⟨record?⟩ ∧ secondary′ = secondary ⌢ ⟨main⟩) ∨ (main′ = main ⌢ ⟨record?⟩ ∧ secondary′ = secondary)
status! = ok
23.2 / Design 371
However, the invariant property of CSaveArea, together with the declarations of fseq and bseq, allows us to be more explicit about the factors determining the new values of main and secondary. In the first case,
secondary ⌢ ⟨main⟩ ∈ seq(fseq[Record])
secondary ∈ seq(fseq[Record]) ∧ main ∈ fseq[Record]
main ∈ fseq[Record]
main ∈ seqRecord ∧ #main = n #main = n
and in the second,
[property of sequences] [CSaveArea invariant] [definition of fseq] [CSaveArea invariant]
main ⌢ ⟨record?⟩ ∈ bseq[Record]
main ⌢ ⟨record?⟩ ∈ seq Record ∧ #(main ⌢ ⟨record?⟩) ≤ n
[definition of bseq]
main ∈ seq Record ∧ ⟨record ?⟩ ∈ seq Record ∧ #(main ⌢ ⟨record?⟩) ≤ n
[property of sequences]
⟨record?⟩ ∈ seq Record ∧ #(main ⌢ ⟨record?⟩) ≤ n
[CSaveArea invariant]
record? ∈ Record ∧ #(main ⌢ ⟨record?⟩) ≤ n
[property of sequences]
#(main ⌢ ⟨record?⟩) ≤ n (#main)+#⟨record?⟩≤n (#main)+1≤n
#main < n
The successful part of our save operation is therefore
[declaration of record?] [property of #] [property of #] [property of numbers]
372
23 / A Save Area
CSave0 ∆CSaveArea record? : Record status! : Status
( #main=n∧
main′ = ⟨record?⟩ ∧
secondary′ = secondary ⌢ ⟨main⟩ ∨
#main < n ∧
main′ = main ⌢ ⟨record?⟩ ∧ secondary′ = secondary )
status! = ok
The error case is easily calculated:
CSaveFullErr ΞCSaveArea status! : Status
status! = full
The complete description of this operation is given by
CSave = CSave0 ∨ CSaveFullErr 23.3 Further design
Our second design decision concerns the implementation of main memory stor- age. A bounded sequence such as main can be implemented using a fixed-length array; a suitable representation might be
[X] Array:P(N→ X)
Array = (1 . . n) → X
That is, a fixed-length array can be represented by a total function from the indices to the target type.
Our new design adds an array and a counter to the existing representation of secondary memory:
23.3 / Further design 373
CSaveArea1
array : Array[Record]
count : 0 . . n
secondary : seq(fseq[Record])
The counter is used to keep track of the number of records stored.
We may retrieve the bounded sequence of the abstract state by discarding any array elements whose indices are greater than the current value of the
variable count:
Retrieve1 CSaveArea CSaveArea1
main = (1 . . count ) ▹ array
The resulting retrieve relation is a total surjective function from concrete to
abstract, and we may calculate the latest refinement of the save operation:
∆CSaveArea record? : Record status! : Status
( #((1..count)▹array)=n∧
(1 . . count′) ▹ array′ = ⟨record?⟩ ∧ secondary′ =
secondary ⌢ ⟨(1 . . count ) ▹ array ⟩ ∨
#((1 . . count) ▹ array) < n ∧ (1..count′)▹array′ =
((1 . . count) ▹ array) ⌢ ⟨record?⟩ ∧ secondary′ = secondary )
status! = ok
It is easy to see that
#((1..count)▹array) = count
This simplification makes the predicate part more readable:
374
23 / A Save Area
∆CSaveArea record? : Record status! : Status
( count=n∧
(1 . . count′) ▹ array′ = ⟨record?⟩ ∧ secondary′ =
secondary ⌢ ⟨(1 . . count ) ▹ array ⟩) ∨
count < n ∧ (1..count′)▹array′ =
((1 . . count) ▹ array) ⌢ ⟨record?⟩ ∧ secondary′ = secondary )
status! = ok
The predicate part includes a disjunction; we proceed by analysing the two
cases. In case count = n, we have
(1 . . count′) ▹ array′ = ⟨record?⟩
We may infer that (1 . . count ′ ) ▹ array ′ is a singleton sequence. Hence count′ =1
and array′ may take any value as long as its first element is record?. secondary′ must take the value
secondary ⌢⟨(1..n)▹array⟩
which, since dom array is by definition 1 . . n, is simply
secondary ⌢ ⟨array⟩ In case count < n, we have
(1 . . count′) ▹ array′ = ((1 . . count) ▹ array) ⌢ ⟨record?⟩
This tells us that these two sequences have the same length, and hence that count′ =count+1.
We may then observe that
(1 . . count′) ▹ array′ = ((1 . . count) ▹ array) ⌢ ⟨record?⟩
23.3 / Further design 375 (1..(count +1))▹array′ =
= ((1 . . count) ▹ array) ⌢ ⟨record?⟩
(1..(count +1))▹array′ = ((1 . . count) ▹ array) ⊕
[since count ′ = count + 1]
{#((1 . . count) ▹ array) + 1 record?} (1..(count +1))▹array′ =
((1 . . count) ▹ array) ⊕ {count + 1 record?} (1..(count +1))▹array′ =
(1 . . (count + 1)) ▹ (array ⊕ {count + 1 record?})
[by a property of ⊕]
There are many solutions for array′, but an obvious one is array′ = array ⊕ {count + 1 record?}.
Our new operation has been simplified to
CCSave0 ∆CSaveArea1 record? : Record status! : Status
( count=n∧ count′ =1∧
array′ 1 = record? ∧
secondary′ = secondary ⌢ ⟨array⟩ ∨
count < n ∧
count′ =count+1∧
array′ = array ⊕ {count + 1 record?} ∧ secondary′ = secondary )
status! = ok
The error case is simple:
[property of ⌢] [since count ′ = count + 1]
376
23 / A Save Area
CCSaveFullErr ΞCSaveArea1 status! : Status
status! = full
and the complete definition of the save operation is
CCSave = CCSave0 ∨ CCSaveFullErr 23.4 Refinement to code
Before we move into the refinement calculus, we break the CCSave0 operation into its component disjuncts: the secondary memory update
CCUpdateSM ∆CSaveArea1 record? : Record status! : Status
count = n
count′ =1
array′ 1 = record?
secondary′ = secondary ⌢ ⟨array⟩ status! = ok
and the main memory update
CCUpdateMM ∆CSaveArea1 record? : Record status! : Status
count < n
count′ =count+1
array′ = array ⊕ {count + 1 record?} secondary′ = secondary
status! = ok
If we define save to be the refinement calculus equivalent of CCSave: save = CSaveArea1,status!:[true,CCSave]
23.4 / Refinement to code then
377
save =
CCUpdateSM
CSaveArea1, status! :
CCUpdateMM ∨
∨ true , CCSaveFullErr
We may refine this specification statement using the refinement rule for condi- tional introduction, to obtain
if count