CS4003 All Slides 4up

CS4003: Approach
CS4003: Formal Methods

When Where
Andrew Butterfield1 What
Wed 10am LB120 Lecture
1 Foundations& Methods Group,
Software Systems Laboratory Thursday 5pm LB120 Lecture
Andrew.Butterfield@cs.tcd.ie Friday 2pm LB107 mini-Solution;
Room G.39, O’Reilly Institute
Tutorial/Examples;
mini-Exercise
Michaelmas Term, 2013
CS4003 Formal Methods CS4003 Formal Methods
CS4003: Assessment CS4003: Resources
I Blackboard (mymodule.tcd.ie)
I Exam: 80% I Main Reference Text:
I Coursework: 20% Unifying Theories of Programming,
I Project: 10%
C.A.R. Hoare and Jifeng He,
I Class (Mini-)Exercises: 10% Prentice Hall, 1998.
I Mini-exercises handed out at end of Fri 2pm class. (out of print, will be uploaded to Blackboard)
I Mini-solutions due in at start of following Friday 2pm class. I Secondary Texts:
I These deadlines are hard, as solutions will be given out at I A Logical Approach to Discrete Math, D. Gries &
the start of the 2pm Friday class.
F. B. Schneider, Springer, 1993 (your JF math text!).
I Using Z , J. Woodcock & J. Davies, Prentice Hall 1996.
(out of print, will be uploaded to Blackboard)

What are “Formal” Systems? Example: System ~z= (“H-Cross-I”)
I Symbols: ~ z =
I Well-Formed Sequences, H-Things and I-Things, where:
I Specified collection of Symbols (lexicon) H-Thing : A ~ followed by Crosses:
I Specified ways of putting them together (well-formedness) Crosses : Zero or more z
I Specific ways of manipulating symbol-sequences I-Thing : A = followed by two H-Things
(inference rules) I Manipulations (let f1 and f2 stand for arbitrary Crosses).
I Typically the goal is to transform a starting sequence to a
I-absorbii
hh =~~f1 becomes ~f1
final one having desired properties.
hh swap-Cross-Hii =~f1 z~f2 becomes =~f1 ~zf2
I Goal: convert a starting I-Thing into a H-Thing
Example Interpretation
~ 0 zero
=~zz~zzz z +1 succ
= swap-Cross-Hii
hh = + plus
=~z~zzzz
=~zz~zzz + 0+1+1 0+1+1+1 2+3
= swap-Cross-Hii
hh
=~z~zzzz + 0+1 0+1+1+1+1 1+4
=~~zzzzz =~~zzzzz + 0 0+1+1+1+1+1 0+5
= I-absorbii
hh ~zzzzz 0+1+1+1+1+1 5
~zzzzz
=~f1 z~f2 99K =~f1 ~zf2 (n + 1) + m = n + (m + 1)
=~~f1 99K ~f1 0 + m = m

What’s the point? Formal Logic
We present a Formal System, called Predicate

Calculus
I We can give very precise meanings to the symbols, Symbols
I The manipulations can have a very-well defined meaning, Those used for expressions and propositional
I but, the symbols can be manipulated without our having to logic, as well as ∃, ∀, •.
understand these meanings. Well-Formedness
I which is exactly how a computer does it ! Predicates: Well structured expressions whose
I Formal Methods allow us to limit the scope for human error type is Boolean.
and to exploit the use of machines to help our analysis. Manipulation Rules
Classified as Axioms and Inference Rules.
Goal
To prove a given Predicate is “True”.
Expressions Expressions (Aggregates)
We build basic expressions out of constants (k ∈ Const ),

variables (v ∈ Var ), tuples, functions and operators:
e ∈ Expr ::= k | v constants, variables e ∈ Expr ::= (e1 , . . . , en ) | {. . .} aggregates

| (e1 , . . . , en ) | {. . .} aggregates
| e1 e2 function application
I Aggregates are distinguished by different brackets:
| e1 ⊕ e2 infix application
| (e) parenthesised expr. (e1 , . . . , en ) tuples
{e1 , . . . , en } sets
I Read e ∈ Expr ::= . . . as “e, an Expr , is …” he1 , . . . , en i sequences
..
I Read k as “a constant k ” .
I Read | as “or”
I We do not give a complete definition here of expressions,
and will extend this as the course progresses.

Expressions (Function application) Expressions (Infix operators)
I We define function application without brackets, so f x

denotes function f applied to argument x (if f is a prefix
function — most are !) e ∈ Expr ::= e1 ⊕ e2 infix operator application
I We can write function application with brackets if we prefer
so f (x ) and f x are equivalent.
I Here ⊕ denotes any infix binary operator, such as
I In some of the literature, function application is shown
+, −, ∗, /, =, <, >, ≤, ≥, ∪, ∩, . . .
explicitly with a dot, so f .x is the same as f x (or f (x ) ).
I Parentheses and precedence behave in the same manner
I In the case where f is a postfix function, then applying f to
as found in most programming languages, so x + y ∗ z is
x is written as x f (e.g. raising to a power — x 2 is the
the same as x + (y ∗ z ), but different from (x + y ) ∗ z .
squaring function 2 post-applied to x ).
I The notation used is often a matter of style, and depends
on context.
Well-Typedness Types
We make use of a rich variety of given types and type

constructors:
I We require expressions to be well typed.
e.g. we want to outlaw nonsense like 3 + (A ∪ B) or S, T ∈ Type ::= 1 unit type
h1, 0, 1, 0i − 5 = True | B boolean values
I we write the assertion that expression e has type T as | A (ASCII) characters
| N | Z | Q | R | C numbers
e:T | PT set of T
| T1 × · · · × Tn cross-product
| T∗ sequence of T
I We can consider (for now) a type T as being the set of | S→T function from S to T
values that are allowed for something of that type.
I There are rules for checking (and/or inferring) expression
types, which we ignore for now.

Expressions (Type annotations - I) Expressions (Type annotations 2)
I I Sometimes we use type annotations embedded in

e ∈ Expr ::= . . . expressions as an abuse of notation e.g..
| (e : T ) type annotation
(x : Q)2 = 2 instead of x 2 = 2
I As a standalone expression, it has type Boolean, and is
true if e has type T
I Note,if e is a variable (v ) not in scope, then v : T is always I Strictly speaking, this is ill-typed (why?), but the intention
true, and so can be considered a type declaration. was to say
I Note that an incorrect annotation is not a type error, but is (x : Q) ∧ x 2 = 2
simply a statement, so ((A ∪ B) : N) is a well-typed
boolean-valued expression that just happens to be false
(provided A ∪ B is well-typed). I Usually we shall avoid this abuse of notation.

Class 2 Expression Meaning
I What is our intended meaning for an expression ?

(e.g. x 2 + y )
I it depends on the value of x and y
I so, let x = 3 and y = 5 (say)
I OK, so then x 2 + y has value 14.
I The “meaning” of an expression is the relationship it
creates between the values of its variables and its own
overall value:
“meaning : values(x , y ) → value”
I Alternatively, we can view the meaning as a function from

variables to the expression’s value.
Environments Evaluating Expressions against Environments
Given an environment (as per previous slide), it is possible to

I We call the association of values with variables an determine the value for an expression in a systematic way.
Environment (or Interpretation) and is a table associating a
value with every variable (whose value is defined). ix + offset 6 length list
I We assume environments are always well-formed, in that = “ lookup above table ”
the associated value is always of the correct type. 4 + 2 6 length h1, 1, 2, 3, 5, 8, 13i
= “ defn. of + and length. (?) ”
Variable : Type Value
667
list : N∗ h1, 1, 2, 3, 5, 8, 13i
I e.g.: = “ defn. of 6(?) ”
ix : N 4
True
offset : N 2
(?) Where do we find the definitions +, length and 6 ?

Modelling Environments Expressions as Functions
I We usually model Environments mathematically as a finite

partial map (→)
7 from variables to values:
I Given an expression, and then an environment, we can get
the value of that expression in that environment.
ρ ∈ Env = Var →
7 Value I We can therefore view the meaning of an expression as a
(partial (?)) function from environments to values.
Here the ‘type’ Value should considered as the union of all I Let [[e]] denote the “meaning of e”, and [[e]]ρ the meaning
possible types.
given environment ρ, then we can say
I A table entry mapping variable v to value k is written as
v 7→ k . [[e]] : Env →7 Value
I A table is a set of table entry mappings (order is irrelevant): [[e]]ρ = . . .
{list 7→ h1, 1, 2, 3, 5, 8, 13i, ix 7→ 4, offset 7→ 2} The meaning function, given an expression, returns a
partial function from environment to values.
Example Predicates
I What is the meaning of expression
ix + offset 6 length list

I A Predicate is an “expression” whose type is boolean (B).
P ∈ Pred ::= . . .
w.r.t. environment
[[P ]] : Env → B
ρ = {list 7→ h1, 1, 2, 3, 5, 8, 13i, ix 7→ 4, offset 7→ 2}
Remember that “type” Value contains values of all types,
? including B, so B ⊆ Value.
I I Unlike expressions, where evaluation w.r.t. an environment
[[ix + offset 6 length list ]]ρ = True may be undefined, we insist that predicates always
evaluate to either True or False.
I We shall see how to define [[ ]] later.

Atomic Predicates True & False
I An Atomic Predicate is an expression whose overall type is
Boolean, and whose constituent parts have non-Boolean
types
A, B, C ∈ AtmPred ::= e : B I Two special predicates true and false always return True
and False respectively, regardless of the environment.
I They can be viewed as a function from an environment to
I True and true are not the same:
the values true or false.
I True : B is a boolean value
I true : Env → B is a predicate, a function from environments
[[A]] : Env → B to B.
I Similarly for False and false.
I In practise we can often ignore the distinction, using them
I Examples: interchangeably.
x +36y
f (x ) = g(x ) − h(x )
reverse(hx i a xs) = (reverse xs) a hx i
Identities Predicate Logic Syntax
Given atomic predicates we can build a richer language using

Propositional Connectives (¬ , ∧, ∨, ⇒, ≡):
I (Atomic) Predicate Expressions of the form: P ∈ Pred
::= true | false | A atomic predicates
e1 = e2
| ¬P logical negation
where e1 and e2 have the same type, are known as | P1 ∧ P2 conjunction (logic-and)
Identities. | P1 ∨ P2 disjunction (logic-or)
| P1 ⇒ P2 implication
I Identities play a major role in what is to come.
| P1 ≡ P2 equivalence
This gives us the same power as propositional calculus, a.k.a.

“digital logic”.

Predicate Logic Syntax Predicate Meanings (Propositions)
The predicate meaning function can be described as follows:

Considerably more power is obtained by adding Quantifiers
(∀, ∃, ∃1 ) to the language: [[true]]ρ =
b True
[[false]]ρ =
b False
P ∈ Pred [[e]]ρ =
b [[e]]ρ pred. meaning = expr. meaning
::= . . . already discussed [[¬ P ]]ρ =
b logical inverse of [[P ]]ρ
| ∀x : T • P universal quantification (for-all) [[P1 ∧ P2 ]]ρ =
b True iff both [[P1 ]]ρ and [[P2 ]]ρ are
| ∃x : T • P existential quantification (there-exists) [[P1 ∨ P2 ]]ρ =
b True iff either [[P1 ]]ρ or [[P2 ]]ρ are
| ∃1 x : T • P unique existence quantification
| [P ] universal closure We define implication and equivalence by translation
The type annotations (: T ) are optional and are often omitted P1 ⇒ P2 = ¬ P1 ∨ P2

when clear from context (or irrelevant!) P1 ≡ P2 = (P1 ⇒ P2 ) ∧ (P2 ⇒ P1 )
Manipulating Environments (Maps) The Meaning of Quantifiers (I)
We can now give the meaning for the main two quantifiers as:
We define the domain of an environment (dom ρ) as the set of
all variables mentioned in ρ. [[∀ x : T • P ]]ρ =
b for all values k in T
We can use one environment (ρ0 ) to override part or all of we have [[P ]]ρ⊕{x 7→k } = True
another (ρ), indicating this by ρ ⊕ ρ0 .
The bindings in the second map, extend and take precedence “∀ x : T • P is true if P is true for all x : T ”
over those in the first map — e.g.:
[[∃ x : T • P ]]ρ =
b for at least one value k in T
{a 7→ 1, b 7→ 2, c 7→ 3} ⊕ {c 7→ 33, d 7→ 44} we have [[P ]]ρ⊕{x 7→k } = True
= {a →7 1, b 7→ 2, c 7→ 33, d 7→ 44}
“∃ x : T • P is true if P is true for at least one x : T ”

Example The Meaning of Quantifiers (II)
We can now give the meaning for the other two quantifiers as:
Let T = {1, 3, 5} and evaluate:
[[∃1 x : T • P ]]ρ =
b for exactly one k in T
[[∀ x : T • x < y ]]{x 7→2,y 7→5} we have [[P ]]ρ⊕{x 7→k } = True
For all values k in {1, 3, 5} “∃1 x : T • P is true if P is true for exactly one x : T ”
k = 1 we have [[x < y ]]{x 7→1,y →5} = 1 < 5 = True
k = 3 we have [[x < y ]]{x 7→3,y →5} = 3 < 5 = True b for any ρ0 such that dom ρ0 = dom ρ
[[[P ]]]ρ =
we have [[P ]]ρ0 = True
k = 5 we have [[x < y ]]{x 7→5,y →5} = 5 < 5 = False
Overall result: False. “[P ] is true if P is true for all values of all its variables”
Evaluating Quantifiers
I Consider:
∀ n : N • prime(n) ∧ n > 2 ⇒ ¬ prime(n + 1)
True, or False?
I To evaluate a quantifier, we may need to generate all
possible environments ρ0 involving the bound variable —
tricky if type has an infinite number of values.
I In general, in order to reason about quantifiers we need to
use Axioms and Inference Rules.

Class 3 Logic Example I
Under what circumstances is the following true?
(x < 3 ∧ x > 5) ⇒ x = x + 1
Example I Commentary Implication Truth-Table
(x < 3 ∧ x > 5) ⇒ x = x + 1 The truth table for implication is as follows:

= “ definition of ⇒ ” P Q P ⇒Q
¬ (x < 3 ∧ x > 5) ∨ x = x + 1 False False True
= “ 5 < x < 3 clearly impossible ” False True True
¬ (false) ∨ x = x + 1 True False False
= “ negation ” True True True
true ∨ x = x + 1
Simply put, for P ⇒ Q,
= “ logical-OR ”
if P is false, then the whole thing is true,
true
regardless of Q.
It is always true !

Logic Example II Example II Commentary
The following statement is true: ∀ n : N • n > 2 ⇒ (prime(n) ⇒ ¬ prime(n + 1))
∀ n : N • n > 2 ⇒ prime(n) ⇒ ¬ prime(n + 1)

I Case n 6 2 : False ⇒ . . . is true.
I Case n > 2 ∧ ¬ prime(n) : True ⇒ (False ⇒ . . .) is true.
How might we argue this? I Case n > 2 ∧ prime(n) : 2 is only even prime, so here n is
odd, so n + 1 is even and therefore not prime.
Quantifier Expansion Logic Example III
I We can view quantifiers as (approximate) shorthand for Assuming all variables are natural numbers, is the statement
repeated logical-and/or:
∀x • ∃x • x < y
∀ n : N • P (n) = P (0) ∧ P (1) ∧ P (2) ∧ P (3) ∧ . . .
∃ n : N • P (n) = P (0) ∨ P (1) ∨ P (2) ∨ P (3) ∨ . . . equivalent to
∀x • x < y,
or
I The equality is exact if the type quantified over is finite:
∃z • z < y,
∀ b : B • P (b) = P (False) ∧ P (True) or neither?
∃ b : B • P (b) = P (False) ∨ P (True) (What precisely do the three statements actually mean?)
What about ∃ z • z < x ?

Example III Commentary (1) Example III Commentary (2)
I
[[∀ x • ∃ x • x < y ]]ρ [[∀ x • x < y ]]ρ

= “ by our semantics ” = “ by our semantics ”
[[∃ x • x < y ]]ρ⊕{x 7→k } , for all k [[x < y ]]ρ⊕{x 7→k } , for all k
= “ by our semantics ” = “ false if we choose k = ρ(y ) + 1 ”
[[x < y ]]ρ⊕{x 7→k }⊕{x 7→k 0 } , for all k , for some k 0 False
= “ 2nd override masks 1st ”
[[x < y ]]ρ⊕{x 7→k 0 } , for all k , for some k 0 [[∃ z • z < y ]]ρ
= “ choose k 0 = 0 ” = “ by our semantics ”
[[0 < y ]]ρ [[z < y ]]ρ⊕{z 7→k } , for some k
= “ true for natural number y if non-zero ” = “ choose k = 0 ”
y 6= 0 [[0 < y ]]ρ
= “ true for natural number y if non-zero ”
y 6= 0
I This is a statement about y , not about x , and the outer ∀ x
is masked by inner ∃ x .
Example III Commentary (3) Logic Example IV
Define the following in terms of other predicates:

I
[[∃ z • z < x ]]ρ ∃1 x • P (x )
= “ by our semantics ”
[[z < x ]]ρ⊕{z 7→k } , for some k Here P (x ) indicates explicitly that P mentions x .
= “ choose k = 0 ” A reminder:
[[0 < x ]]ρ
= “ true for natural number x if non-zero ” [[∃1 x : T • P ]]ρ =
b for exactly one k in T
x 6= 0 we have [[P ]]ρ⊕{x 7→k } = True
I This is a statement about x , not y , or z . “∃1 x : T • P is true if P is true for exactly one x : T ”

Example IV Commentary Logic Example V
∃1 x • P (x )
b (∃ x • P (x ))
= Simplify the following predicate:
∧ (∀ x • ∀ y •
(P (x ) ∧ P (y )) ⇒ x = y ) ∃x • x = y + z ∧ x < 2 ∗ y
There exists only one x satisfying P , iff
there is at least one x satisfying P
and for all x and y
if both x and y satisfy P then it must the case that x = y .
Example V Commentary Formal Methods: early History
I 1967, Robert W. Floyd, “Assigning Meanings to Programs”

Mathematical Aspects of Computer Science, AMS, Vol.19,
∃x • x = y + z ∧ x < 2 ∗ y pp19–32
= “ The only way this can be true is when x = y + z ” I Floyd described a technique for annotating flowcharts with
“ so replace x by that. ” predicates describing what should be true at every point in
∃x • y + z = y + z ∧ y + z < 2 ∗ y the execution.
= “ x is not mentioned, so ∃ is now redundant ” I 1969, C. A. R. Hoare, “An axiomatic basis for computer
y +z =y +z ∧ y +z <2∗y programming” Communications of the ACM , Vol.12, No.10,
pp576—580,583 October.
= “ y + z = y + z is clearly true ”
I Hoare introduced the notation known today as a “Hoare
y +z <2∗y
triple”:
= “ arithmetic ” Pre{prog}Post
z <y
“if Pre holds at the start and prog terminates,
then Post will be true at the end”.

Floyd’67: Annotated flowchart example Hoare’69: Proof example
 
r :=x ;

 


 


 


 




 q:=0; 




 

 
while ¬ (y 6r )

 


 


 

true y 6r ∧

 


 

do x =r +y ×q

 


 


 


 




 r :=r −y ; 




 

 
 q:=1+q
 

image © 1969 ACM

image © 1967 AMS
Floyd/Hoare as a foundation Mini-Exercise 1
I The framework we shall explore is known as “Unifying

Theories of Programming” (UTP) Q1.1 Evaluate A ∩ elems(trace) = ∅
I It is a direct descendant of the Floyd/Hoare approach in environment {A 7→ {2, 4, 6}, trace 7→ h1, 2, 1, 3i}
I UTP aims to link theories of different kinds of programming where
language: I elems takes a list and returns the set of
imperative, concurrent, functional, logical, dataflow, values in that list
assembler, … Q1.2 Is ∃ n : N • n ≥ 3 ∧ prime(n) ⇒ prime(n − 1) true
I C.A.R. (Tony) Hoare is one of the prime movers behind or false? Justify your answer
UTP
Q1.3 Write one paragraph about a software failure (not
I he spent most of time in Oxford at the Programming
yours) that you found most vexing.
Research Group (PRG)
I now with Microsoft Research, Cambridge (handwritten, due in at start of 2pm class, Fri.4th October)
I most famous outside the formal methods community for
QuickSort !

Class 4 Key Concept: Free and Bound Variables
I Expressions, Formula, Propositions and Predicates usually

involve a number of variables.
I Depending on context, a variable occurrence can be free
or bound .
I If a variable occurrence is bound , that is because there is
something in the context in which it occurs that is binding it.
I A binding occurence is something (a piece of syntax) that
mentions a variable in a special way, usually introducing it
to stand for something specific.
I If nothing is binding an occurrence of a variable, then it is
free.
I Free occurrences of variables are usually there to denote a
wide range of possible values (of a given type).
Examples of Binding — Definitions Examples of Binding — Quantifiers
I The definition (read ‘x is defined to be 3’):

I The Logic Quantifiers ∀, ∃ are examples of binding
x =
b3 (1)
constructs.
binds the variable x to 3 wherever the definition is in scope. I For example: ∃ x : Q • x 2 = 2 has
I a binding occurrence of x immediately after ∃,
I The following recursive definition of factorial: I and it is bound in the expression to the right of •.
fac(0) =
b 1 I Consider:
b n ∗ fac(n − 1)
fac(n) =
∀ x • x ≥ 3 ⇒ y = 0 ∧ ∃ y • y > 4 ∧ z = 10
binds two variables:
I The variable fac is bound wherever this definition is in scope Which variable occurrences are free, bound or binding ?
I n is bound in the righthand-side of the second line
I The binding occurrence of n is in the lefthand-side.

Answer Examples of Binding — Programs
I We shall colour-code as follows:

Free Green I In a program block, local variable declarations are binding
Binding Red I For example, code to swap x and y, using local variable
Bound Orange temp:
I
∀ x • x ≥ 3 ⇒ y = 0 ∧ ∃ y • y > 4 ∧ z = 10 { int temp ;
temp = x ;
x=y;
I the first occurrence of y is free, whilst the second and third y = temp ;
are binding and bound respectively. }
I This is why we only talk about occurrences of variables as
being free or bound.
Manipulating Free and Bound Variables Replacing Free Variables by Expressions (I)
I The key operation we use to manipulate free and bound
variables is that of substitution.
I This takes two forms: I We often want to replace free occurrences of variables by
I α-Substitution, or Renaming of Bound Variables expressions (of the same type).
I Replacing all Free Occurrences of a Variable by an I We denote the replacement by F of all occurrences of free
Expression. variable a in expression E , by the notation E [F /a].
I We change our substitution notation, instead of E [x := F ], I It is defined if none of the free variables in F have binding
we write occurrences in E .
E [F /x ]
I Example:
to denote the substitution of F for every free occurrence of
x in E . (∀ x • x ≥ 3 ⇒ y = 0 ∧ ∃ y • y > 4 ∧ z = 10) [a + 5/y ]
I This notation extends to cover multiple simultaneous = ∀ x • x ≥ 3 ⇒ a + 5 = 0 ∧ ∃ y • y > 4 ∧ z = 10
substitutions:
Note that only the free occurrence of y is affected.
E [F1 , F2 , . . . , Fn /x1 , x2 , . . . , xn ]

Replacing Free Variables by Expressions (II) Renaming Bound Variables (I)
I Substituting x − 10 for y does not work — we get a

I We can rename bound variables in a consistent way
phenomenon known as name capture: (binding, and all bound occurrences) without changing the
meaning of the underlying expression.
(∀ x • x ≥ 3 ⇒ y = 0 ∧ ∃ y • y > 4 ∧ z = 10) [x − 10/y ] I We denote the replacement of bound variable a by b in E
α
= ∀ x • x ≥ 3 ⇒ x − 10 = 0 ∧ ∃ y • y > 4 ∧ z = 10 by E {a + b} (read as “a α-becomes b”).
I It is defined if b does not occur free in E .
I The first free occurrence of y (in y = 0) is replaced by I It is defined in terms of free variable substitution:
x − 10, where the free x becomes bound! α
hh∀-α-renameii (∀ x • P ){x + y } = ∀ y • (P [y /x ])
I In E [F /x ], the free/bound status of variables in F should hh∃-α-renameii
α
(∃ x • P ){x + y } = ∃ y • (P [y /x ])
not change.
Renaming Bound Variables (II) Renaming Bound Variables (III)
I Example: I Substituting x for y is illegal:

α
(∀ y • x ≥ 3 ⇒ y = 0 ∧ ∃ y • y > 4 ∧ z = 10){y + w } α
(∀ y • x ≥ 3 ⇒ y = 0 ∧ ∃ y • y > 4 ∧ z = 10){y + x }
= ∀ w • x ≥ 3 ⇒ w = 0 ∧ ∃ y • y > 4 ∧ z = 10
= ∀ x • x ≥ 3 ⇒ x = 0 ∧ ∃ z • z > 4 ∧ z = 10
I Note that only the instances of y outside the inner ∃ y were I We see that x becomes bound !
replaced.

Using Both Substitutions Function Application
I alpha-substitution is often used to get around the
restriction associated with replacing free variables.
I Let’s say we really want to replace free y by x − 10 in the I Consider a function, defined as,
following
f (x ) =
b Erhs
∀ x • x ≥ 3 ⇒ y = 0 ∧ ∃ y • y > 4 ∧ z = 10
I If applied to an argument Earg , then the result is given by

I First, we use α-substitution to rename the binding and
replacing all free occurrences of x in Erhs by Earg :
bound occurrences of x to something different (a, say) —
α
{x + a} f (Earg ) = Erhs [Earg /x ]
∀ a • a ≥ 3 ⇒ y = 0 ∧ ∃ y • y > 4 ∧ z = 10
I Remember to use α-substitution to avoid name-capture,if

I Then we do our desired substitution [x − 10/y ]: necessary.
∀ a • a ≥ 3 ⇒ x − 10 = 0 ∧ ∃ y • y > 4 ∧ z = 10
Use in Logic — an example
I If we know that for any s : T that P [s/x ] is true, then we

can conclude that
∀x : T • P
I This inference rule is often written as

s:T P [s/x ]
∀x : T • P
I Alternatively, we have the converse law:
∀x : T • P s:T
P [s/x ]

Class 5 Rule-based Manipulation
I So far, we have seen ad-hoc ways of reasoning about

properties.
I Calculation/Evaluation
I when we had precise information about environment values
I doing symbolic evaluation
I “Handwaving”
I reasoning about a range of environments
I reasoning over infinite cases
I We need a way to reason through symbol manipulation
(the “formal approach”).
The Rules of Formal Logic Inference Rules
I Inference rules describe how we may deduce the truth of

I There are many ways to formulate the laws of logic. one statement (the consequent , C) from the truth of a
I We shall adopt the formulation of Equational Logic. collection of other statements (the antecedents Ai ), subject
I Logic proofs handled “equation-style” to some side-condition S.
I Four inference laws (Liebniz, Transitivity, Substitution,
Equanimity) A1 , ..., An
Rule Name: S
I Many axioms C
I D. Gries & F. B. Schneider, A Logical Approach to Discrete
Math, Springer-Verlag, 1994.
I G. Tourlakis, “On the Soundness and Completeness of I “From the truth of A1 and … and An we can deduce C
Equational Predicate Logics”, J. Log. Comput., Vol. 11, No. (provided S holds).”
4, pp623–653, 2001 I Side-conditions S are not predicates themselves, but are
properties of predicates.

Inference meta-Notation Axioms
I Axioms are statements which are accepted as true in their

own right, and are sometimes shown as inference rules
I Sometimes both antecedents and consequents in with no antecedents:
inference rules use extra (meta-)notation not part of the
formal language. axiom
I For example, notation
I For example. the law of the excluded middle:
P [v := Q] (Textual Substitution)
Excluded Middle:
p∨¬p
describes predicate P where all instances (if any) of
variable v have been replaced by Q
I Often axioms are simply written without any line above:
I e.g. (x < y + z )[y := 3 ∗ n] denotes x < 3 ∗ n + z
Axiom, Excluded Middle: p ∨ ¬ p
Equational Axioms of Propositional Calculus The inference rules of Equational Logic
We have four inference rules:

I Axioms are laws taken as true, as a starting point
I Different sets of axioms are possible P, P =Q
Equanimity:
I G&S define their own set, of which the following are just a Q
few:
P = Q, Q=R
hh≡-associi ((p ≡ q) ≡ r ) ≡ (p ≡ (q ≡ r )) (3.1) Transitivity:
hh≡-comm ii
P =R
p≡q≡q≡p (3.2)
hhfalse-def ii false ≡ ¬ true (3.8)
hh∨-comm ii
P
p∨q≡q∨p (3.24) Substitution: [no capture]
hhgolden-ruleii p∧q≡p≡q≡p∨q (3.35) P [r := Q]
hh⇒-joinii p⇒q≡p∨q≡q (3.57)
F =G
The numbers in parentheses are those used in G&S, but Leibniz: [v a variable]
E [v := F ] = E [v := G]
the names are different

Inference Rule: Equanimity Inference Rule: Transitivity
P = Q, Q=R
P =R
P, P =Q
Q I If P equals Q and Q equals R,
then P equals R.
I If P is true, and we know that P = Q then, we can deduce
I This key property of equality allows us to “linearise” our
that Q must be true also.
proofs.
I Simple, really !
I Assume we know that A = B, B = C, C = D and D = E ,
I Not actually mentioned in Gries & Schneider (1994), but and we want to prove that A = E .
used in that text!
I We get branching — we can use the first two equalities to
give us A = C, and the second two to get C = E , and then
combine these.
Proving with Transitivity (I) Proving with Transitivity (II)
I However, this very transitivity property allows us to re-write

the proof as
I We can use our inference rule notation to illustrate the A
proof: = “ why A = B ”
A=B B=C C =D D=E B
A=C C =E = “ why B = C ”
A=E C
= “ why C = D ”
D
I Very unwieldy ! = “ why D = E ”
E
I Much better !

Predicate textual substitution Inference Rule: Substitution
P
[no capture]
P [r := Q]
I if predicate P is true,
I Consider the consequent of Substitution: P [r := Q] then so is P with all instances of any boolean variable (r )
I We do not expect P to appear with an explicit substitution replaced by an arbitrary predicate Q, (provided r does not
(remember, [r := Q] is not in the language). occur inside any quantifier binding any free variable of Q
I Instead P [r := Q] denotes the case where: — no capture).
I P contains an occurrence of Q within it.
I Example:
I We use variable r to refer to that occurrence of Q p∨¬p
[p a boolean variable]
(p ∨ ¬ p)[p := (x 6 y + z )]
I or (performing the substitution)

p∨¬p
[p boolean]
(x 6 y + z ) ∨ ¬ (x 6 y + z )
Inference Rule: Leibniz Theorems and Proofs
F =G
[v a variable]
E [v := F ] = E [v := G]
I Theorems are predicates that are logical consequences of
the axioms and inferences rules
I If F = G then, in any predicate/expression E mentioning
F , we can replace that mention by G.
I A predicate is shown to be a theorem by providing a proof .
I A proof is either:
I a.k.a. “Substitution of equals for equals”.
I an axiom
I Here, E , F and G stand for arbitrary predicates and/or I or a consequence of an inference rule whose premises are
expressions. axioms or pre-existing theorems.
I Example I in practice, we chain these together using the linear form of
the Transitivity inference rule.
x +x =2∗x x +x =2∗x
or
(y −v )[v :=x +x ]=(y −v )[v :=2∗x ] y −(x +x )=y −(2∗x )

Example: R ≡ R ≡ S ≡ S, see G&S,p43 Example: R ≡ R ≡ S ≡ S alt. proof
hh≡-associi ((p ≡ q) ≡ r ) ≡ (p ≡ (q ≡ r )) (3.1)
hh≡-comm ii p≡q≡q≡p (3.2)
hh≡-associi ((p ≡ q) ≡ r ) ≡ (p ≡ (q ≡ r )) (3.1)
hh≡-comm ii p≡q≡q≡p (3.2)
R≡R≡S≡S
= “ hh≡-commii with R, S matching p, q resp. ”
R≡R≡S≡S
R ≡ S ≡R ≡ S
= “ hh≡-commii with p = R and q = S ”
= “ hh≡-commii with R, S matching p, q resp. ”
R≡R
R≡S≡S≡R
= “ hh≡-commii with p = R and q = S ”
“ Axiom hh≡-commii, so we are done ”
R≡S≡S≡R
“ this proof implicitly used hh≡-associi ”
“ Axiom ≡-comm , so we are done ”
hh ii
I making implicit use of associativity, commutativity is

common in hand proofs
CS4003 Formal Methods I it is not so easy for mechanical proof systems CS4003 Formal Methods
Theorems of Propositional Calculus Some Terminology
I We build a collection of proven theorems, from axioms,

using inferences.
I We can also use these theorems in other proofs Conjecture a predicate we believe is true, but with no proof
I G&S proves many, such as : (yet).
Theorem a conjecture for which we have a proof.
hh6 -commii
≡ (p 6≡ q) ≡ (q 6≡ p) (3.16)
hh∨-unit ii
Law a theorem or an axiom
p ∨ false ≡ p (3.30)
hh∧-associi
(i.e. a predicate either given as true, or proven to
(p ∧ q) ∧ r ≡ p ∧ (q ∧ r ) (3.37)
be so).
hhexclusive-or ii p 6≡ q ≡ (¬ p ∧ q) ∨ (p ∧ ¬ q) (3.53)
hh⇒-meet ii p⇒q≡p∧q≡p (3.60)
And many, many more.

Adding flexibility Derived Proof Techniques (I)
I Reduction: Prove P ≡ Q by converting P to Q (or v.v.)
I Deduction: Prove P ⇒ Q by assuming P , and proving Q
I In principle, a proof of P uses the 4 inference rules and careful: variables in P must be treated as constants !
axioms to transform P into axioms (e.g. proof of I Boolean Case Analysis:
R ≡ R ≡ S ≡ S above). Prove Q[b := P ] by
I We can also transform, using laws, to any law, to get a proving Q[b := True] and Q[b := False]
proof.
Q[b := True] Q[b := False]
i.e if P and Q are theorems, then so is P ≡ Q Boolean Case Analysis:
I However, we can also derive new inference rules (a.k.a. Q[b := P ]
derived rules)
I allows better structuring of proofs I Case Analysis: Prove P by finding Qi , i ∈ 1 . . . n such that
I in principle can be converted to proof using original four we can prove (Q1 ∨ . . . ∨ Qn ) and Qi ⇒ P for all i
rules.
(Q1 ∨ . . . ∨ Qn ) (Qi ⇒ P )i ∈1...n
Case Analysis:
P
Derived Proof Techniques (II) Mutual Transitivity

I Mutual Implication: I Transitivity works when we mix ≡ and ⇒
Prove P ≡ Q by proving P ⇒ Q and Q ⇒ P
hh⇒-transii (p ⇒ q) ∧ (q ⇒ r ) ⇒ (p ⇒ r ) (3.82)
P ⇒Q Q⇒P hh≡-⇒-transii (p ≡ q) ∧ (q ⇒ r ) ⇒ (p ⇒ r ) (3.82)

Mutual Implication: hh⇒-≡-transii
P ≡Q (p ⇒ q) ∧ (q ≡ r ) ⇒ (p ⇒ r ) (3.82)
I Contradiction: Prove P by proving ¬ P ⇒ false I We can mix these in Reduction proofs (here that P ⇒ R):
¬ P ⇒ false P
Contradiction: ⇒ “ why P ⇒ Q ”
P
Q
≡ “ why Q ≡ R ”
I Contrapositive: Prove P ⇒ Q by proving ¬ Q ⇒ ¬ P R
¬Q⇒¬P
Contrapositive: I We call this ⇒-Reduction
P ⇒Q
I Also possible is <-Reduction, using =, < and 6.
Example: x + y > 2 ⇒ (x > 1 ∨ y > 1) (G&S)
I We apply Contrapositive to get:
¬ (x > 1 ∨ y > 1) ⇒ ¬ (x + y > 2)

= “ hhdeMorganii ”
¬ (x > 1) ∧ ¬ (y > 1) ⇒ ¬ (x + y > 2)
I We now use Deduction: assume x < 1 and y < 1 as

axioms, to show x + y < 2
I We now use <-Reduction:
x +y
< “ assumption: x < 1, y < 1, arithmetic ”
1+1
= “ arithmetic ”
2

Class 6 Mini-Exercise 1
Q1.1 Evaluate A ∩ elems(trace) = ∅

in environment {A 7→ {2, 4, 6}, trace 7→ h1, 2, 1, 3i}
where
I elems takes a list and returns the set of
values in that list
Q1.2 Is ∃ n : N • n ≥ 3 ∧ prime(n) ⇒ prime(n − 1) true
or false? Justify your answer
Q1.3 Write one paragraph about a software failure (not
yours) that you found most vexing.
(handwritten, due in at start of 2pm class, Fri.4th October)
Quantifier Axioms A Theorem ! Proof ?
hh∀-1ptii (∀ x • x = E ⇒ P ) ≡ P [E /x ], x 6 E
hh∃-1ptii (∃ x • x = E ∧ P ) ≡ P [E /x ], x 6 E
hh∀-distr ii (∀ x • P ) ∧ (∀ x • Q) ≡ (∀ x • P ∧ Q)
hh∃-distr ii (∃ x • P ) ∨ (∃ x • Q) ≡ (∃ x • P ∨ Q) ¬ (∀ x • R ⇒ ¬ P )
hh∀-swapii (∀ x • ∀ y • P ) ≡ (∀ y • ∀ x • P ) = ¬ (∀ x • ¬ R ∨ ¬ P )
hh∃-swapii (∃ x • ∃ y • P ) ≡ (∃ y • ∃ x • P ) = ¬ (∀ x • ¬ (R ∧ P ))
hh∀-nest ii (∀ x , y • P ) ≡ (∀ x • ∀ y • P ) = ∃x • R ∧ P
hh∃-nest ii (∃ x , y • P ) ≡ (∃ x • ∃ y • P )
hh∀-renameii (∀ x • P ) ≡ (∀ y • P [y /x ]), y 6 P
hh∃-renameii (∃ x • P ) ≡ (∃ y • P [y /x ]), y 6 P
∨-∀-distr ii
hh P ∨ (∀ x • Q) ≡ (∀ x • P ∨ Q) x 6 P
gen-deMorgan (∃ x • P ) ≡ ¬ (∀ x • ¬ P )
hh ii

Moving Bindings Around Quantifier Distributivity
I We can distribute a quantifier through the appropriate
I the following axioms move bindings around binary propositional operator:
hh∀-swapii (∀ x • ∀ y • P ) ≡ (∀ y • ∀ x • P ) hh∀-distr ii (∀ x • P ) ∧ (∀ x • Q) ≡ (∀ x • P ∧ Q)
hh∃-swapii (∃ x • ∃ y • P ) ≡ (∃ y • ∃ x • P ) hh∃-distr ii (∃ x • P ) ∨ (∃ x • Q) ≡ (∃ x • P ∨ Q)
hh∀-nest ii (∀ x , y • P ) ≡ (∀ x • ∀ y • P )
hh∃-nest ii (∃ x , y • P ) ≡ (∃ x • ∃ y • P )
I To understand these, consider them as repeated and/or:
I often we implicitly use these laws, ignoring binding, (P (x1 ) ∧ P (x2 ) ∧ . . .) ∧ (Q(x1 ) ∧ Q(x2 ) ∧ . . .)
nesting, or ordering ≡ ((P (x1 ) ∧ Q(x1 )) ∧ (P (x2 ) ∧ Q(x2 )) ∧ . . .)
I Note these only apply when the quantifier is the same !
(P (x1 ) ∨ P (x2 ) ∨ . . .) ∨ (Q(x1 ) ∨ Q(x2 ) ∨ . . .)
(∀ x • ∃ y • P ) 6≡ (∃ y • ∀ x • P ) ≡ ((P (x1 ) ∨ Q(x1 )) ∨ (P (x2 ) ∨ Q(x2 )) ∨ . . .)
I c.f. “Quantifier Expansion” slide, Class 2.

Mixed Quantifier Distributivity Renaming
I We can distribute a quantifier through the “other” binary I We have already covered this
propositional operator, under certain circumstances:
hh ∀-renameii (∀ x • P ) ≡ (∀ y • P [y /x ]), y 6 P
hh∨-∀-distr ii P ∨ (∀ x • Q) ≡ (∀ x • P ∨ Q) x 6 P hh ∃-renameii (∃ x • P ) ≡ (∃ y • P [y /x ]), y 6 P
hh∧-∃-distr ii P ∧ (∃ x • Q) ≡ (∃ x • P ∧ Q) x 6 P
I We can uniformly replace binding and bound occurrences

I Essentially we can merge P as shown above if it does not
of one variable by another,provided the new variable is
mention x .
“fresh”.
I Law hh∧-∃-distr ii is a theorem, not an axiom I Known for historical reasons as α-renaming.
(proof depends on hhgen-deMorganii, so let’s defer this)

Generalised de-Morgan Proof of theorem hh∧-∃-distr ii
I Goal: P ∧ (∃ x • Q) ≡ (∃ x • P ∧ Q), x 6 P
I de-Morgans laws apply to quantifiers:
I Strategy: Reduce left-hand side (lhs) to right-hand side
gen-deMorganii (∃ x • P ) ≡ ¬ (∀ x • ¬ P )
hh (rhs)
¬ (∃ x • ¬ P ) ≡ (∀ x • P ) I Proof:
¬ (∃ x • P ) ≡ (∀ x • ¬ P )
(∃ x • ¬ P ) ≡ ¬ (∀ x • P ) P ∧ (∃ x • Q)
= “ hhgen-deMorganii ”
P ∧ ¬ (∀ x • ¬ Q)
I the first law above is an axiom, the rest are theorems
= “ hh¬ -involii ”
I Proving the three theorems above involves the axiom, and ¬ ¬ P ∧ ¬ (∀ x • ¬ Q)
the law of involution: = “ hhdeMorganii ”
¬ (¬ P ∨ (∀ x • ¬ Q))
hh ¬ -involii ¬ ¬ p ≡ p
= “ hh∨-∀-distr ii, noting that if x 6 P , then x 6 ¬ P ”
(voluntary exercises !) ¬ (∀ x • ¬ P ∨ ¬ Q)
Proof of theorem hh∧-∃-distr ii(cont.,) The “one-point” laws
I continued, repeat last line above: I The “one-point” laws are very important.
¬ (∀ x • ¬ P ∨ ¬ Q) hh∀-1pt ii (∀ x • x = E ⇒ P ) ≡ P [E /x ], x 6 E
= “ hhdeMorganii ” hh∃-1pt ii (∃ x • x = E ∧ P ) ≡ P [E /x ], x 6 E
¬ (∀ x • ¬ (P ∧ Q))
= “ hhgen-deMorganii ”
∃x • P ∧ Q I These allow us to get rid of quantifiers.
I The key intuition behind them is that having the condition
x = E in the quantifier allows us to focus on that specific
I Proof complete — from here on we shall adopt this pattern value of x , rather than considering them all.
of stating: I Remember “Logic Example V” in Class 2 ?
I Goal — what is to be proved I Law hh∃-1pt ii will play a key role in the UTP theories we will
I Strategy — our top-level approach
explore later on.
I Proof (Sections) — the gory details

One-point examples Simultaneous one-point
I I We can do multiple “points” at once — goal:
∀ n • n = 5 ⇒ prime(n)
= “ hh∀-1pt ii ” (∃ x , y • x = E ∧ y = F ∧ P ) ≡ P [E , F /x , y ], x , y 6 E , F
prime(n)[5/n]
= “ substitution ”
prime(5) I Proof (strategy, reduce lhs to rhs):
= “ prime number theory ”
true ∃ x, y • x = E ∧ y = F ∧ P
= “ hh∃-1pt iiwith x , given that x 6 E ”
I ∃ y • (y = F ∧ P )[E /x ]
= “ substitution, given that x 6 F ”
∃ m • ∃ n • prime(m) ∧ n = m + 2 ∧ prime(n) ∃ y • y = F ∧ (P [E /x ])
= “ hh∃-1pt ii ” = “ hh∃-1pt ii, given that y 6 F ”
∃ m • (prime(m) ∧ prime(n))[m + 2/n] (P [E /x ])[F /y ]
= “ substitution ” = “ can substitute simultaneously, given that y 6 E ”
∃ m • prime(m) ∧ prime(m + 2) P [E , F /x , y ]
Proof using 1-pt (many, many times …) Proof using 1-pt, cont.
I Proof:
I Goal: ∃ t1 , t2 , x1 , x2 , y1 , y2 •
(∃ t1 , t2 , x1 , x2 , y1 , y2 • t1 = x ∧ x1 = x ∧ y1 = y ∧
t1 = x ∧ x 1 = x ∧ y 1 = y ∧ t2 = t1 ∧ x2 = y1 ∧ y2 = y1 ∧
t2 = t1 ∧ x2 = y1 ∧ y2 = y1 ∧ x 0 = x2 ∧ y 0 = t2
x 0 = x 2 ∧ y 0 = t2 ) = “ hh∃-1ptii, t1 , x1 , y1 6 x , y , t2 , x2 , y2 , substitute ”
≡ x0 = y ∧ y0 = x ∃ t2 , x2 , y2 •
t2 = x ∧ x2 = y ∧ y2 = y ∧
I Where did this strange example come from ?
x 0 = x2 ∧ y 0 = t2
I Remember { int t; t=x; x=y; y=t } ?
= “ hh∃-1pt ii, t2 , x2 , y2 6 x , y , substitute ”
I Strategy: reduce lhs to rhs x = y ∧ y0 = x
0

Mini-Exercise 2
Q2.1 For the following predicate, state for every variable

occurrence if it is free, binding or bound:
(∀ a • (∀ b • (∃ c • a ∧ c ∨ b) ∧ (c ∨ ¬ a)) ∨ b)
Q2.2 Perform the following (simultaneous, double)

substitution:
(∃ t , t 0 • t 0 − t = tr 0 − tr )[t a tr , t 0 a tr 0 / tr , tr 0 ]
Here tr and tr 0 are different variables.
Q2.3 The proof on the slide with title “A Theorem ! Proof

?” has no justifications—fill them in.
Use the Proof-Section format described in class. (due in next
Fri, 2pm, in class)

Class 7 A Simple Imperative Language
I We now turn our attention to a simple (terse) imperative

language, with assignment, sequencing, conditionals and a
while-loop:
p, q ∈ Prog ::= skip do nothing

| v := e assignment
| p; q do p, then do q
| pc q do p if c, else do q
| c ~p while c do p
I skip does nothing, but is useful to have around.

I Assignment uses := (“becomes”) rather than =.
I ; is an operator that joins programs together.
I For now, we ignore variable declarations.
Program Examples The Meaning of an Imperative Program

I The meaning of an expression (or predicate), is a function
I Swapping the values of x and y , using t as temporary:
from an environment to a value of the appropriate type:
t := x ; x := y ; y := t
[[E ]] : Env →
7 Value
[[P ]] : Env → B
I Setting a and b to the maximum and minimum of a and b
respectively: I For a program, the environment maps program variables to
values, and is often called the program state.
skip a > b ( t := a ; a := b ; b := t ) I The meaning of an (deterministic (?), imperative) program,
is a function from an initial environment/state to a final
environment/state
I Setting f to factorial of n, using x as temporary
[[p]] : Env →
7 Env
f := 1 ; x := n ; (x > 1) ~ ( f := f ∗ x ; x := x − 1 )
I Often we refer to a program as a state-transformer .

Denotational Semantics Program Meaning Example I
Defining the meaning of a program as a function from program
text to some mathematical structure, in a compositional way, is
known as a denotational semantics, i.e., a function that returns I Swapping the values of x and y , using t as temporary:
what a program denotes.
t := x ; x := y ; y := t
[[−]] : Prog → Env → 7 Env
[[skip]]ρ =b ρ
[[v := e]]ρ = b ρ ⊕ {v 7→ [[e]]ρ } I The after-value of x is the before-value of y , and vice-versa
[[p; q]]ρ = b [[q]]
[[p]]ρ I Using our environment notation:
[[p]]ρ , if [[c]]ρ
[[p c q]]ρ =
[[q]]ρ , if ¬ [[c]]ρ [[t := x ; x := y ; y := t ]]ρ
b
[[c ~ p]] = b µ W • λ ρ • if [[c]]ρ then (W ◦ [[p]])ρ else ρ = ρ ⊕ {t 7→ ρ(x ), x 7→ ρ(y ), y 7→ ρ(x )}
The last definition is a mystery left for later.

In every case the meaning of a composite is given in terms of
the meanings of its components (compositionality).
Program Meaning Example II Program Meaning Example III

I Setting f to factorial of n, using x as temporary
I Setting a and b to the maximum and minimum of a and b
f := 1 ; x := n ; (x > 1) ~ ( f := f ∗ x ; x := x − 1 )
respectively:
skip a > b ( t := a ; a := b ; b := t )
I If before-value of n is negative, then the after values of f
and x are 1 and n respectively, otherwise:
I The after-value of f is the factorial of the before-value of n
I The after-value of a is the maximum of the before-values of I The after-value of n is the same as before
both a and b, whilst the after value of b is the minimum. I The after-value of x is 1, except if the before-value of n was
I Using environments 0, in which case so is x ’s after-value.
I With environments
[[skip a > b ( t := a ; a := b ; b := t )]]ρ
= ρ ⊕ {t 7→ ρ(a), a 7→ ρ(b), b 7→ ρ(a)}, a<b [[f := 1 ; x := n ; (x > 1) ~ ( f := f ∗ x ; x := x − 1 )]]ρ
= ρ, a>b = ρ ⊕ {f 7→ 1, x 7→ ρ(n)}, ρ(n) ∈ {0, 1}
= ρ ⊕ {f 7→ ρ(n)!, x 7→ 1}, ρ(n) > 1
= ρ ⊕ {f 7→ 1, x 7→ ρ(n)}, ρ(n) < 0
Too much ρ ! Programs are Predicates
I Eric Hehner pushed this idea, inspiring Tony Hoare to write

I The use of explicit environments is precise, but verbose “Programs are predicates”, Mathematical logic and
I we have to distinguish between variable x and its value ρ(x ) programming languages, Royal Society of London,
I we have a language syntax x := e that is different to that pp141–155, 1984.
used to express its meaning: ρ ⊕ {x 7→ [[e]]ρ }. I Many approaches to programming language semantics
I To reduce clutter, we adopt some key ideas keep the programming language and the semantics
I Programs are predicates language separate
I We denote the before-value of program variable x by
predicate variable x . Meaning[[program]] = mathematical stuff
I We denote the after-value of program variable x by
predicate variable x 0 . What’s inside the brackets ([[]]) is syntax, outside is
I Programs are now predicates that relate before and after
semantics
values.
I This distinction is considered by many today as artificial
and unnecessary.
Extending our Predicate Language skip is a predicate
I We are going to extend our predicate language to include

our program language:
P , Q ∈ Pred ::= ... I Program skip leaves that state unchanged

| skip
| v := E b x0 = x ∧ y0 = y ∧ z0 = z
skip =
| P; Q
(here assuming that our only variables are x , y and z !
| P c Q
| c ~P I We have a little problem here — we need to know which
variables are in scope.
I c denotes a condition (boolean expression)
I In effect, we shall define our programming constructs as
shorthand for equivalent predicates

Alphabets Alphabet example
I consider the assignment

We associate the set of variables in scope with every predicate
x := e
P:
I this set is called the alphabet of the predicate (αP ). in a program where x , y and z are in scope.
I if variable x is in scope, the alphabet contains x and x0 I e can only mention these three variables
I all variables mentioned in P must be in αP . I We have
I we denote all the un-dashed alphabet variables by inαP
α(x := e) = {x , x 0 , y , y 0 , z , z 0 }
I we denote all the dashed alphabet variables by out αP inα(x := e) = {x , y , z }
out α(x := e) = {x 0 , y 0 , z 0 }
Alphabet labelling The “rest”
I Frequently we single out a few variables (zero or more) and

just want to refer to “the rest”.
We can label language constructs with their alphabet (A, say)
I We shall use meta-variable S to refer to the set of all
I skipA and x :=A e
program (script) variable before values, and S 0 for
I We can infer alphabets for other language constructs after-values.
I We often omit alphabets where obvious from context I S 0 = S means x10 = x1 ∧ . . . ∧ xn0 = xn where x1 …xn are
I We are talking about using “alphabetised predicates” to the variables in S.
give meanings to programs I If we want to talk about all script variables except x and y
(say) we write S\x ,y
I For now, S and S 0 correspond to inα and out α, respectively.

skip as an alphabetised predicate x := e as an alphabetised predicate
I Given A = {S, S 0 }:
I Given A = {S, S 0 }:
skip-def ii
hh skipA =
b S0 = S :=-def ii
hh x :=A e =
b x 0 = e ∧ S 0\x 0 = S\x
I All the variables are unchanged

I the after-value of x takes on the value of e, evaluated in
the before-state.
I Example, if A is {i , j , k , i 0 , j 0 , k 0 }, then
I Example, if A is {i , j , k }, then
0 0 0
skipA = (i = i ∧ j = j ∧ k = k )
j :=A i + k = ( i0 = i ∧ j0 = i + k ∧ k0 = k )
; as a binary predicate operator Sequential Composition Example

I P ; Q is the sequential composition of P with Q.
I Consider program t := x ; x := y , with t , x and y in scope.
How is this expressed using our predicate notation?
I We phrase its behaviour as follows:
I We calculate:
“P ; Q maps before-state S to after-state S 0 , when there t := x ; x := y
exists a mid-state Sm , such that P maps S to Sm , and Q = “ hh:=-def ii ”
maps Sm to S 0 .” t = x ∧ x 0 = x ∧ y 0 = y ; x := y
0
I We get the following definition: = “ hh:=-def ii ”

t = x ∧ x0 = x ∧ y0 = y; t0 = t ∧ x0 = y ∧ y0 = y
0
hh; -def ii P; Q =
b (∃ Sm • P [Sm /S 0 ] ∧ Q[Sm /S]) = “ hh; -def ii, noting S is t , x , y ”
∃ tm , xm , ym •
(t 0 = x ∧ x 0 = x ∧ y 0 = y )[tm , xm , ym /t 0 , x 0 , y 0 ]
I The alphabets involved must satisfy the following
∧ (t 0 = t ∧ x 0 = y ∧ y 0 = y )[tm , xm , ym /t , x , y ]
conditions:
= “ substitution, twice ”
out αP = (inαQ)0 , {x , . . . , z }0 = {x 0 , . . . , z 0 } ∃ tm , xm , ym • tm = x ∧ xm = x ∧ ym = y
inα(P ; Q) = inαP ∧ t 0 = tm ∧ x 0 = y m ∧ y 0 = y m
out α(P ; Q) = out αQ
Sequential Composition Example, cont. as a ternary predicate operator
I P c Q, behaves like P ,if c is true, otherwise it

I We continue: behaves like Q.
∃ tm , xm , ym • tm = x ∧ xm = x ∧ ym = y I Definition:
∧ t 0 = tm ∧ x 0 = ym ∧ y 0 = ym
= “ hh∃-1pt ii, tm , xm , ym 6 x , y ”
hh -def ii P c Q =
b c ∧P ∨¬c ∧Q
t = x ∧ x0 = y ∧ y0 = y
0
I Alphabet constraints
I We see that the net effect is like the simultaneous
assignment t , x := x , y , inα(P c Q) = αc = inαP = inαQ
t now has the value of x , and x has the value of y . out α(P c Q) = out αP = out αQ
Example ~ as a binary predicate operator
I Program: skip a > b ( t := a ; a := b ; b := t ), with I Program c ~ P checks c, and if true, executes P , and
alphabet A = {a, a 0 , b, b 0 , t , t 0 } then repeats the whole process
I Meaning: I We won’t define it yet, instead we give a law that describes
how a while-loop can be “unrolled” once:
skipA a > b t :=A a ; a :=A b ; b :=A t
= “ hh-def ii ” ~-unrollii
hh c ~P = (P ; c ~ P ) c skip
a > b ∧ skipA
∨ If c is False, we skip, otherwise we do P followed by the
¬ (a > b) ∧ ( t :=A a ; a :=A b ; b :=A t ) whole loop (c ~ P ) once more.
= “ hhskip-def ii, hh:=-def ii, hh; -def ii, and hh∃-1pt ii ” I Alphabet constraints
a > b ∧ a0 = a ∧ b 0 = b ∧ t 0 = t
∨ inα(c ~ P ) = αc = inαP
a < b ∧ a0 = b ∧ b 0 = a ∧ t 0 = a out α(c ~ P ) = out αP = (inαP )0

Loop example
f := 1 ; x := n ; (x > 1) ~ (f := f ∗ x ; x := x − 1)
= “ hh:=-def ii ”
n = n ∧ f 0 = 1 ∧ x0 = x
0
;
x := n; (x > 1) ~ (f := f ∗ x ; x := x − 1)
There must be a better way !!

Class 8 all the other variables …
I Consider computing the semantics of
x := x + y ; y := x − y ; x := x − y
in a scope with variables s, t , u, v , w , x , y , z

I The program only mentions x and y , but we have to carry
equalities around for s, t , u, w and z .
I We can tidy-up using the 1-pt law, but this is tedious and
error prone.
I Can we show that the above program swaps the values of
x and y , without mentioning the other variables?
I What we need are laws that work at the programming
language level
(a.k.a. “Laws of Programming”)
Laws of Imperative Programming (Some) Laws of Programming

I Here P , Q and R stand for arbitrary programs, A for an
arbitrary alphabet, x , y and z for arbitrary variables, and
I When we give a law stating that programs p1 and p2 are c,e and f for arbitrary expressions
the same:
p1 = p2
hhskip-altii skipA = x :=A x , x ∈A
we are stating that both programs have the same hhskip-; -unit ii skip ; P = P
behaviour, i.e. that they change the state in the same way. hh; -skip-unit ii P ; skip = P
I Given that our programs are predicates, we can simply use hh; -associi P ; (Q ; R) = (P ; Q) ; R
predicate calculus to prove such laws as theorems in the hh:=-seq ii x := e ; x := f = x := f [e/x ]
usual way. hh:=-swapii x := e ; y := f = y := f [e/x ] ; x := e,
I The laws typically show how various combinations of y 6 e
language constructs are related. hh -trueii P True Q = P
hh-falseii P False Q = Q
hh-seq ii (P c Q) ; R = (P ; R) c (Q ; R)

Proof of hhskip-altii Proof of hhskip-; -unitii
I Goal: skipA = x :=A x

I Goal: skip ; P = P
I Strategy: reduce rhs to lhs
I Strategy: reduce lhs to rhs
I Proof:
I Proof:
skip ; P
x :=A x = “ hhskip-def ii ”
0
S =S; P
= “ hh:=-def ii, A = {S, S 0 } ”
x 0 = x ∧ S 0\x 0 = S\x = “ hh; -def ii ”
= “ merge ” ∃ Sm • Sm = S ∧ P [Sm /S]
S0 = S = “ hh∃-1pt ii ”
= “ hhskip-def ii, A = {S, S 0 } ” (P [Sm /S])[S/Sm ]
skipA = “ substitution ‘inverse’ ”
P

Laws of Substitution Defining Single Substitution
k [e/x ] = k
I We have used some “laws of substitution” in our proofs.
b
v [e/x ] =
b v , v 6= x
I These too have a rigorous basis. x [e/x ] =
b e
I First, we promote substitution to be part of our predicate (e1 + e2 )[e/x ] =
b e1 [e/x ] + e2 [e/x ]
language: (¬ P )[e/x ] =
b ¬ P [e/x ]
(P ∧ Q)[e/x ] =
b P [e/x ] ∧ Q[e/x ]
Pred ::= . . . | P [e1 , . . . , en /v1 , . . . , vn ] (∀ x • P )[e/x ] =
b ∀x • P
(∀ v • P )[e/x ] = ∀ v • P [e/x ], v 6= x , v 6 e
We assume that substitution has highest precedence
b
(∀ v • P )[e/x ] = ∀ w • (P [w /v ])[e/x ],
(binds tighter) than all other constructs
b
v 6= x , v e, w 6 P , e, x
I Next we define its effect on predicates.
The constructs not mentioned above follow the same pattern.
We shall now look at the last four lines in more detail.

Substitution and Quantifiers (I) Substitution and Quantifiers (II)
(∀ v • P )[e/x ] =
b ∀ v • P [e/x ], v 6= x , v 6 e
(∀ x • P )[e/x ] =
b ∀x • P
The simplest case: x is simply not free in ∀ x • P , I We are not substituting for v , and v does occur in e, so
so nothing changes. there is no possibility of name capture.
I We simply recurse to the body predicate P .
Substitution and Quantifiers (III) Laws of single substitution
I We can identify a number of useful laws

(∀ v • P )[e/x ] =
b ∀ w • (P [w /v ])[e/x ],
v 6= x , v e, w 6 P , e, x hhsubst-invii P [x /y ][y /x ] = P , x 6 P
hhsubst-compii P [e/x ][f /x ] = P [e[f /x ]/x ]
hhsubst-swapii P [e/x ][f /y ] = P [f /y ][e/x ],
I The tricky case, where v occurs in e.
x 6 f , y 6 e
I To avoid name capture of v in e:
I Pick a fresh variable w — i.e. one not currently in use.
I α-rename the bound and binding occurrences of v to w I We shall not prove these laws at this point
I Then recurse into the now α-renamed body P . I to do so requires induction,
I over the grammar (?!) of our predicate language

Substitution Law examples Simultaneous Substitution
I Simultaneous substitution does several replacements at

once:
I subst-invii: P [x /y ][y /x ] = P ,
hh x 6 P (x + y )[y 2 , k + x /x , y ] = y 2 + k + x
I (x + y )[z /x ][x /z ] = (z + y )[x /z ] = x + y
I The side-condition matters:
(x + y )[y /x ][x /y ] = (y + y )[x /y ] = x + x I In general, it is not the same as doing each replacement
(x + y )[x /y ][y /x ] = (x + x )[y /x ] = y + y one at a time:
I subst-compii: P [e/x ][f /x ] = P [e[f /x ]/x ]
hh
I x [x + y /x ][z /x ] = (x + y )[z /x ] = z + y (x +y )[y 2 /x ][k +x /y ] = (y 2 +y )[k +x /y ] = (k +x )2 +k +x

I x [(x + y )[z /x ]/x ] = x [z + y /x ] = z + y
I When the first substitution does not introduce the “target ”

of the second, then we can do them one at a time.
Laws of Simultaneous Substitution Proof of hh; -associi
I Order of substitutions does not matter:

hhsubst-comm ii P [e, f /x , y ] = P [f , e/y , x ]
I We can merge in later substitutions if they don’t act on I Goal: P ; (Q ; R) = (P ; Q) ; R
earlier replacements:
hhsubst-seq ii P [e/x ][f /y ] = P [e, f /x , y ], y 6 e
I Strategy: reduce both lhs and rhs to same predicate
I The above law generalises to many substitutions:
I Proof: hold on tight!
P [e1 , . . . , en /x1 , . . . , xn ][f /y ] = P [e1 , . . . , en , f /x1 , . . . , xn , y ]
(provided y 6 e1 , . . . , en )

Proof hh; -associi (lhs) Proof hh; -associi (rhs)
P ; (Q ; R) (P ; Q) ; R
= “ hh; -def ii, {S, S 0 } = out αQ ∪ inαR ” = “ hh; -def ii, {S, S 0 } = out αP ∪ inαQ ”
P ; (∃ Sm • Q[Sm /S 0 ] ∧ R[Sm /S]) (∃ Sn • P [Sn /S 0 ] ∧ Q[Sn /S]) ; R
= “ hh; -def ii, {S, S 0 } = out αP ∪ inαQ ” = “ hh; -def ii, {S, S 0 } = out αQ ∪ inαR ”
∃ Sn • P [Sn /S 0 ] ∧ (∃ Sm • Q[Sm /S 0 ] ∧ R[Sm /S])[Sn /S] ∃ Sm • (∃ Sn • P [Sn /S 0 ] ∧ Q[Sn /S])[Sm /S 0 ] ∧ R[Sm /S]
= “ defn. of substitution, S = 6 Sm ” = “ defn. of substitution, S 0 6= Sn ”
∃ Sn • P [Sn /S 0 ] ∧ ∃ Sm • Q[Sm /S 0 ][Sn /S] ∧ R[Sm /S][Sn /S] ∃ Sm • (∃ Sn • P [Sn /S 0 ][Sm /S 0 ] ∧ Q[Sn /S][Sm /S 0 ]) ∧ R[Sm /S]
= “ hh∧-∃-distr ii, Sm 6 P [Sn /S 0 ] ” = “ hh∧-∃-distr ii, Sn 6 R[Sm /S] ”
∃ Sn , Sm • P [Sn /S 0 ] ∧ Q[Sm /S 0 ][Sn /S] ∧ R[Sm /S][Sn /S] ∃ Sm , Sn • P [Sn /S 0 ][Sm /S 0 ] ∧ Q[Sn /S][Sm /S 0 ] ∧ R[Sm /S]
= “ hhsubst-seqii, S 6 Sm ” = “ hhsubst-seqii, S 0 6 Sn ”
∃ Sn , Sm • P [Sn /S 0 ] ∧ Q[Sm , Sn /S 0 , S] ∧ R[Sm /S][Sn /S] ∃ Sm , Sn • P [Sn /S 0 ][Sm /S 0 ] ∧ Q[Sn , Sm /S, S 0 ] ∧ R[Sm /S]
= “ hhsubst-compii, Sm [Sn /S] = Sm ” = “ hhsubst-compii, Sn [Sm /S 0 ] = Sn ”
∃ Sn , Sm • P [Sn /S 0 ] ∧ Q[Sm , Sn /S 0 , S] ∧ R[Sm /S] ∃ Sm , Sn • P [Sn /S 0 ] ∧ Q[Sn , Sm /S, S 0 ] ∧ R[Sm /S]
“ lhs=rhs, with minor re-orderings ”
Proof using Laws (example) Subtleties with Substitution (I)

I Goal:
Consider the following proof of hh:=-seqii reducing LHS to RHS:
( f := 1 ; x := n ; f := f · x ; x := x − 1 )
= x := e ; x := f
( f := n ; x := n − 1 ) = “ hh:=-def ii, A = {S, S 0 } ”
x = e ∧ S 0\x 0 = S\x ; x 0 = f ∧ S 0\x 0 = S\x
0
= “ hh; -def ii, A = {S, S 0 } ”

I Strategy: reduce lhs to rhs
∃ Sm • (x 0 = e ∧ S 0\x 0 = S\x )[Sm /S 0 ]
I Proof: ∧ (x 0 = f ∧ S 0\x 0 = S\x )[Sm /x , S]
f := 1 ; x := n ; f := f · x ; x := x − 1 = “ substitution, noting that e has no dashed vars ”
= “ hh:=-swapii, f 6 n ” ∃ Sm • xm = e ∧ Sm\xm = S\x
f := 1 ; f := f · n ; x := n ; x := x − 1 ∧ x 0 = f [Sm /S] ∧ S 0\x 0 = Sm\xm
= “ hh:=-seqii ” = “ hh∃-1pt ii, Sm 6 e, S ”
f := 1 · n ; x := n − 1 x = f [e, S \x /x , S\x ] ∧ S 0\x 0 = S\x
0
= “ arithmetic ” = “ ignore [S \x /S\x ], hh:=-def ii ”

f := n ; x := n − 1 x := f [e/x ]

Subtleties with Substitution (II) The Problem
I We might have been tempted to apply hh; -def ii first, “do” the
substitution, and then use hh:=-def ii:
I Sequential composition is designed to work with predicates
x := e ; x := f
using x , S for before-variables, and x 0 and S 0 for after
= “ hh; -def ii ”
variables.
∃ Sm • (x := e)[Sm /S 0 ]
∧ (x := f )[Sm /S] I In x := e, the variable x stands for the program variable,
= “ doing substitution into assignment ” and not its initial value
∃ Sm • x := e I We cannot do substitutions safely until we have expanded
∧ xm := f [Sm /S] its definition.
= “ h:=-def ii, twice ”
h I In fact, we cannot determine what its free variables are
∃ Sm • x 0 = e ∧ S 0\x 0 = S\x until it has been expanded.
∧ xm0 = f [Sm /S] ∧ S 0\x 0 = S\x
I What is xm0 ? We seem to have a problem !

Non-substitutable Predicates
I Some of our new predicate (programming) constructs are

non-substitutable (n.s.).
I Substitution can only be applied to these once their
definitions have been expanded.
I We have assignment as one example, but there are others:
skip P; Q c ∗P
I Of the new constructs so far, only conditional is

substitutable:
(P c Q)[e/x ] = P [e/x ] c[e/x ] Q[e/x ]

Class 9 Swapping “trick” revisited
I Re-consider computing the semantics of
x := x + y ; y := x − y ; x := x − y
in a scope with variables s, t , u, v , w , x , y , z

I We’d like to use the laws of programming, so we can ignore
s, t , u, v , w and z .
I We can’t use hh:=-swapii, because the side-condition does
not hold.
I We can’t use hh:=-seqii, because we don’t have two
assignments to the same variable one after the other.
I In fact it’s not clear what laws would work: after the first two
assignments we have
x 0 = x + y ∧ y 0 = x ∧ S 0\x 0 ,y 0 = S\x ,y whilst at the end we
get x 0 = y ∧ y 0 = x ∧ S 0\x 0 ,y 0 = S\x ,y .
Simultaneous Assignment Laws of Simultaneous Assignment (I)

I A single assignment to y can always be merged with a
I We introduce a further extension to predicate syntax,
preceding simultaneous assignment to ~x , provided y ∈
/ ~x :
simultaneous assignment:
sim-:=-mergeii
hh ~x := ~e ; y := f = ~x , y := (~e , f [~e /~x ])
Pred ::= . . .
| x1 , . . . , xn := e1 , . . . , en
I Proof, reducing lhs to rhs:
I We introduce shorthands: ~x and ~e for x1 , . . . , xn and ~x := ~e ; y := f

e1 , . . . , en resp. = “ hhsim-:=-def ii, hh:=-def ii ”
~
x = ~e ∧ S 0\x~0 = S\~x ; y 0 = f ∧ S 0\y 0 = S\y
0
I Its meaning is that the expressions e1 through en are
evaluated, and then all the xi are updated simultaneously: = “ hh; -def ii, and substitute ”
∃ Sm • x~m = ~e ∧ Sm\x~m = S\~x
hhsim-:=-def ii ∧ y 0 = f [Sm /S] ∧ S 0\y 0 = Sm\ym
~x :=A ~e = b x10 = e1 ∧ . . . ∧ xn0 = en ∧ S 0\x10 ...xn0 = S\x1 ...xn , = “ hh∃-1pt ii, noting ym = y ”
~
x = ~e ∧ y 0 = f [~e , S \~e /~x , S\~x ] ∧ S 0\x~0 ,y 0 = S\~x ,y
0
A = {S, S 0 }, x1 , . . . , xn ∈ S = “ hhsim-:=-def ii, ignoring [y , S \~x ,y /y , S\~x ,y ] ”

~x , y := ~e , f [~e /~x ]
Laws of Simultaneous Assignment (II) Swapping Trick Proof
I If y ∈ ~x , the sequencing law has to be slightly different I Goal:
sim-:=-seqii
hh ~x , y := ~e , f ; y := g = ~x , y := ~e , g[~e , f /~x , y ] x := x + y ; y := x − y ; x := x − y = x , y := y , x
I Proof, reducing lhs to rhs:
I Proof, reducing lhs to rhs: x := x + y ; y := x − y ; x := x − y

= “ hhsim-:=-mergeii ”
~x , y := ~e , f ; y := g x , y := x + y , (x − y )[x + y /x ] ; x := x − y
= “ hhsim-:=-def ii, hh:=-def ii ” = “ do substitution ”
x~ = ~e ∧ y 0 = f ∧ S 0\x~0 ,y 0 = S\~x ,y ; y 0 = g ∧ S 0\y 0 = S\y
0
x , y := x + y , (x + y ) − y ; x := x − y
= “ hh; -def ii, and substitute ” = “ hhsim-:=-seqii ”
∃ Sm • x~m = ~e ∧ ym = f ∧ Sm\x~m ,ym = S\~x ,y x , y := (x − y )[x + y , (x + y ) − y /x , y ], (x + y ) − y
∧∧ y 0 = g[ym , Sm \ym /y , S\y ] ∧ S 0\y 0 = Sm\ym = “ do substitution ”
= “ hh∃-1pt ii ” x , y := x + y − ((x + y ) − y ), (x + y ) − y
~
x = ~e ∧ y 0 = g[~e , f , S \~x ,y /~x , y , S\~x ,y ] ∧ S 0 = S
0
= “ arithmetic ”
= “ hhsim-:=-def ii, ignoring [S \~x ,y /S\~x ,y ] ” x , y := y , x
~x , y := (~e , g)[~e , f /~x , y ]
Messing with notation Programs as Predicates
I Is simultaneous assignment a programming language I If programs are predicates, then we can join them up using
construct ? predicate notation.
I Depends on the language: I e.g prog1 ∧ prog2
I in languages like C, Java, it is not allowed I e.g prog1 ∨ prog2
I in Handel-C it is allowed, as it targets hardware and so we I e.g prog1 ⇒ prog2
have real parallelism I We can also mix them with non-program predicates
I It does not matter ! I e.g prog ∧ pred
I It is a predicate with a sensible meaning I e.g prog ∨ pred
I It is convenient for certain proofs I e.g prog ⇒ pred
I It can describe outcomes concisely that are not possible I Do these make sense? If so, how?
using only single assignments, e.g. x , y := y , x .
I Are any of these useful?
I Not all predicate language extensions have to be “code”.

Programs and Conjunction Examining (x := 2) ∧ (x := 3)
I
I Consider the following:
(x := 2) ∧ (x := 3)
(x := 2) ∧ (x := 3) = “ hh:=-def ii, twice ”
(x := 2) ∧ (y := 3) x 0 = 2 ∧ S 0\x 0 = S\x ∧ x 0 = 3 ∧ S 0\x 0 = S\x
(x := 2) ∧ x = 2 = “ 2 6= 3 ”
(x := 2) ∧ y = 3 false
I Not unexpectedly, we get false

I What behaviour do these describe? we cannot assign 2 and 3 to x (at the same time)
Examining (x := 2) ∧ (y := 3) Examining (x := 2) ∧ x = 2
I
(x := 2) ∧ (y := 3)
= “ hh:=-def ii, twice ” I
x = 2 ∧ y 0 = y ∧ S 0\x 0 ,y 0 = S\x ,y
0 (x := 2) ∧ x = 2
∧ x 0 = x ∧ y 0 = 3 ∧ S 0\x 0 ,y 0 = S\x ,y = “ hh:=-def ii ”
= “ = is transitive, re-arrange ” x = 2 ∧ S 0\x 0 = S\x ∧ x = 2
0
x = x ∧ y 0 = y ∧ S 0\x 0 ,y 0 = S\x ,y
0
∧ x0 = 2 ∧ y0 = 3 ∧ x = 2 ∧ y = 3 I We get a predicate stating that the assignment occurred, in

= “ hhskip-def ii ” a starting state where x had value 2.
skip ∧ x 0 = 2 ∧ y 0 = 3 ∧ x = 2 ∧ y = 3 I It is the same as Skip ∧ x = 2
I true only if x and y start as 2 and 3 resp., and do not

change.

Examining (x := 2) ∧ y = 3 Programs and Conjunction—Comment
I Conjoining two programs (prog1 ∧ prog2 ) easily leads to

I contradiction
(x := 2) ∧ y = 3
I Predicate
x = 2 ∧ S 0\x 0 = S\x ∧ y = 3
0 prog ∧ ~x = ~e
describes a run of prog that started in a state where
I We get a predicate stating that the assignment occurred, in variables ~x had values ~e .
a starting state where y had value 3. I Remember, x := e means x is changed, and that all other
variables are left unchanged .
Programs and Disjunction Examining (x := 2) ∨ (x := 3)
I
(x := 2) ∨ (x := 3)
= “ hh:=-def ii, twice ”
I Consider the following: x = 2 ∧ S 0\x 0 = S\x
0
∨ x 0 = 3 ∧ S 0\x 0 = S\x
(x := 2) ∨ (x := 3)
= “ hh∧-∨-distr ii ”
(x := 2) ∨ (y := 3)
(x = 2 ∨ x 0 = 3) ∧ S 0\x 0 = S\x
0
(x := 2) ∨ x = 2
I Variable x ends up having either value 2 or 3, and all other
variables are unchanged.
I The choice between 2 or 3 is arbitrary — nothing here
states how that choice is made.

Examining (x := 2) ∨ (y := 3) Examining (x := 2) ∨ x = 2
I
I
(x := 2) ∨ (y := 3) (x := 2) ∨ x = 2)
= “ hh:=-def ii, twice ” = “ hh:=-def ii, twice ”
x = 2 ∧ y 0 = y ∧ S 0\x 0 ,y 0 = S\x ,y
0
x = 2 ∧ S 0\x 0 = S\x ∨ x = 2
0
∨ x 0 = x ∧ y 0 = 3 ∧ S 0\x 0 ,y 0 = S\x ,y
= “ hh∧-∨-distr ii ” I Either x becomes 2, or we started with x equal to 2 and
(x = 2 ∧ y 0 = y ∨ x 0 = x ∧ y 0 = 3) ∧ S 0\x 0 ,y 0 = S\x ,y
0
then anything could have happened !
I if x is not equal to 2 to start, then it equals 2 at the end and
no other variable changes
I Either x ends up having value 2, or y ends up equal to 3, I if x equals 2 at the beginning, then the final values of all
and all other variables are unchanged. variables are arbitrary.
I The choice between changing x or y is arbitrary — nothing
here states how that choice is made.
Programs and Disjunction—Comment Programs and Negation

I How do we “not” assign something?
¬ (x := e)
I Disjoining two programs (prog1 ∨ prog2 ) denotes an
arbitrary choice between the two behaviours.
I Predicate I Let’s calculate:
prog ∨ ~x = ~e ¬ (x := e)
tells us that we get: = “ hh:=-def ii ”
I the behaviour of prog, ¬ (x 0 = e ∧ S 0\x 0 = S\x )
if initial values of ~x are not all equal to ~e ; = “ hhdeMorganii ”
I arbitrary behaviour, if they are all equal. x 6= e ∨ S 0\x 0 6= S\x
0
I So, ¬ (x := e) is any situation where

I either x does not end up with value e
I or some other variable gets changed
Programs and Implication Examining (x := 2) ⇒ (x := 3)
I
(x := 2) ⇒ (x := 3)
= “ hh:=-def ii, twice ”
I Consider the following: x 0 = 2 ∧ S 0\x 0 = S\x ⇒ x 0 = 3 ∧ S 0\x 0 = S\x
= “ hh⇒-def ii ”
(x := 2) ⇒ (x := 3) ¬ (x 0 = 2 ∧ S 0\x 0 = S\x ) ∨ x 0 = 3 ∧ S 0\x 0 = S\x
(x := 2) ⇒ (y := 3) = “ hhdeMorganii ”
(x := 2) ⇒ x 0 = 2 x 6= 2 ∨ S 0 6= S ∨ x 0 = 3 ∧ S 0\x 0 = S\x
0
(x := 2) ⇒ x 0 ∈ {1, . . . , 10} = “ hh∨-∧-absorbii, with p matched to S 0 6= S ”
x 6= 2 ∨ S 0 6= S ∨ x 0 = 3
0
= “ hh⇒-joinii, given that x 0 = 3 ⇒ x 0 6= 2 ”

x 0 6= 2 ∨ S 0 6= S
I This can only be true if the assignment x := 2 does not

happen.
Examining (x := 2) ⇒ (y := 3) Examining (x := 2) ⇒ x 0 = 2
I
I
(x := 2) ⇒ (y := 3) (x := 2) ⇒ x 0 = 2)
= “ hh:=-def ii, twice ” = “ hh:=-def ii ”
x = 2 ∧ y 0 = y ∧ S 0\x 0 ,y 0 = S\x ,y
0 x = 2 ∧ S 0\x 0 = S\x ⇒ x 0 = 2
0
⇒ x 0 = x ∧ y 0 = 3 ∧ S 0\x 0 ,y 0 = S\x ,y = “ hh⇒-def ii ”

= “ hh⇒-def ii ” ¬ (x 0 = 2 ∧ S 0\x 0 = S\x ) ∨ x 0 = 2
¬ (x 0 = 2 ∧ y 0 = y ∧ S 0\x 0 ,y 0 = S\x ,y ) = “ hhdeMorganii ”
∨ x 0 = x ∧ y 0 = 3 ∧ S 0\x 0 ,y 0 = S\x ,y x 6= 2 ∨ S 0\x 0 6= S\x ∨ x 0 = 2
0
= “ hhdeMorganii ” = “ hhexcluded-middleii ”
x 6= 2 ∨ y 0 6= y ∨ S 0 6= S
0 true ∨ S 0\x 0 6= S\x
∨ x 0 = x ∧ y 0 = 3 ∧ S 0\x 0 ,y 0 = S\x ,y = “ hh∨-zeroii ”
= “ hh∨-∧-absorbii, with p matched to S 0\x 0 ,y 0 6= S\x ,y ” true
x 6= 2 ∨ y 0 6= y ∨ S 0\x 0 ,y 0 6= S\x ,y ∨ x 0 = x ∧ y 0 = 3
0
I This is always true: if we assign 2 to x , then the final value
of x is 2.
I Complicated !
Examining (x := 2) ⇒ x 0 ∈ {1, . . . , 10} Programs and Implication—Comment
I
(x := 2) ⇒ x 0 ∈ {1, . . . , 10})
= “ hh:=-def ii ” I Predicate prog1 ⇒ prog2 is true if
x = 2 ∧ S 0\x 0 = S\x ⇒ x 0 ∈ {1, . . . , 10}
0 I the before-after relationship described by prog1 does not
= “ hh⇒-def ii, hhdeMorganii ” hold, or …
x 0 6= 2 ∨ S 0\x 0 6= S\x ∨ x 0 ∈ {1, . . . , 10} I prog1 holds, and the behaviour described by prog2
somehow includes the behaviour of prog1
= “ i ∈ {1, . . . , k , . . . , n} ≡ i = k ∨ i ∈ {1, . . . , k , . . . , n} ”
x 0 6= 2 ∨ S 0\x 0 6= S\x ∨ x 0 = 2 ∨ x 0 ∈ {1, . . . , 10}
I Predicate prog ⇒ pred is true if
= “ hhexcluded-middleii ”
I the before-after relationship described by prog does not
hold, or …
true ∨ S 0\x 0 6= S\x ∨ x 0 ∈ {1, . . . , 10} I prog holds, and the situation described by pred is covered
= “ hh∨-zeroii ” by the behaviour of prog
true
I This is always true: if we assign 2 to x , then the final value

of x is between 1 and 10.
Mini-Exercise 3
Q3.1 Prove
(∀ x • P ) ≡ ¬ (∃ x • ¬ P )
using only the following axioms:
hh gen-deMorganii (∃ x • P ) ≡ ¬ (∀ x • ¬ P )
hh¬ -involii ¬¬p≡p
Q3.2 Prove
hh ; -skip-unitii P ; skip = P
(due in next Friday, 2pm, in class)

Class 10 Taking Stock
I We are playing a BIG formal game
I We have a well-defined extensible language:
Pred ::= true | . . . | ∀ x • P | . . .
I We have given it a well-defined meaning:
[[∃ x • P ]]ρ =
b ...
I We have provided rules to do proofs:
F =G
E [v := F ] = E [v := G]
CS4003 Formal Methods

I Does it all make sense? CS4003 Formal Methods
Truth and Provability Truth vs. Provability

I Truth and Provability are not the same thing!
I Soundness
I Statements A proof system is sound if whenever we can prove
We are interested in statements of the following form: something, it is also true:
Whenever predicates P1 , . . . , Pn are true, then so is Q.
Γ ` Q means that Γ |= Q
(Let us use Γ as a shorthand for P1 , . . . , Pn ).
I Truth — Γ |= Q
The above statement is true when, for every environment ρ I Completeness
that makes all the Pi true, we have [[Q]]ρ = True. A proof system is complete if whenever something is true,
I Provability — Γ ` Q it can proved to be so:
The above statement is provable when, given the Pi as
Γ |= Q means that Γ ` Q
assumptions, we can prove Q as a theorem.
I The “Holy Grail”of formal systems is a sound and complete

formal system
Soundness Completeness
I Completeness is a “nice-to-have” property

I Soundess is a critical property I In principle a complete proof-system can be made fully
I Unsound proof systems allow “proofs” of false statements automatic.
Very undesirable! I Incompleteness simply means there are some true
I Unsoundness can arise in one of two ways: properties for which there are no proofs in our formal
I Inconsistency system.
I A proof system is inconsistent if anything can be proved I Gödel’s Incompleteness Theorems (1931):
using it
I In particular if we can prove false, we can prove anything. 1. Any proof-system powerful enough for arithmetic cannot be
I Environment Mismatch Even if consistent, a proof system both consistent and complete.
can be unsound if our axioms and inference rules are 2. Any proof-system powerful enough to prove theorems
incorrect, and fail to capture the truth properly. about itself (arithmetic !), is inconsistent iff it can prove its
own consistency
I Ensuring soundness require great care in determining
I Most formal systems we want to use embody arithmetic
axioms and inference rules.
and so are incomplete as just described.
Meta-mathematics Relating x := 2 and x 0 ∈ {1, . . . , 10}
I Meta-mathematics is the study of mathematics itself, as a

“mathematical object” I x 0 ∈ {1, . . . , 2} could be viewed as a specification:
I A major focus of meta-mathematics is the study of “pick a number between 1 and 10, call it x ”.
proof-systems I x := 2 is clearly a program that satisfies that specification
I There is a large body of soundness and completeness I So does x := 5 (say)
results out there for different formal systems. I More surprisingly, so does the program x := 2 ; y := 99 !
I This course is based on a (mainly) sound but incomplete The spec. says nothing about y (or any other variable).
logic system
I Mainly ???
I Interestingly, the “program” x := 2 ∨ x := 5 also satisfies
I Yes, but … the specification.
I We will be extending our language later by adding axioms
of our own …

Specifying “pick a number” Formally introducing frames
I Once again, we extend our predicate language, with

I the problem with x 0 ∈ {1, . . . , 10} is that it allows anything
specification frames (n.s.)
to happen to variables other than x .
I We can strengthen it to require that only x be modified: Pred ::= . . .
| ~x :[P ]
x 0 ∈ {1, . . . , 10} ∧ S 0\x 0 = S\x
I It asserts P , and that any variable not in ~x is unchanged:

I This idiom is so common we invent specific notation for it:
frame-def ii
hh ~x :[P ] =
b P ∧ S 0\x~0 = S\~x , A = {S, S 0 }
x : x 0 ∈ {1, . . . , 10}

The outer x : says, “modifying x only,” I Not be confused with [P ], the universal closure of P ,
I The notation x :[. . .] is called a (specification) “frame”. or x : T , asserting that x has type T ,
or P [e/x ] where e replaces free x in P .
Satisfying Specifications Is Implication Satisfaction ?
I Consider x := 2 ⇒ x :[x 0 ∈ {1, . . . , 10}]

I Formally (assuming only x and y in scope):
I Given specification S =b x :[x 0 ∈ {1, . . . , 10}], how do we
check if an offered program P fully satisfies it?
x := 2 ⇒ x : [x 0 ∈ {1, . . . , 10}]
I P2 =
b x := 2 clearly satisfies it,
= “ hh:=-def ii, hhframe-def ii ”
and we saw previously that P2 ⇒ S.
I Can we conclude then that we want P ⇒ S as our
x = 2 ∧ y 0 = y ⇒ x 0 ∈ {1, . . . , 10} ∧ y 0 = y )
0
acceptance criteria ? = “ equality substitution (? — see later) ”

x = 2 ∧ y 0 = y ⇒ 20 ∈ {1, . . . , 10} ∧ y = y
0
I Problem: predicate P ⇒ S does not give us a yes/no
= “ set theory, reflexivity of equality ”
answer.
x 0 = 2 ∧ y 0 = y ⇒ true ∧ true
I Instead, we get a predicate whose truth depends on the = “ prop. logic ”
values of variables. true
I Seems OK.

Implication is not Satisfaction (I) Implication is not Satisfaction (II)
I Consider x := x + 10 ⇒ x :[x 0 > y 0 ]

I Consider y := 99 ⇒ x :[x 0 ∈ {1, . . . , 10}]
x := x + 10 ⇒ x :[x 0 > y 0 ]
y := 99 ⇒ x : [x 0 ∈ {1, . . . , 10}]
x = x + 10 ∧ y 0 = y ⇒ x 0 > y 0 ∧ y 0 = y
0
x 0 = x ∧ y 0 = 99 ⇒ x 0 ∈ {1, . . . , 10} ∧ y 0 = y
= “ equality substitution (? — see later) ”
= “ equality substitution (? — see later) ”
x 0 = x + 10 ∧ y 0 = y ⇒ x + 10 > y ∧ y = y
x 0 = x ∧ y 0 = 99 ⇒ x ∈ {1, . . . , 10} ∧ 99 = y
= “ logic, arithmetic ”
x 0 = x + 10 ∧ y 0 = y ⇒ x > y − 10
The truth/falsity of this satisfaction question seems to depend
on initial x already satisfying the specification, and initial y I Program x := x + 10 only satisfies specification x :[x 0 > y 0 ]
being 99 already! if x is greater than y − 10 to begin with.

Class 11 Full Satisfaction (a.k.a. “Refinement”)
I Given specification S and program P :
I all before/after-relationships resulting from P must satisfy
those required by S
I so P must imply S for all possible variable before- and
after-values
I So we require universal implication,
saying that P satisfies S iff
[P ⇒ S]
I Once more, we add special predicate notation, saying that

S is “refined by” P , written S v P
Pred ::= . . . | S v P
hh v-def ii SvP = b [P ⇒ S]
Universal Closure re-visited Example: Assignment as Frame refinement
I Reminder: notation [P ] asserts that P is true for all values Consider x :[P ] v x := e, assuming x and y in scope,
of its variables
I [P ] ≡ ∀ x1 , . . . , xn • P , FV P ⊆ {x1 , . . . , xn }
[x := e ⇒ x :[P ]]
I It satisfies the following laws: = “ hh:=-def ii, hhframe-def ii ”
[x = e ∧ y 0 = y ⇒ P ∧ y 0 = y ]
0
hh []-trueii [true] ≡ true
= “ hhshuntingii ”
hh []-falseii [false] ≡ false
[x = e ⇒ (y 0 = y ⇒ P ∧ y 0 = y )]
0
hh[]-∧-distr ii [P ∧ Q] ≡ [P ] ∧ [Q]
= “ (A ⇒ B ∧ A) ≡ (A ⇒ B) ”
hh[]-idem ii [[P ]] ≡ [P ]
[x = e ⇒ (y 0 = y ⇒ P )]
0
hh[]-∀-absorbii [∀ x1 , . . . , xn • P ] ≡ [P ]
= “ hh[]-1pt ii ”
hh[]-1pt ii [x = e ⇒ P ] ≡ [P [e/x ]]
[y 0 = y ⇒ P [e/x 0 ]]
hh[]-split ii [P ] ≡ [P ] ∧ P [~e /~x ], αP = {~x }
= “ hh[]-1pt ii ”
[ P [e/x 0 ][y /y 0 ] ]
I It does not distribute over logical-or [P ∨ Q] 6≡ [P ] ∨ [Q]

Example: x :[x 0 ∈ {1, . . . , 10}] v x := 2 Example: wrong-Assignment as Frame refinement
Consider x :[P ] v y := e, assuming x and y in scope,
x :[x 0 ∈ {1, . . . , 10}] v x := 2 [y := e ⇒ x :[P ]]

= “ previous slide ” = “ hh:=-def ii, hhframe-def ii ”
[ (x 0 ∈ {1, . . . , 10})[2/x 0 ][y /y 0 ] ] [x = x ∧ y 0 = e ⇒ P ∧ y 0 = y ]
0
= “ substitution ” = “ hhshuntingii ”
[2 ∈ {1, . . . , 10}] [x = x ⇒ (y 0 = e ⇒ P ∧ y 0 = y )]
0
= “ set theory ” = “ hh[]-1ptii ”
[true] [(y = e ⇒ P ∧ y 0 = y )[x 0 /x ]]
0
= “ hh[]-trueii ” = “ hh[]-1ptii ”
true [(P ∧ y 0 = y )[x /x 0 ][e/y 0 ]]
[ (P [x /x 0 ][e/y 0 ] ∧ e = y ) ]
Example: x :[x 0 ∈ {1, . . . , 10}] 6v y := 99 Equality Substitution

I Earlier, we used a law referred to as “equality substitution”.
I If we assert a number of equalities, and something else, it
x :[x 0 ∈ {1, . . . , 10}] v y := 99 allows us to use those equalities in the “something else”
= “ previous slide ” I Formally:
[ (x ∈ {1, . . . , 10})[x /x 0 ][99/y 0 ] ∧ 99 = y ) ]
0
= “ substitution ” =-∧-substii
hh x =e∧P ≡ x = e ∧ P [e/x ]
[x ∈ {1, . . . , 10} ∧ 99 = y ]
= “ hh[]-splitii ”
[x ∈ {1, . . . , 10} ∧ 99 = y ] I Proof is by induction over the structure of P , so we omit it
∧ (x ∈ {1, . . . , 10} ∧ 99 = y )[0, 0/x , y ] (consider it an axiom).
= “ substitution ” I The law still holds if we only substitute e for x in part of P ,
[x ∈ {1, . . . , 10} ∧ 99 = y ] ∧ 0 ∈ {1, . . . , 10} ∧ 99 = 0
rather than all of it. We also have the following theorem:
= “ set-theory, arithmetic, logic, hand-waving ”
false =-⇒-substii
hh (x = e ∧ P ⇒ Q) ≡ (x = e ∧ P ⇒ Q[e/x ])

Refinement Example: MinMax (I) S v Q? Solution (Ia)
I Consider the following specification: x , y :[x , y := max (x , y ), min(x , y )]

v skip x ≥ y x , y := y , x
S =
b x , y :[x , y := max (x , y ), min(x , y )] = “ hhv-def ii ”
skip x ≥ y x , y := y , x

⇒ x , y :[x , y := max (x , y ), min(x , y )]

I “changing only x and y , ensure that x ends up as the = “ hh-def ii ”
maximum of the two, whilst y is the minimum.”

x ≥ y ∧ skip ∨ x < y ∧ x , y := y , x
I We posit the following “code” as a solution: ⇒ x , y :[x , y := max (x , y ), min(x , y )]
=  “ (A ∨ B ⇒ C) ≡ (A ⇒ C) ∧ (B ⇒ C) ” 
Q =
b skip x ≥ y x , y := y , x (x ≥ y ∧ skip
 ⇒ x , y :[x , y := max (x , y ), min(x , y )]) 
 
 ∧ (x < y ∧ x , y := y , x 
I Does Q refine S ? ⇒ x , y :[x , y := max (x , y ), min(x , y )])
S v Q? Solution (Ib) S v Q? Solution (Ic)
= “ hh[]-∧-distr ii ” = “ hhshuntingii(2) ”
x0= x ∧ y0 = y ⇒ x ≥ y

x ≥ y ∧ skip
⇒ x , y :[x , y := max (x , y ), min(x , y )] ⇒ x 0 = max (x , y ) ∧ y 0 = min(x , y )
∧ ∧
x0 = y ∧ y0 = x ⇒ x < y

x < y ∧ x , y := y , x
⇒ x , y :[x , y := max (x , y ), min(x , y )] ⇒ x 0 = max (x , y ) ∧ y 0 = min(x , y )
= “ hhskip-def ii, hhframe-def ii(2), hhsim-:=-defii ” = “ hh[]-1pt ii(2), replacing x 0 and y 0 ”
x ≥ y ∧ x0 = x ∧ y0 = y x0 = x ∧ y0 = y ⇒

⇒ x 0 = max (x , y ) ∧ y 0 = min(x , y ) x ≥ y ⇒ x = max (x , y ) ∧ y = min(x , y )

∧ ∧ 0
x < y ∧ x0 = y ∧ y0 = x x = y ∧ y0 = x ⇒

⇒ x 0 = max (x , y ) ∧ y 0 = min(x , y ) x < y ⇒ y = max (x , y ) ∧ x = min(x , y )

S v Q? Solution (Id) Refinement Example: MinMax (II)
= “ properties of max and min ”

[x 0 = x ∧ y 0 = y ⇒ true] I Given the following (familiar) program
∧
[x 0 = y ∧ y 0 = x ⇒ true] P =
b x := x + y ; y := x − y ; x := x − y
= “ hh⇒-r-zeroii ”
[true] ∧ [true]
= “ hh[]-trueii ” I Can we replace x , y := y , x in Q by P and still have it
true ∧ true refine S ?
= “ logic ”
true


Class 12 Mini-Issues (1–3)
A number of issues have been raised by class members while

working through the mini-exercises:
I Precisely how to interpret laws, when doing matching
against them.
I The strange notation P (b).
We address these briefly.
Pattern Matching Laws What is P (b)?
Consider, for example, the following laws:

Previously, we saw a law of the form
(∃ x • P ) ≡ (¬ (∀ x • ¬ P ))
v := e ≡ v 0 = e ∧ S 0 = S (∀ b : B • P (b)) ≡ P (False) ∧ P (True)
x , v 0 are regular observation variables, P is a predicate variable, Here, the intended meaning of P (b) is that P is a predicate that
e is an expression variable, and v is a program variable. (possibly) mentions b, as a free variable.
In general these match anything of the corresponding type. Then P (True) is P with all such free b replaced by True.
The exception is when such a variable has been defined It is a convenient shorthand, more formally written as
elsewhere to mean something specific. In such a case a
variable can only match itself. (∀ b : B • P ) ≡ P [False/b] ∧ P [True/b]
So far the only example we have seen of this is when we have
defined a specific alphabet. S, S 0 are list-variables that match
themselves, or the alphabet, if known.

re-examining Refinement Partial Orders (reminder)
I A set S, with a binary relation 4 between its elements, is
called a partial order (p.o.) iff:
I the relation is reflexive: ∀ x : S • x 4 x
I the relation is transitive:
I Consider the following laws:
∀ x, y, z : S • x 4 y ∧ y 4 z ⇒ x 4 z
hh v-reflii P vP
I the relation is anti-symmetric:
hhv-transii
∀ x, y : S • x 4 y ∧ y 4 x ⇒ x = y
(S v Q) ∧ (Q v P ) ⇒ (S v P )
hhv-antiii (P = Q) ≡ (P v Q) ∧ (Q v P )
I Examples:
I (N, 6), natural numbers under usual numeric ordering.
What do they say about refinement ? I (P T , ⊆), sets, under the subset relation.
I (Pred , ⇒), predicates, under the implication relation.
I It is a partial order. I (Pred , v), predicates, under the refinement relation.
I Partiality: in general some of these orders are partial, in
that, given arbitrary x and y , it may not be the case that
either x 4 y or y 4 x
e.g. {1, 2} 6⊆ {3} and {3} 6⊆ {1, 2}
Meet and Join (a.k.a. Min and Max) Meet and Join in Refinement
I We use the general symbols u and t to stand for meet and

I Given two elements x and y in a p.o.„ we can ask if their join with respect to the refinement ordering
minimum or maximum exists under that ordering.
I Meet and Join for refinement have simple definitions.
I We refer to the minimum as the “meet” (u), and the
maximum as the “join” (t). u-def ii
hh P uQ =
b P ∨Q
I If x 4 y then the meet of x and y is x , and their join is y . t-def ii
hh P tQ =
b P ∧Q
(x u y = x ) ≡ (x 4 y ) ≡ (x t y = y )
I From these we can deduce the following laws:
hhv-joinii (P v Q) ≡ (P t Q ≡ Q)
I Meets and joins exists for all our examples so far: hhv-meet ii (P v Q) ≡ (P u Q ≡ P )
I (N, 6), meet is minimum, join is maximum
I (P T , ⊆), meet is intersection, join is union.
I (Pred , ⇒), meet is logical-and, join is logical-or. I A p.o. in which meets and joins exists for all pairs of
elements is called a Lattice.

Complete Lattices Complete Lattices: a Key Property
I A complete lattice (S, 4) has overall maximum and
minimum elements
I A lattice is Complete if meets and joins (maxima/minima)
I The minimal element (⊥ or “bottom”) is simply
can be found for arbitrary sets of elements: ⊥ b de S
=
I de
F S — the minimum of all the elements of S
I S — the maximum of all the elements of S
I Not all of our examples are complete lattices: I The maximal element (> or “top”) is simply
I (N, 6) is not complete — what is the maximum element of G
the set of all even naturals? > = b S
I The following are complete lattices:
T S
I P T , ⊆, take and . I Clearly. both top and bottom satisfy the following laws:
I (Pred , ⇒), take ∀, ∃(?).
⊥ 4 x, for all x ∈ S
x 4 >, for all x ∈ S
Refinement is a Complete Lattice What are true and false ?

I The set of all predicates under the refinement relation
I So, we have
forms a complete lattice true v P v false
I for any predicate P .
P uQ ≡ P ∨Q I In terms of our interpretation of predicates as programs
P tQ ≡ P ∧Q
W and/or specifications, what do true and false denote?
de S ≡ S I true is the weakest possible specification (“whatever”) or
de {P1 , . . . ,FPn } ≡ V1 ∨ . . . ∨ Pn
P the most badly behaved program (“do anything”)
S ≡ S
F I We shall call it “Chaos” (a.k.a “abort”)
{P1 , . . . , Pn } ≡ P1 ∧ . . . ∧ Pn
Chaos =
b true
I The minimal events:
⊥ ≡ true I false is capable of satisfying any specification !
true v P I We shall call it “miracle” (a.k.a. “magic”).
> ≡ false
P v false miracle =
b false

Implication Lattice Refinement Lattice
relating predicates with universal implication ([ ⇒ ]),: relating programs/specifications with refinement (v):
false strong miracle prog.
x0 = 3 x0 = 6 x := 3 x := 6
x0 = 3 ∨ x0 = 6 x := 3 u x := 6 v
x 0 ∈ {1 . . . 10} x : [x 0 ∈ {1 . . . 10}]
true weak Chaos spec.
The Theology of Computing Refinement
miracle prog. I The notion of Refinement, relating a specification to any

program that satisfies it, is key in formal methods.
I In our formalism, UTP, it (v) is defined as
x := 3 x := 6 “universally-closed ( [ ] ) reverse implication (⇐):
hhv-def ii SvP =
b [S ⇐ P ]
x := 3 u x := 6 v
I The key thing to remember is the reversal of the

x : [x 0 ∈ {1 . . . 10}] implication, e.g.
SvP ≡ [P ⇒ S]
Chaos spec.

Laws of Implication (some) Laws of Refinement
I There are many laws of implication:
hhv-reflii P vP
hh ⇒-reflii P ⇒ P ≡ true
hh⇒-transii (P ⇒ Q) ∧ (Q ⇒ R) ⇒ (P ⇒ R) hhv-transii (S v Q) ∧ (Q v P ) ⇒ (S v P )
hhv-antiii (P = Q) ≡ (P v Q) ∧ (Q v P )
hh≡-⇒-transii (P ≡ Q) ∧ (Q ⇒ R) ⇒ (P ⇒ R)
hh≡-v-transii (S = Q) ∧ (Q v P ) ⇒ (S v P )
hh⇒-≡-transii (P ⇒ Q) ∧ (Q ≡ R) ⇒ (P ⇒ R)
hhv-≡-transii (S v Q) ∧ (Q = P ) ⇒ (S v P )
hhstrengthen-anteii P ∧Q⇒P
hhv-prog-alt ii S v P ∨ Q ≡ (S v P ) ∧ (S v Q)
hhweaken-cnsq ii P ⇒P ∨Q
hhv-spec-split ii S ∧ T v P ≡ (S v P ) ∧ (T v P )
hhante-∨-distr ii P ∨ Q ⇒ R ≡ (P ⇒ R) ∧ (Q ⇒ R)
hh≡-imp-vii (P = Q) ⇒ (P v Q)
hhcnsq-∧-distr ii P ⇒ Q ∧ R ≡ (P ⇒ Q) ∧ (P ⇒ R)
hhspec-weakeningii S∨T vT
hhprog-strengthenii P vP ∧Q
I As refinement is defined as “universally-closed reverse
implication”, we expect to derive many refinement laws
from these, and similar laws.
Exploring the Refinement Laws (I) Exploring the Refinement Laws (II)
I P vP hh v-reflii
Anything refines itself (trivially). I S v P ∨ Q ≡ (S v P ) ∧ (S v Q) hhv-prog-alt ii
I (P = Q) ⇒ (P v Q) ≡-imp-vii
hh Refining by an arbitrary choice of alternatives is the same
Equality is a (fairly trivial) refinement. as refining by both options individually
I (P = Q) ≡ (P v Q) ∧ (Q v P ) hhv-antiii I S ∧ T v P ≡ (S v P ) ∧ (T v P ) hhv-spec-split ii
Two programs/specifications are equal if they refine each Satisfying a specification with two mandatory parts is the
other. same as satisfying both parts individually.
I (S v Q) ∧ (Q v P ) ⇒ (S v P ) hhv-transii I S∨T vT hhspec-weakeningii
If Q refines S, and P refines Q, then P also refines S. A specification offering alternatives can be satisfied by
We can do refinement in several steps. choosing one of those alternatives
I (S = Q) ∧ (Q v P ) ⇒ (S v P ) hh≡-v-transii I P vP ∧Q hhprog-strengthenii
(S v Q) ∧ (Q = P ) ⇒ (S v P ) hhv-≡-transii A specification can be refined by adding in extra

A refinement step can also be a replacement by something constraints.
equal.

Proving some refinement laws Proof of hh≡-v-transii
I Goal: (S = Q) ∧ (Q v P ) ⇒ (S v P ).
I Strategy: reduce to law hh⇒-≡-transii.
I Proof:
I Select and do in class.
I Note the following meta-theorem: (S = Q) ∧ (Q v P ) ⇒ (S v P )
I If P is a theorem, then so is [P ] = “ hhv-def ii ”
I Why: because if P is a theorem, then it is true for all S = Q ∧ [P ⇒ Q] ⇒ [P ⇒ S]
instantiations of variables it contains. So, it remains true if = “ equality substitution, S = Q ”
we quantify over the expression variables. S = Q ∧ [P ⇒ Q] ⇒ [P ⇒ Q]
= “ hhstrengthen-anteii ”
true

Mini-Exercise 4
Q4.1 Prove law ~x :[A] v ~x :[A ∧ B]

(due in next Friday, 2pm, in class)

Class 13 Exploring the Refinement Laws (III)
I Consider the addition of a notation for arrays into our

expression language.
I If a is an array, then ai denotes the i th element.
I We assume the array elements are indexed from 1 . . . N .
Find index of a value Running the programs

I Consider specification spec:
I Consider starting state
p : ap 0 = w w ∈ a p 0 = 0

1 2 3 4 5 6
Modifying p, set it equal to the index of an element in the w =3∧a=2 1 3 1 3 2 (N = 6)

array equal to w , otherwise zero.
I Consider prog1 : I Running prog1 results in the final outcome:
p := 1
p0 = 3
; (ap 6= w ∧ p < N ) ~ p := p + 1
; p := 0 p = N skip (it searches left-to-right)
I Running prog2 results in the final outcome:
I Consider prog2 :
p0 = 5
p := N
; (ap 6= w ∧ p > 0) ~ p := p − 1 (it searches right-to-left)
Relating spec and the progi Refinement and non-determinism
I We see that both programs refine the specification: I The programs are deterministic
spec v progi , i ∈ 1, 2 prog1 search left-to-right
prog2 search right-to-left
I Both programs, however, have different outcomes. I The choice between them has some non-determinism
prog1 6= prog2 prog1 ∨ prog2 search either l-to-r, or r-to-l
(p 0 = 3 vs. p 0 = 5).
I The specification has lots of non-determinism
I An arbitrary choice between the programs also refines the
spec: spec search any which-way
spec v prog1 ∨ prog2
(p 0 = 3 ∨ p 0 = 5) I Refinement is essentially about reducing non-determinism.
Program-Oriented Refinement Laws Proof of hhv-:=ii
I Most of the refinement laws seen to date are derived from

the implication laws.
I We have others as well, based on language constructs: x 0 = e v x := e
hhv-:=ii x 0 = e v x := e x 0 = e v x 0 = e ∧ S 0\x 0 = S\x
hhv-sim-:=ii x~0 = ~e v ~x := ~e = “ hhv-def ii ”
hh:=-lead ii P v x := e ; P , x 6 P [ x = e ∧ S 0\x 0 = S\x ⇒ x 0 = e ]
0
hh:=-trailii P v P ; x := e, x 0 6 P = “ prop. law: A ∧ B ⇒ A ”
hhsim-:=-lead ii P v ~x := ~e ; P , ~x 6 P [true]
hhsim-:=-trailii P v P ; ~x := ~e , x~0 6 P = “ hh[]-trueii ”
hhv-; ii (S1 v P1 ) ∧ (S2 v P2 ) ⇒ (S1 ; S2 ) v (P1 ; P2 ) true
I / P and x 0 ∈
The conditions x ∈ / P exclude a lot, e.g. all
assignment statements (why?)

Proof of hh:=-trailii Proof of hh:=-trailii (cont.)
[ ( ∃ xm , Sm\xm • P [Sm \xm /S 0\x 0 ]

P v P ; x := e
∧ x 0 = e[xm , Sm \xm /x , S\x ] ∧ S 0\x 0 = Sm\xm )
= “ hhv-def ii,hh:=-def ii ”
⇒ P]
[ P ; x 0 = e ∧ S 0\x 0 = S\x ⇒ P ]
= “ hh∃-1ptii ”
[ ( ∃ xm • P [Sm \xm /S 0\x 0 ][S 0 \x 0 /Sm\xm ]
[ (∃ xm , Sm\xm • P [xm , Sm \xm /x 0 , S 0\x 0 ]
∧ x 0 = e[xm , Sm \xm /x , S\x ][S 0 \x 0 /Sm\xm ] )
∧ (x 0 = e ∧ S 0\x 0 = S\x )[xm , Sm \xm /x , S\x ])
⇒ P]
⇒ P]
= “ hhsubst-invii,hh∧-∃-distr ii with xm 6 P ”
= “ substitution, noting x 0 6 P ”
[ P ∧ ( ∃ xm • x 0 = e[xm , S 0 \x 0 /x , S\x ][S 0 \x 0 /Sm\xm ] ) ⇒ P ]
[ ( ∃ xm , Sm\xm • P [Sm \xm /S 0\x 0 ]
= “ prop. law: A ∧ B ⇒ A ”
∧ x 0 = e[xm , Sm \xm /x , S\x ] ∧ S 0\x 0 = Sm\xm )
[true]
⇒ P]
= “ hh[]-trueii ”
(cont. overleaf) true
Real Life: BASE Trusted Gateway BASE: Key Results (1)
Goal — Trusted Gateway for transferring messages

between different security levels,
for British Aerospace Systems & Equipment. I Formal approach spent more time up front in System
Approach — Two teams, one conventional, the other using Design (43% as against 34%).
formal methods. I Formal approach uncovered an implicit special condition
Method — Formal team employed VDM-SL, using IFAD from requirements.
Toolkit. Informal code had to be re-written at late stage to cope.
Who — T.M.Brookes, J.S.Fitzgerald & P.G.Larsen, I Formal code was less complex (“McCabe Complexity”)
“Formal and Informal Specifications of a Secure I Formal code one-fifth the size of informal code.
System Component”
in FME’96: Industrial Benefit and Advances in
Formal Methods,
LNCS 1051, pp214–227, 1996.

BASE: Key Results (2) BASE: Key Results (3)
Formal system started up slower Formal system throughput higher

(4 times longer) (almost 14 times faster)
1. Formal System Invariant better understood, so more care 1. The informal system had to have a last-minute fix, so the
was taken by resulting initialisation code. code speed got worse.
2. Not a big issue as the system is meant to stay up and 2. If code is formally verified, then you don’t need so many
running. run-time checks (array bounds, etc.)
Reasoning about Loops Loop Semantics

I What is the meaning of c ~ P ?
I Let us call it W .
I It must satisfy the un-rolling law:
I So far we have one law regarding loops, that “unrolls” once: W = (P ; W ) c skip
~-unrollii
hh c ~P = (P ; c ~ P ) c skip
I It must also be the the least predicate that satisfies this law:
I This has limited utility, as we often want to reason about (X = (P ; X ) c skip) ⇒ W v X
arbitrary numbers of “un-rollings”.
I These results come from a branch of mathematics called

“fixpoint theory”
I The “meaning” of recursion is (typically) the least fixed point
of an appropriate higher-order function
I We shall not concern ourselves with this at present.
Infinite Loops Forever is bad
I What is the meaning of true ~ skip ?

I It is an infinite loop, so call it Forever I Every predicate satisfies the Forever unrolling law,
including miracle and Chaos, our two extremes.
I It must satisfy the un-rolling law:
I It makes no sense to pick a predicate “in the middle”, so
Forever = (skip; Forever ) true skip which extreme point should we use ?
= skip; Forever I If we use miracle, then Forever refines any specification,
which is not desirable at all.
I However, all of the following satisfy this instance of the I It makes sense to choose Chaos, as it is least in our
un-rolling law: ordering, and the only thing refining it is itself.
I miracle = skip ; miracle I So Forever = Chaos = true
I skip = skip ; skip
I Chaos = skip ; Chaos
So Chaos covers all unpredictable/undesirable behaviour,
I P = skip ; P for any P (It’s law hhskip-; -unit ii) ! including non-termination.
I Why pick the least of these as the meaning of Forever ?

Class 14 Loop Reasoning
I Given a loop c ~ P , and possible candidate W :
I checking the unroll-law is not too bad:
W = (P ; W ) c skip
I checking for the least such fixpoint is painful:
(X = (P ; X ) c skip) ⇒ W v X , for any X
I Fortunately, in many cases, the fixpoint is unique.

I We won’t characterise the unique cases here (quite
technical).
I Instead we shall just use the unroll check.
I A challenge still remains: finding W !
A Simple example (I) A convenient shorthand

I Our specification: summing (natural) numbers between 1 I To simplify matters we defined the following shorthand
and n:  
P
X S(m) =b i ∈1...m i
SSum = b s, i :s 0 = j
j ∈1...n
So S(m) is the sum of numbers from 1 to m.
. P
I Note that i above is local, being bound by the operator.
I Our program:
I It obeys the following laws:
PSum =
b s := 0 ; i := n ; (i > 0)~(s := s +i ; i := i −1)
S(0) = 0
S(n) = S(n − 1) + n, n>0
I Our goal, to prove the program satisfies our specification:
I Our specification becomes:
SSum v PSum
b s, i :[s 0 = S(n)]
SSum =
I We assume all variables are natural numbers1 .

1 CS4003 Formal Methods CS4003 Formal Methods
a.k.a. “unsigned int”
A Simple example (II) A Simple example (III — SInit v PInit )
I Our strategy, to split the spec and program into two parts:
initialisation and the loop, and do these separately:
SInit v PInit
I We take a simple approach here, setting SInit = PInit
SLoop v PLoop I
PInit
= “ defn. ”
I Here, we have s := 0; i := n
PInit =
b s := 0 ; i := n = “ hhsim-:=-mergeii ”
PLoop =b (i > 0) ~ (s := s + i ; i := i − 1) s, i := 0, n
= “ hhsim-:=-def ii ”
s = 0 ∧ i 0 = n ∧ n0 = n
0
I We then use the following law of refinement (hhv-; ii) to
= “ by design ”
complete:
SInit
(S1 v P1 ) ∧ (S2 v P2 ) ⇒ (S1 ; S2 ) v (P1 ; P2 )
I The question now is, what are SInit and SLoop ? CS4003 Formal Methods CS4003 Formal Methods
A Simple example (IV — SLoop v PLoop) A Simple example (V — “guessing” W )
I Our loop specification says we sum on top of starting s

value: I We suggest the following definition for W :
b s, i : s 0 = s + S(i )

SLoop =
W =
b i 0 = 0 ∧ s 0 = s + S(i ) ∧ n 0 = n
I But what is PLoop ?

I We need to find W such that I It iterates until i = 0, so hence i 0 = 0.
I It sums from starting i down to 1
W = (s := s + i ; i := i − 1 ; W ) i > 0 skip I It adds on top of the starting value of s
I It does not change n.
I Do we guess ? informed guess ? informed by what ?

A Simple example (VI.a — simplifying W ) A Simple example (VI.b — simplifying W )
I More pre-computation (here ignoring n and n 0 for brevity):
I It is useful to do some pre-computation: i > 0 ∧ (s := s + i ; i := i − 1 ; W )
= “ defn. W , ”
i =0∧W i > 0 ∧ (s 0 = s + i ∧ i 0 = i − 1 ;
= “ defn. W ” i 0 = 0 ∧ s 0 = s + S(i ))
i = 0 ∧ i 0 = 0 ∧ s 0 = s + S(i ) ∧ n 0 = n = “ hh; -def ii, substitution ”
= “ equality substitution ” i > 0 ∧ (∃ sm , im • sm = s + i ∧ im = i − 1 ;
i = 0 ∧ i 0 = 0 ∧ s 0 = s + S(0) ∧ n 0 = n i 0 = 0 ∧ s 0 = sm + S(im ))
= “ arithmetic ” = “ hh∃-1pt ii ”
i = 0 ∧ i 0 = 0 ∧ s0 = s ∧ n0 = n i > 0 ∧ i 0 = 0 ∧ s 0 = s + i + S(i − 1)
= “ hhskip-def ii ” = “ arithmetic ”
i = 0 ∧ skip i > 0 ∧ i 0 = 0 ∧ s 0 = s + S(i )
= “ defn. W ”
i >0∧W
A Simple example (VII — checking W ) A Simple example (VIII — SLoop v W )
I We need to check our W is a fixed-point:

I We need to show that W , our semantics for PLoop does in
fact refine the loop specification.
(s := s + i ; i := i − 1 ; W ) i > 0 skip
= “ hh-def ii, hhsim-:=-mergeii ” SLoop v W
i > 0 ∧ (s, i := s + i , i − 1 ; W ) ∨ i = 0 ∧ skip = “ defns. ”
= “ previous calculations ” [ i = 0 ∧ s 0 = s + S(i ) ∧ n 0 = n
0
i >0∧W ∨i =0∧W ⇒
= “ hh∧-∨-distr ii ” s, i :[s 0 = s + S(i )] ]
(i > 0 ∨ i = 0) ∧ W = “ hhframe-def ii ”
= “ hhexcluded-middleii, noting i : N ” [ i = 0 ∧ s 0 = s + S(i ) ∧ n 0 = n
0
true ∧ W ⇒
= “ hh∧-unitii ” s 0 = s + S(i ) ∧ n 0 = n ]
W = “ prop. law [A ∧ B ⇒ A] ”
true

A Simple example (IX — final assembly) Uuuugh !
I We have SInit = PInit and SLoop v PLoop, so we can

conclude by hhv-; ii that SInit ; SLoop v PInit ; PLoop.
I However, we need to show that SSum = SInit ; SLoop
SInit ; SLoop I We showed that SLoop v PLoop

= “ defns. ” I It was an ad-hoc approach
s 0 = 0 ∧ i 0 = n ∧ n 0 = n ; s 0 = s + S(i ) ∧ n 0 = n
= “ hh; -def ii, subst. ”
I Complicated, long-winded
∃ sm , im , nm • sm = 0 ∧ im = n ∧ nm = n I Is there a better, more systematic way ?
∧ s 0 = sm + S(im ) ∧ n 0 = nm
= “ hh∃-1ptii ”
s = 0 + S(n) ∧ n 0 = n
0
= “ arithmetic, hhframe-def ii ”
s, i :[s 0 = S(n)]
A Simple example (revisited — I) A Simple example (revisited — II)
I Consider two cases:

1. the loop is continuing, as i > 0, so we have I Consider partway through, where 0 < i < n.
i >0 ⇒ W = s := s + i ; i := i − 1 ; W We have summed from n down to i + 1.
I So the final sum should be the current value of s, plus the
remaining numbers to be added, namely from i down to 1.
2. the loop has terminated, as i = 0, so we have
I We posit:
i =0 ⇒ W = skip inv =
b S(n) = s + S(i )
I Whilst the loop is continuing, we see that W is in some I At the start, i = n ∧ s = 0, so inv holds
sense doing the same thing each time round I At the end, i = 0 ∧ inv , so s = S(n) holds
I Somehow W must embody a property true before and
after each iteration: the loop invariant (inv ).

A Simple example (revisited — III) Invariants
I From where did we magic this invariant?
s + S(i ) = S(n) I For a while-loop c ~ P , an invariant inv is:

I a condition (undashed variables only)
I Considering execution snapshots often helps I required to be true before we execute the loop
I will be true after each iteration around the loop
i: n n−1 n−2 k 0 I will be true on exit from the loop
n n I Such conditions are called “invariants” because they state
+ + a property that does not change as the loop executes.
n (n − 1) (n − 1)
I Surprisingly, the loop invariant is key to proving that a loop
s: 0 n + + +
.. .. does the right thing !
(n − 1) . . I A “variant” predicate, describing how P changes things in
+ + each iteration does not help in this regard !!
(k + 1) 1
S(i ) : S(n) S(n − 1) S(n − 2) S(k ) S(0)
As i shrinks, s increases CS4003 Formal Methods CS4003 Formal Methods
Loops and Invariants Loop Refinement (I)

I if inv is an invariant for c ~ P , then the following holds:
I If c and inv are true, then execution of the loop body will I We can put two refinements together into a refinement
leave inv 0 true. inference rule:
rel-is-invariant ii ~v :[c ∧ inv ⇒ inv 0 ] v P ~v : c ∧ inv ⇒ inv 0
hh

v P
~v : inv ⇒ inv 0 ∧ ¬ c 0 v c ~ (v : c ∧ inv ⇒ inv 0 )

~
~v : inv ⇒ inv 0 ∧ ¬ c 0

I If inv is true beforehand, then on termination of the loop, v c ~P
inv 0 is true, as is ¬ c 0
hhrel-v-ii I In other words, in order to show that S v c ~ P , we need
~v :[inv ⇒ inv 0 ∧ ¬ c 0 ] v 0
c ~ (~v :[c ∧ inv ⇒ inv ]) to:1. Look at c and P to find an appropriate invariant inv ,
satisfying hhrel-is-invariantii.
2. Show S is refined by inv ⇒ inv 0 ∧ ¬ c 0
I Note that we have to carry the same frame ~v :[. . .] through
3. Show that hhrel-v-ii holds.
the refinement.
I Proof of these rules is (slightly) beyond the scope of this
I So, we have two refinement checks:
course.
I hh rel-is-invariantii checks that inv is an invariant for c ~ P
I hh rel-v-ii states how we can refine such a loop
Loop Refinement (II) The Simple example (redone — I)
I However, using invariants requires that inv holds at loop I Reminder: we want to show
start. s, i :[s 0 = S(n)]
We need to ensure that initialization brings this about. v s, i := 0, n ; (i > 0) ~ (s, i := s + i , i − 1)
I Another refinement rule hhrel-init-loop-vii allows us to
couple both initialisation and the loop: using inv = s + S(i ) = S(n).
I We need to get the specification into the correct form,
~v :[pre ⇒ inv 0 ∧ ¬ c 0 ]
which requires the very useful, very general refinement
v ~v :[pre ⇒ inv 0 ] ; c ~ ~v :[c ∧ inv ⇒ inv 0 ] inference rule hhstrengthen-post ii:
~v :[Post1 ] v ~v :[Post2 ]
I Given refinement check S v c ~ P , we no longer look for
an appropriate W . ~v :[pre ⇒ Post1 ] v ~v :[pre ⇒ Post2 ]
I Instead we have to find inv , which is simpler. (The rationale for this law will follow shortly)
The Simple example (redone — II) Reminder: “equality substitution”
We can now proceed:
s, i :[s 0 = S(n)]
I We have the law hh=-∧-substii:
= “ hh⇒-l-unitii ” x = e ∧ P ≡ x = e ∧ P [e/x ]
s, i :[true ⇒ s 0 = S(n)] I From this we can derive many useful laws, e.g.
v “ hhstrengthen-post ii, using ~x :[A] v ~x :[A ∧ B] ”
hh=-⇒-substii (x = e ∧ P ⇒ Q) ≡ (x = e ∧ P ⇒ Q[e/x ])
s, i :[true ⇒ s 0 = S(n) ∧ i 0 = 0]
hh=-v-subst ii (S v P ∧ x = e) ≡ (S[e/x ] v P ∧ x = e)
= “ 0 = S(0) = S(i 0 ) and frame requires n 0 = n ”
s, i :[true ⇒ s 0 + S(i 0 ) = S(n 0 ) ∧ i 0 = 0]
v “ hhrel-init-loop-vii ” I Remember also, that the laws above also apply even if we
s, i :[true ⇒ s 0 + S(i 0 ) = S(n 0 )] don’t replace all free x with e, but instead only change
; (i > 0) ~ s, i :[i > 0 ∧ s + S(i ) = S(n) ⇒ s 0 + S(i 0 ) = S(n 0 )] some.
At this point we can refine the two statements individually.

Intuition for “equality substitution” The Simple example (redone — III)
The first statement

s, i :[true ⇒ s 0 + S(i 0 ) = S(n 0 )] v s, i := 0, n
I In essence the equality substitution laws just mentioned = “ hh⇒-l-unitii,hhframe-def ii, hhsim-:=-def ii ”
express when we can propagate an identity (e1 = e2 )
around the rest of its containing predicate. s 0 + S(i 0 ) = S(n 0 ) ∧ n 0 = n v s 0 = 0 ∧ i 0 = n ∧ n 0 = n
= “ hhv-def ii ”
I by “propagating e1 = e2 ” we mean identifying places in the
containing predicate where we can replace e1 by e2 , or v.v. [ s = 0 ∧ i 0 = n ∧ n 0 = n ⇒ s 0 + S(i 0 ) = S(n 0 ) ∧ n 0 = n ]
0
= “ hh=-⇒-substii ”
I Identities propagate through logical-and (∧).
[ s = 0 ∧ i 0 = n ∧ n 0 = n ⇒ 0 + S(n) = S(n) ∧ n = n ]
0
I Identities propagate leftwards through implication (⇒), i.e. = “ arithmetic ”
following the arrow. [ s = 0 ∧ i 0 = n ∧ n 0 = n ⇒ true ]
0
= “ hh⇒-r-zeroii ”
true
The Simple example (redone — IV) Refining by Initialised While-Loops: recap

The second statement
s, i :[i > 0 ∧ s + S(i ) = S(n) ⇒ s 0 + S(i 0 ) = S(n 0 )]
v s, i := s + i , i − 1
To refine ~v :[S] by init ; c ~ P we need to :
= “ hhframe-def ii, hhsim-:=-def ii ”
(i > 0 ∧ s + S(i ) = S(n) ⇒ s 0 + S(i 0 ) = S(n 0 )) ∧ n 0 = n 1. find an appropriate invariant inv
v s0 = s + i ∧ i 0 = i − 1 ∧ n0 = n 2. find an appropriate pre-condition pre (often true will do)
= “ hh=-v-substii ” 3. show that ~v :[S] v ~v :[pre ⇒ inv 0 ∧ ¬ c 0 ]
(i > 0 ∧ s + S(i ) = S(n) ⇒ s + i + S(i − 1) = S(n)) ∧ n = n 4. Then it remains to verify both
v s 0 = s + i ∧ i 0 = i − 1 ∧ true
= “ arithmetic, esp laws of S(x ) ” ~v :[pre ⇒ inv 0 ] v init
(i > 0 ∧ s + S(i ) = S(n) ⇒ s + S(i ) = S(n)) ~v :[c ∧ inv ⇒ inv 0 ] v P
v s0 = s + i ∧ i 0 = i − 1 ∧ n0 = n
= “ prop. calc A ∧ B ⇒ A ”
true v s 0 = s + i ∧ i 0 = i − 1 ∧ n 0 = n
= “ true (Chaos) is refined by anything ”
true
Invariants: the last words
I Invariants capture a property that is true before and after

every iteration of the loop body
I However, the existence of an invariant, does not mean that
nothing changes going round the loop
I Clearly something must change or the loop would not
achieve its goal (or terminate).
I The trick in verifying loops is finding the appropriate
invariant.

Class 15 Pre and post conditions
I We have seen a few specifications now of the form
P ⇒Q
I Typically P has been a condition (no dashed-variables)

whilst Q may have had both dashed and non-dashed
variables.
I We shall use lower-case names for predicates that are
conditions
I p : a pre-condition (no dashed variables)
I p 0 : a post -condition (only dashed variables)
I P : a pre-post-relation (mixed variables)
Interpreting Implications (I) Interpreting Implications (II)
I The specification
pre ⇒ post 0 I Given specification pre ⇒ Rel what should our refinement
do, in situations were pre is False?
I is interpreted as I Guiding principle: guarantees and commitments
“if pre holds at the start, the we must ensure that post holds I The pre-condition pre is a guarantee that some other agent
at the end”. will set things up appropriately.
I relates a “pre-snapshot” to a “post-snapshot”
I Given that guarantee has been met, then Rel is the
I The specification commitment that any refinement must make.
pre ⇒ Rel
I But, but, if the guarantee isn’t met ?
I If the pre-condition is False we can do anything.
I is interpreted as I in general we cannot offer anything better than that
“if pre holds at the start, then we must ensure that start and consider: x , r : R ∧ x ≥ 0 ⇒ (r 0 )2 = x
end states are related by Rel ”. what can we do if x < 0?
I relates a “pre-snapshot” to a relationship between before
and after states
Loop Refinement Example 1 (Floyd ’67) Refining Floyd’67: process
Given
a : array 1 . . . n of R
A(0) = 0 We need to
A(x ) = ax + A(x − 1), x > 0 1. find appropriate invariant ainv
2. show ASpec v s, i :[ainv 0 ∧ i 0 > n 0 ]
b s, i :[s 0 = A(n)]
ASpec =
(precondition is true, so we ignore it)
αAProg = {n, i , s, n 0 , i 0 , s 0 } 3. show s, i :[ainv 0 ] v i , s := 1, 0
b i , s := 1, 0 ; (i ≤ n) ∗ (s, i := s + ai , i + 1)
AProg = 4. show s, i :[i ≤ n ∧ ainv ⇒ ainv 0 ] v s, i := s + ai , i + 1
Prove
ASpec v AProg
Refining Floyd’67: process (1) Refining Floyd’67: process (1x)
We introduce a shorthand, with laws:

Looking at loop execution:
Pu
A(`, u) =b j =` aj
i 1 2 3 k n n+1 A(k , k ) = ak
s 0 a1 a1 + a2 a1 + · · · ak −1 a1 + · · · an−1 a1 + · · · an A(`, u) = 0, ` > u
A(0) A(1) A(2) A(k − 1) A(n − 1) A(n) A(`, u) = a` + A(` + 1, u), ` 6 u
Pn A(1, n) = A(n), n > 0
We can see that for i = k that s + j =k aj = A(n).
Pn Now the invariant is more concise
ainv b s+
= j =i = A(n)
ainv b s + A(i , n) = A(n)
=

Refining Floyd’67: process (2) Refining Floyd’67: process (3)
We must show ASpec v s, i :[ainv 0 ∧ i 0 > n 0 ] We must show s, i :[ainv 0 ] v i , s := 1, 0
s, i :[s 0 = A(n)] v s, i :[s 0 + A(i 0 , n 0 ) = A(n 0 ) ∧ i 0 > n 0 ] s, i :[s 0 + A(i 0 , n 0 ) = A(n 0 )] v i , s := 1, 0

= “ hhframe-def ii ” = “ hhframe-def ii,hhsim-:=-def ii ”
s = A(n) ∧ n 0 = n v s 0 + A(i 0 , n 0 ) = A(n 0 ) ∧ i 0 > n 0 ∧ n 0 = n
0 s + A(i 0 , n 0 ) = A(n 0 ) ∧ n 0 = n v i 0 = 1 ∧ s 0 = 0 ∧ n 0 = n
0
= “ A(i 0 , n 0 ) = 0 if i 0 > n 0 ” = “ hh=-v-substii ”

s = A(n) ∧ n 0 = n v s 0 = A(n 0 ) ∧ i 0 > n 0 ∧ n 0 = n
0 0 + A(1, n 0 ) = A(n 0 ) ∧ n 0 = n v i 0 = 1 ∧ s 0 = 0 ∧ n 0 = n
= “ hh=-v-substii ” = “ law A(1, n) = A(n) ”
s = A(n 0 ) ∧ n 0 = n v s 0 = A(n 0 ) ∧ i 0 > n 0 ∧ n 0 = n
0 true ∧ n 0 = n v i 0 = 1 ∧ s 0 = 0 ∧ n 0 = n
= “ hhprog-strengthenii ” = “ hh∧-unitii,hhprog-strengthenii ”
true true
Refining Floyd’67: process (4) Refining Floyd’67: process (4 cont.)
We must show s, i :[i ≤ n ∧ ainv ⇒ ainv 0 ] v s, i := s + ai , i + 1
s, i :[i ≤ n ∧ s + A(i , n) = A(n) ⇒ s 0 + A(i 0 , n 0 ) = A(n 0 )] s, i :[i ≤ n ∧ s + A(i , n) = A(n) ⇒ s + A(i , n) = A(n)]
v s, i := s + ai , i + 1 v s 0 = s + ai ∧ i 0 = i + 1 ∧ n 0 = n
= “ hhsim-:=-def ii ” = “A∧B⇒B”
s, i :[i ≤ n ∧ s + A(i , n) = A(n) ⇒ s 0 + A(i 0 , n 0 ) = A(n 0 )] s, i :[true]
v s 0 = s + ai ∧ i 0 = i + 1 ∧ n 0 = n v s 0 = s + ai ∧ i 0 = i + 1 ∧ n 0 = n
= “ hh=-v-substii ” = “ hhframe-def ii ”
s, i :[i ≤ n ∧ s + A(i , n) = A(n) ⇒ s + ai + A(i + 1, n) = A(n)] true ∧ n 0 = n
v s 0 = s + ai ∧ i 0 = i + 1 ∧ n 0 = n v s 0 = s + ai ∧ i 0 = i + 1 ∧ n 0 = n
= “ law of A( , ) ” = “ hhprog-strengthenii ”
s, i :[i ≤ n ∧ s + A(i , n) = A(n) ⇒ s + A(i , n) = A(n)] true
v s 0 = s + ai ∧ i 0 = i + 1 ∧ n 0 = n

Loop Refinement Example 2 (Hoare ’69) Refining Hoare’69: process
Given
We need to
b r , q :[y 0 > r 0 ∧ x 0 = r 0 + y 0 ∗ q 0 ]
HSpec = 1. find appropriate invariant hinv
2. show HSpec v r , q :[hinv 0 ∧ y 0 > r 0 ]
b r , q := x , 0 ; (y ≤ r ) ∗ (r , q := r − y , 1 + q)
HProg =
(precondition is true, so we ignore it)
Prove 3. show r , q :[hinv 0 ] v r , q := x , 0
HSpec v HProg 4. show r , q :[y ≤ r ∧ hinv ⇒ hinv 0 ] v r , q := r − y , 1 + q
Refining Hoare’69: process (1) Refining Hoare’69: process (2)
Looking at loop execution:

We must show HSpec v r , q :[hinv 0 ∧ y 0 > r 0 ]
r x x −y x − 2y x −k ·y x −n·y
q 0 1 2 k n r , q :[y 0 > r 0 ∧ x 0 = r 0 + y 0 ∗ q 0 ]
v r , q :[x 0 = r 0 + q 0 ∗ y 0 ∧ y 0 > r 0 ]
We can see that for q = k that r = x − k · y . = “ hhv-reflii ”
true
hinv b x =r +q ·y
=

Refining Hoare’69: process (3) Refining Hoare’69: process (4)
We must show r , q :[hinv 0 ] v r , q := x , 0

We must show r , q :[y ≤ r ∧ hinv ⇒ hinv 0 ] v r , q := r − y , 1 + q
r,q :[x 0 r0
= + ∗ q0 y 0]
v r , q := x , 0
= “ frame-def , sim-:=-def ii ”
hh ii hh r , q :[y ≤ r ∧ x = r + q ∗ y ⇒ x 0 = r 0 + q 0 ∗ y 0 ]
x = r 0 + q0 ∗ y 0 ∧ x 0 = x ∧ y 0 = y
0 v r , q := r − y , 1 + q
v r 0 = x ∧ q0 = 0 ∧ x 0 = x ∧ y 0 = y = “ hhframe-def ii,hhsim-:=-def ii ”
= “ hh=-v-substii ” (y ≤ r ∧ x = r + q ∗ y ⇒ x 0 = r 0 + q 0 ∗ y 0 ) ∧ x 0 = x ∧ y 0 = y
x = x + 0 ∗ y ∧ x0 = x ∧ y0 = y v r 0 = r − y ∧ q0 = 1 + q ∧ x 0 = x ∧ y 0 = y
v r 0 = x ∧ q0 = 0 ∧ x 0 = x ∧ y 0 = y = “ hh=-v-subst ii ”
= “ arithmetic ” (y ≤ r ∧ x = r + q ∗ y
true ∧ x 0 = x ∧ y 0 = y v r 0 = x ∧ q 0 = 0 ∧ x 0 = x ∧ y 0 = y ⇒ x = r − y + (q + 1) ∗ y ) ∧ x 0 = x ∧ y 0 = y
= “ hhprog-strengthenii ” v r 0 = r − y ∧ q0 = 1 + q ∧ x 0 = x ∧ y 0 = y
true
Refining Hoare’69: process (4 cont.) One More Loop Example
(y ≤ r ∧ x = r + q ∗ y
⇒ x = r − y + (q + 1) ∗ y ) ∧ x 0 = x ∧ y 0 = y
v r = r − y ∧ q0 = 1 + q ∧ x 0 = x ∧ y 0 = y
0
I We shall finish off with one more different loop example
= “ arithmetic ” I A loop whose termination is not pre-determined
(y ≤ r ∧ x = r + q ∗ y ⇒ x = r − q ∗ y ) ∧ x 0 = x ∧ y 0 = y I e.g., searching an array
v r 0 = r − y ∧ q0 = 1 + q ∧ x 0 = x ∧ y 0 = y I p :[ap 0 = w w ∈ a p 0 = 0]
= “A∧B⇒B”
true ∧ x 0 = x ∧ y 0 = y
v r 0 = r − y ∧ q0 = 1 + q ∧ x 0 = x ∧ y 0 = y
= “ hhprog-strengthenii ”
true

Searching an Array The Proof obligations
a : array 1 . . . N of T
w : T 1. find an appropriate invariant asinv
2. Prove ASSpec v p : asinv 0 ∧ ¬ (ap 0 6= w ∧ p 0 > 0)

p : N
3. Prove p :[asinv 0 ] v p := N
b p : ap 0 = w w ∈ a p 0 = 0

ASSpec =
4. Prove p :[ap 6= w ∧ p > 0 ∧ asinv ⇒ asinv 0 ] v p := p − 1
b p := N ; (ap 6= w ∧ p > 0) ∗ p := p − 1
ASProg = 5. For simplicity, we shall assume w 0 = w and a 0 = a
throughout, so we can ignore the frames.
ASSpec v ASProg
Array Stuff Picking the invariant
I We need to have some laws/definitions regarding array

membership: I An overview of a run of the algorithm looks like:
1 2 k k +1 N
w ∈a =
b ∃ k • 1 6 k 6 N ∧ ak = w 0
a1 a2 · · · ak ak +1 · · · aN
I We also want to talk about membership in a subset of an

array: I When p = k , we have come down from N ,
without finding w .
w ∈ a`...u b ∃ k • ` 6 k 6 u ∧ ak = w ,
= 16`6u6N I We also know that p will range from N down to 0
w ∈ a`...u = w = a` ∨ w ∈ a`+1...u , `6u
I We propose asinv = 0 6 p 6 N ∧ w ∈
/ ap+1...N
w ∈ a`...u = false, `>u

The Proof obligations (revisited) Uh-Oh ! Heuston, we have a problem …
I Clearly Forever ; P = Forever = P ; Forever , right?
1. We drop frames, assume a = a 0 and w = w 0 throughout (Remember,Forever is true ∗ skip.)
2. Prove I
Forever ; P
ASSpec = “ semantics of Forever ”
v 0 6 p0 6 N ∧ w ∈
/ ap 0 +1...N ∧ ¬ (ap 0 6= w ∧ p 0 > 0) true ; P
∃ Sm • true[Sm /S 0 ] ∧ P [Sm /S]
3. Prove 0 6 p 0 6 N ∧ w ∈
/ ap 0 +1...N v p := N
4. Prove ∃ Sm • true ∧ P [Sm /S]
ap 6= w ∧ p > 0 ∧ 0 6 p 6 N ∧ w ∈ / ap+1...N = “ hh∧-unitii ”
⇒ 0 6 p0 6 N ∧ w ∈ / ap0 0 +1...N ∃ Sm • P [Sm /S]
v p := p − 1 = “ hh∃-α-renameii ”
∃S • P
5. Left as exercise for the very keen ! I This doesn’t reduce to true as expected.
I We get an execution of P in an arbitrary starting state ! CS4003 Formal Methods
Wrong Choice ?
I Maybe we chose wrong earlier — should Forever be
miracle ?
I
miracle ; P
= “ defn. miracle ”
false ; P
∃ Sm • false[Sm /S 0 ] ∧ P [Sm /S]
∃ Sm • false ∧ P [Sm /S]
= “ hh∧-zeroii ”
∃ Sm • false
= “ hh∃-freeii, defn. miracle ”
miracle
I This works — but we ruled it out because it refines any

specification. CS4003 Formal Methods CS4003 Formal Methods
Class 16 Partial vs. Total Correctness
I We have a theory of partial correctness.

I Right now, a proof of
Spec v Prog
proves that Prog satisfies Spec, if it terminates.

I We want a theory of total correctness.
I In other words, a proof of
Spec v Prog
should prove that Prog terminates and satisfies Spec.
What’s the problem regarding termination ? When things go bad: Divergence
I A program execution is divergent if

I We can’t observe it ! I a serious error has occurred
I All our theory allows us to do is: I the error is unrecoverable
I observe variable values at the start (A) I future system behaviour is effectively unpredictable
I observe variable values at the end (B)
I relate these observations (C)
I In our theory to date, the predicate true (a.k.a. Forever )
captures such unpredictability
I For (B) and (C) it is necessary that the program terminates.
I In our theory so-far of (sequential) programming,
I In other words, a hidden (wrong!) assumption in our theory non-termination is an instance of divergence.
so far is that all programs terminate!
I Divergence is sometimes also referred to as “Instability”.

Observing (non-)Divergence Using ok and ok 0
I We shall extend our theory by allowing I Consider the specification: pre ⇒ Post
divergence/non-divergence to be an observable notion. I i.e. if pre holds at start, the Post relates start and end
(provided the program stops)
I We introduce a new variable : ok
I We shall now replace the above by:
ok = True program is non-divergent (a.k.a. “stable”) ok ∧ pre ⇒ ok 0 ∧ Post
ok = False program is diverging (a.k.a. “unstable”) I if started in a stable state ok
I Variable ok is not a program variable I and pre holds at start
I it is an auxiliary or model variable. I then, we end in a stable state ok 0 ,
I We assume no program has such a variable I and the relation Post holds of starting and ending states.
I ok ∈ /S I For sequential imperative programs, stability is termination
I As with program variable, we distinguish before- and after-
execution:
I Important: We assume that neither pre nor Post mention
ok or ok 0 .
I ok — stability/non-divergence at start
(i.e. of “previous” program) I Also, variables ok and ok 0 are added to the alphabet of
I ok 0 — stability/non-divergence at end every language construct.
The Meaning of ok ∧ pre ⇒ ok 0 ∧ Post Program Semantics using ok and ok 0
I We can now give our program language semantics in this

style:
Given this specification, then for any run of a satisfying
program: hhskip-def ii b ok ⇒ ok 0 ∧ S 0 = S
skip =
I If ok = False, i.e. we started in a divergent state
hh:=-def ii b ok ⇒ ok 0 ∧ x 0 = e ∧ S 0\x 0 = S\x
x := e =
(previous program diverged)
hh; -def ii P; Q =b ∃ Sm , okm •
and then any subsequent behavour was acceptable. P [Sm , okm /S 0 , ok 0 ]
∧ Q[Sm , okm /S, ok ]
I If pre = False, then anything was also allowed.
I If ok = pre = True, then ok 0 must have been true
(the program terminated without diverging), and relation
I The rules regarding alphabets are unchanged,
Post was satisfied. remembering that ok and ok 0 now belong.
I All other language constructs are defined as before, except
for the while-loop, which has some differences.
I Many of the laws remain unchanged.

(Some) Laws of Programming Laws requiring the new form
I If P has the (new) form

I The followings laws, seen before, all still hold.
ok ∧ pre ⇒ ok 0 ∧ Post
skip-altii
hh skipA = x :=A x
hh; -associi P ; (Q ; R) = (P ; Q) ; R then the following laws also hold:
hh:=-seq ii x := e ; x := f = x := f [e/x ]
hh:=-swapii x := e ; y := f = y := f [e/x ] ; x := e, hhskip-; -unit ii skip ; P = P
y 6 e hh; -skip-unit ii P ; skip = P
-trueii
hh P True Q = P
-falseii
hh P False Q = Q
hh-seq ii (P c Q) ; R = (P ; R) c (Q ; R)
I However, they are no longer true for arbitrary P .
I This occurs with laws involving assignment and skip whose
definitions have changed.
Proof of hhskip-; -unitii (Setup) Proof of hhskip-; -unitii (I)
skip; ok ∧ pre ⇒ ok 0 ∧ Post

I Goal skip ; P = P , = “ (new) hhskip-def ii ”
given new definition for skip ok ⇒ ok 0 ∧ S 0 = S; ok ∧ pre ⇒ ok 0 ∧ Post
and P of the form ok ∧ pre ⇒ ok 0 ∧ Post = “ (new) hh; -def ii ”
I Strategy: reduce lhs to rhs ∃ Sm , okm •
(ok ⇒ ok 0 ∧ S 0 = S)[Sm , okm /S 0 , ok 0 ]
skip; ok ∧ pre ⇒ ok 0 ∧ Post ∧ (ok ∧ pre ⇒ ok 0 ∧ Post )[Sm , okm /S, ok ]
= “ proof steps … ” = “ substitution, noting that ok , ok 0 6 pre, Post ”
ok ∧ pre ⇒ ok 0 ∧ Post ∃ Sm , okm •
(ok ⇒ okm ∧ Sm = S)
∧ (okm ∧ pre[Sm , /S] ⇒ ok 0 ∧ Post [Sm /S])
We have something of the form ∃ xs • (A ⇒ B) ∧ (C ⇒ D),

which we now transform.
Proof of hhskip-; -unitii (II) Proof of hhskip-; -unitii (III)
∃ xs • (A ⇒ B) ∧ (C ⇒ D)
= “ hh⇒-def ii ” I We shall now simplify each of the four components
∃ xs • (¬ A ∨ B) ∧ (¬ C ∨ D) obtained above
= “ Distributivity laws ”
I For convenience we give them labels (using “S;U” as short
∃ xs • ¬ A ∧ ¬ C ∨ ¬ A ∧ D ∨ B ∧ ¬ C ∨ B ∧ D
for hhskip-; -unit ii):
= “ hh∃-distr ii, several times ”
(∃ xs • ¬ A ∧ ¬ C) ∨ (∃ xs • ¬ A ∧ D) ∨ (S;U.1) ∃ Sm , okm • ¬ ok ∧ ¬ (okm ∧ pre[Sm , /S])
(∃ xs • B ∧ ¬ C) ∨ (∃ xs • B ∧ D) (S;U.2) ∃ Sm , okm • ¬ ok ∧ ok 0 ∧ Post [Sm /S]
(S;U.3) ∃ Sm , okm • okm ∧ Sm = S ∧ ¬ (okm ∧ pre[Sm , /S])
If we apply this to our proof we get
(S;U.4) ∃ Sm , okm • okm ∧ Sm = S ∧ ok 0 ∧ Post [Sm /S]
(∃ Sm , okm • ¬ ok ∧ ¬ (okm ∧ pre[Sm , /S])) ∨
(∃ Sm , okm • ¬ ok ∧ ok 0 ∧ Post [Sm /S]) ∨
(∃ Sm , okm • okm ∧ Sm = S ∧ ¬ (okm ∧ pre[Sm , /S])) ∨
(∃ Sm , okm • okm ∧ Sm = S ∧ ok 0 ∧ Post [Sm /S])
Proof of hhskip-; -unitii (IV, simplifying S;U.1) Proof of hhskip-; -unitii (V, simplifying S;U.2)
∃ Sm , okm • ¬ ok ∧ ¬ (okm ∧ pre[Sm , /S])

∃ Sm , okm • ¬ ok ∧ ok 0 ∧ Post [Sm /S]
= “ move quantifier in ”
= “ move quantifier in ”
¬ ok ∧ ∃ Sm , okm • ¬ (okm ∧ pre[Sm , /S])
¬ ok ∧ ok 0 ∧ ∃ Sm , okm • Post [Sm /S]
= “ witness: okm = False makes existential body true ”
= “ okm 6 Post ”
¬ ok ∧ true
¬ ok ∧ ok 0 ∧ ∃ Sm • Post [Sm /S]
= “ simplify ”
¬ ok

Proof of hhskip-; -unitii (VI, simplifying S;U.3) Proof of hhskip-; -unitii (VII, simplifying S;U.4)
∃ Sm , okm • okm ∧ Sm = S ∧ ¬ (okm ∧ pre[Sm , /S])

= “ de-Morgan ”
∃ Sm , okm • okm ∧ Sm = S ∧ (¬ okm ∨ ¬ pre[Sm , /S])
∃ Sm , okm • okm ∧ Sm = S ∧ ok 0 ∧ Post [Sm /S]
= “ distributivity ”
= “ one-point law ”
∃ Sm , okm • okm ∧ Sm = S ∧ ¬ okm
∃ okm • okm ∧ ok 0 ∧ Post
∨ okm ∧ Sm = S ∧ ¬ pre[Sm , /S]
= “ witness: okm = true ”
= “ contradiction ”
ok 0 ∧ Post
∃ Sm , okm • False ∨ okm ∧ Sm = S ∧ ¬ pre[Sm , /S]
= “ simplify, one-point ”
∃ okm • okm ∧ ¬ pre
= “ witness, okm = True ”
¬ pre
Proof of hhskip-; -unitii (VIII) “Witness” ?

I What is meant by the proof steps labelled “witness” ?
I Remember, ∃ x • P is true if any value of x exists that
We now merge our four simplifications, and continue: makes P true. Such a value is is a “witness” (to the truth of
the existential).
¬ ok ∨ ¬ ok ∧ ok 0 ∧ ∃ Sm • Post [Sm /S] ∨ ¬ pre ∨ ok 0 ∧ Post I We have a law that states: P [e/x ] ⇒ ∃ x • P
= “ hh∨-∧-absorbii ”
¬ ok ∨ ¬ pre ∨ ok 0 ∧ Post
I by hh⇒-joiniithis becomes P [e/x ] ∨ ∃ x • P ≡ ∃ x • P
= “ deMorgan ” I In effect, knowing that P [e/x ] is true, we can replace
¬ (ok ∧ pre) ∨ ok 0 ∧ Post ∃ x • P by true:
∃x • P
ok ∧ pre ⇒ ok 0 ∧ Post
= “ law above ”
P [e/x ] ∨ (∃ x • P )

= “ we know (can show) that P [e/x ] = true ”
true ∨ (∃ x • P )
= “ simplify ”
true
Frame Specifications with ok , ok 0 Frame Syntax change
I To fit our new theory, frames now have to explicitly

distinguish pre and post conditions:
I What is the semantics of a frame specification ~x :[S] in our
new theory ? ~x :[pre , Post ]
I In the old theory it was
b S ∧ S 0\x~0 = S\~x
~x :[S] = I We also need to note that if ok = False at the outset, then
we can modify any variables, not just those in the frame.
I The definition we get is therefore:
I How do we fit in ok , ok 0 ?
hhframe-def ii
b ok ∧ pre ⇒ ok 0 ∧ Post ∧ S 0\x~0 = S\~x
~x :[pre , Post ] =
Upgrading frame specs to new theory Refinement with ok , ok 0

I An old specification of the form
w :[P ] I How does adding in ok and ok 0 affect refinement laws ?

I e.g. (old rules)
where P is not an implication, becomes
hh prog-strengthenii P vP ∧Q
w :[true , P ] hh=-v-subst ii (S v P ∧ x = e)
≡ (S[e/x ] v P ∧ x = e)
hh v-:=ii x 0 = e v x := e
I An old specification of the form
w :[pre ⇒ Post ] I Can we use these as is ?

I Are there more useful variants of these ?
becomes
w :[pre , Post ]

Using hhprog-strengthenii with ok , ok 0 Using hh=-v-subst ii with ok , ok 0
hh prog-strengthenii : P vP ∧Q hh =-v-substii : (S v P ∧ x = e) ≡ (S[e/x ] v P ∧ x = e)
I The rule is still valid

I the rule is still valid, but again we now have those extra
I However we are less likely to be able to use it, as the
implications
P ∧ Q part will often occur on the rhs of an implication.
I The following variant is useful
I The following variant is useful
hh =-v-substii (S v p ⇒ Q ∧ x 0 = e)
hh prog-strengthenii (P ⇒ Q) v (P ⇒ Q ∧ R)
≡ (S[e/x 0 ] v p ⇒ Q ∧ x 0 = e)
Note here that p does not mention x 0 .

I In particular, often, P will be ok ∧ pre,
I As before, we often find that P will be ok ∧ pre,
and Q will be ok 0 ∧ Post .
and Q will be ok 0 ∧ Post .
Using hhv-:=ii with ok , ok 0 Revisiting Loop Refinement Example 2 (Hoare ’69)
hh v-:=ii : x0 = e v x := e Given
b r , q :[true , y 0 > r 0 ∧ x 0 = r 0 + y 0 ∗ q 0 ]
HSpec =
I The specification x 0 = e is no longer valid
— it does not mention ok and ok 0 in a valid way b r , q := x , 0 ; (y ≤ r ) ∗ (r , q := r − y , 1 + q)
HProg =
I We get useful variants if we change the specification to fit
our new theory: Prove
HSpec v HProg
hhv-:=ii ~ :[pre , x 0 = e] v x := e,
w ~
x ∈w
using new version of our theory, with ok and ok 0

Refining Hoare’69: revisited Refining Hoare’69: revisited (1)
We need to We must show HSpec v r , q :[true , hinv 0 ∧ y 0 > r 0 ]

1. find appropriate invariant hinv
I this is still x = r + q ∗ y , as before r , q :[true , y 0 > r 0 ∧ x 0 = r 0 + y 0 ∗ q 0 ]
v r , q :[true , x 0 = r 0 + q 0 ∗ y 0 ∧ y 0 > r 0 ]
2. show HSpec v r , q :[true , hinv 0 ∧ y 0 > r 0 ]
= “ hhv-reflii ”
3. show r , q :[true , hinv 0 ] v r , q := x , 0 true
4. show r , q :[y ≤ r ∧ hinv , hinv 0 ] v r , q := r − y , 1 + q
Refining Hoare’69: revisited (2) Refining Hoare’69: revisited (3)
We must show true :[r , q , hinv 0 ] v r , q := x , 0

We must show r , q :[y ≤ r ∧ hinv , hinv 0 ] v r , q := r − y , 1 + q
x0
r , q :[true , = + ∗r0 q0 y 0]
v r , q := x , 0
= “ frame-def , sim-:=-def i ”
hh ii hh i r , q :[y ≤ r ∧ x = r + q ∗ y , x 0 = r 0 + q 0 ∗ y 0 ]
ok ⇒ ok 0 ∧ x 0 = r 0 + q 0 ∗ y 0 ∧ x 0 = x ∧ y 0 = y v r , q := r − y , 1 + q
v ok ⇒ ok 0 ∧ r 0 = x ∧ q 0 = 0 ∧ x 0 = x ∧ y 0 = y = “ hhframe-def ii,hhsim-:=-def ii ”
= “ hh=-v-substii(new variant) ” ok ∧ y ≤ r ∧ x = r + q ∗ y
ok ⇒ ok 0 ∧ x = x + 0 ∗ y ∧ x 0 = x ∧ y 0 = y ⇒ ok 0 ∧ x 0 = r 0 + q 0 ∗ y 0 ∧ x 0 = x ∧ y 0 = y
v ok ⇒ ok 0 ∧ r 0 = x ∧ q 0 = 0 ∧ x 0 = x ∧ y 0 = y v ok ⇒ ok 0 ∧ r 0 = r − y ∧ q 0 = 1 + q ∧ x 0 = x ∧ y 0 = y
= “ arithmetic ” = “ hh=-v-substii(new variant) ”
ok ⇒ ok 0 ∧ true ∧ x 0 = x ∧ y 0 = y ok ∧ y ≤ r ∧ x = r + q ∗ y
v ok ⇒ ok 0 ∧ r 0 = x ∧ q 0 = 0 ∧ x 0 = x ∧ y 0 = y ⇒ ok 0 ∧ x = r − y + (q + 1) ∗ y ∧ x = x ∧ y = y
= “ hhprog-strengthenii(new variant) ” v ok ⇒ ok 0 ∧ r 0 = r − y ∧ q 0 = 1 + q ∧ x 0 = x ∧ y 0 = y
true

Refining Hoare’69: revisited (3 cont.) What was the point ?
ok ∧ y ≤ r ∧ x = r + q ∗ y
⇒ ok 0 ∧ x = r − y + (q + 1) ∗ y ∧ x = x ∧ y = y I We have proved that if the Hoare’69 program starts ok,
v ok ⇒ ok 0 ∧ r 0 = r − y ∧ q 0 = 1 + q ∧ x 0 = x ∧ y 0 = y then it terminates, establishing y 0 > r 0 ∧ x 0 = y 0 ∗ q 0 + r 0
= “ arithmetic, and e = e ≡ true ” I The proof of correctness was very similar to before
ok ∧ y ≤ r ∧ x = r + q ∗ y ⇒ ok 0 ∧ x = r + q ∗ y I We had to handle the extra complexity of
v ok ⇒ ok 0 ∧ r 0 = r − y ∧ q 0 = 1 + q ∧ x 0 = x ∧ y 0 = y ok ∧ . . . ⇒ ok 0 ∧ . . .
= “ (A ∧ B ⇒ C ∧ B) ≡ (A ∧ B ⇒ C) ” I What have we gained ?
ok ∧ y ≤ r ∧ x = r + q ∗ y ⇒ ok 0
v ok ⇒ ok 0 ∧ r 0 = r − y ∧ q 0 = 1 + q ∧ x 0 = x ∧ y 0 = y
I in fact, things aren’t just pointless, they are worse than
= “ (A ∧ B ⇒ C) v (A ⇒ C ∧ D) ” that !
true
(Exercise (voluntary): prove the last two laws used).
We have “proved” something False !! Hoare’69 can fail to terminate
Consider the following execution of the program:

I This is a cardinal error — it means our proof system is
unsound ! start x=3, y=0
I A proof system is unsound if we can use it to give a “proof” init x=3, y=0, r=3, q=0, y 6 r
of a property, that, by some other means, we know is in fact loop1 x=3, y=0, r=3, q=1, y 6 r
False . loop2 x=3, y=0, r=3, q=2, y 6 r
I Unsoundness means there is a mismatch between our loop3 x=3, y=0, r=3, q=3, y 6 r
proof method and our intended meaning for the predicates loop4 x=3, y=0, r=3, q=4, y 6 r
we are manipulating.
and so on …
I Hold on ! How do we know the property is False ?
So our proof technique is flawed.

Class 17 Fixing our Proof System
I So the addition of ok and ok 0 hasn’t completely solved our

need to reason about total correctness.
I The problem is that invariants tell us about loop
correctness, if they terminate.
I We need something extra to show
that loops do indeed terminate.
I We need to show progress towards termination,
by using a “variant”.
Loop Variants How does a variant guarantee termination ?
I as the loop starts V will have some value k0

I A Variant V for a loop c ∗ P , is: I after the 1st iteration it will have value k1 , with k1 < k0
I An expression over program variables. I after at most k0 iterations it will have value 0
I Has a finite numeric (integer) value
I Is always greater than or equal to zero I the loop must have terminated at this point (Why?)
I Always decreases by at least one on each loop iteration. I it is hasn’t terminated, then either
I The existence of an expression V with the above I the next iteration does not decrease V , or
properties proves that a loop terminates. I the value of V becomes negative
I in both cases, we do not have a variant property, so V
cannot have been a variant after all.

Revising our loop proof method Revisiting Hoare ’69 (one more time)
To refine ~v :[pre , Post ] by init ; c ∗ P we need to : I We need to determine a variant for Hoare’69
1. Find an appropriate invariant inv and variant V V = f (x , y , r , q)
2. Show that I Should be zero when loop terminates (r < y )
~v :[pre , Post ] v ~v :[pre , inv 0 ∧ ¬ c 0 ] r < y ⇒ f (x , y , r , q) = 0
3. show I Should decrease by at least once per iteration

~v :[pre , inv 0 ] v init r , q := r − y , q + 1
f (x , y , r − y , q + 1) < f (x , y , r , q)
4. show
~v :[c ∧ inv , inv 0 ∧ 0 6 V 0 < V ] v P
This is the key difference: we now have to show the variant I intuitively, the variant measures the
is reduced, but never below zero. “distance to go” towards termination.
A Variant for Hoare’69 Attempting to prove that r y is a variant (I)
I Rather than prove the whole thing, we focus on the variant

part
I We shall try the following variant:
r , q :[y 6 r , 0 6 r 0 y 0 < r y ] v r , q := r − y , q + 1
b r y
V =
where a b = a − b, if b 6 a, and equals zero otherwise. I We expand the lhs using hhframe-def ii:
I The proof obligation involving the variant is now
ok ∧ y 6 r ⇒ ok 0 ∧ 0 6 r 0 y 0 < r y ∧ x 0 = x ∧ y 0 = y
r,q : [y 6 r ∧ x = q ∗ y + r,
x 0 = q0 ∗ y 0 + r 0 ∧ 0 6 r 0 y 0 < r y ]
v r , q := r − y , q + 1 I We expand the rhs using hhsim-:=-def ii:
ok ⇒ ok 0 ∧ r 0 = r − y ∧ q 0 = q + 1 ∧ x 0 = x ∧ y 0 = y

Attempting to prove that r y is a variant (II) Revising Hoare ’69
I We use the rhs, and hh=-v-substii(new version) to transform We now know that there was a missing pre-condition: y > 0 !
the lhs: Given a revised specification
ok ∧ y 6 r ⇒ ok 0 ∧ 0 6 (r − y ) y < r y ∧ x = x ∧ y = y b r , q :[y > 0 , y 0 > r 0 ∧ x 0 = r 0 + y 0 ∗ q 0 ]

HSpec =
b r , q := x , 0 ; (y ≤ r ) ∗ (r , q := r − y , 1 + q)
HProg =
I Again we ignore the variables ok , x , and their dashed
We can now prove
variants and focus on the key variant part:
HSpec v HProg
y 6 r ⇒ 0 6 (r − y ) y < r y
by choosing invariant
I The first part 0 6 (r − y ) y is always true because inv b x =q ∗y +r

=
never returns a negative result
I For the second part, having y 6 r ensures that r − y is not and variant
negative, but we cannot guarantee that (r − y ) y < r y , V b r y
=
unless y > 0 !
within the new version of our theory, with ok and ok 0 . CS4003 Formal Methods
Debugging by Proof Formal Methods: recent Research
I (2000–2007, w/Jim Woodcock, Richard Corrigan)

I The Hoare’69 example wasn’t just about a pre-condition Formal Semantics for Handel-C
that we forgot/ignored. I (2008–2011, w/Jim Woodcock, Art O’Catháin)
I It showed another strength of reasoning by proof Formal Models of Flash Memory
I In attempting to prove what we believed was a correct I (2003–present, w/Jim Woodcock)
result, we uncovered an error in our initial assumptions. Using UTP to model synchronous Circus. (a.k.a.
I We discovered/calculated an important pre-condition “slotted-Circus”)
I (2007–2011, w/Paweł Gancarski)
I “95% of theorems are false”
Semantics of priority in slotted-Circus.
(John Rushby, PVS Theorem Prover, 1990s) I (2008–2012, w/Riccardo Bresciani)
Semantics of probabilistic programs in UTP

Formal Methods: current Research Circus, Flash
I (2003–present, w/Jim Woodcock)

Using UTP to model synchronous Circus. (a.k.a. I GC6 is a computing “grand-challenge” to develop libraries
“slotted-Circus”) of verified software, currently with a number of “pilot
I (2008–2013, w/Arshad Beg) projects”:
Formal translation from Circus to CSP I Mondex Smart Card (Natwest Bank)
I POSIX filestore (NASA JPL)
I (2007–∞, w/various)
Developing the U ·(TP )2 proof assistant I Circus is a formal language that combines imperative
programming (variables, assignment) with concurrent
I (2011–2014, w/Lero)
systems (message-passing)
Formal aspects of modelling software development
(see http://www.cs.york.ac.uk/circus/).
processes
I work between TCD and York has focussed on formal
I (2012–2013, w/David Sanán, Lero & ESA)
models of Flash Memory
Investigating techniques to formally model and verify a
secure partitioning microkernel.
Handel-C, slotted-Circus Kernel Verification
I ESA wants to put multiple applications on one computer

I Handel-C is the C language extended with
I currently each application (propulsion, telemetry,
message-passing and parallelism, that compiles directly to experiment, sensor array) has its own computing hardware
hardware (FPGAs). I want integrated modular avionics (IMA) to save weight
(see http://www.mentor.com/products/fpga/handel-c/)
I This requires a time-space partitioning kernel (hypervisor)
I it is based on notion of synchronously clocked time-slots.
to ensure non-interference between applications.
I “slotted-Circus” is a generic framework for adding discrete
time to Circus, suitable for modelling time-slot languages I We are doing a feasibility study:
like Handel-C. I Develop a Reference Specification.
I it is currently be worked on here at TCD, using UTP as the
I Formalise it (Using Isabelle/HOL).
semantic framework.
I Explore feasibility of verifying the correctness of actual
kernel code.

Formal Methods: recent Publications Mini-Exercise 5
2009, , P. Gancarski, J. Woodcock “State Visibility and
Q5 Given
Communication in Unifying Theories of Programming”, TASE 2009,
IEEE CS, pp47–54. n, f , x : N
2009, , P. Gancarski, “The Denotational Semantics of
fac(0) = 1
slotted-Circus”, FM 2009, LNCS 5850, pp451–466.
2010, , P. Gancarski, “Prioritized slotted-Circus”, ICTAC 2010, LNCS
fac(n) = n ∗ fac(n − 1), n>0
6255, pp91-105.
2010, , “Saoithin: A Theorem Prover for UTP”, UTP 2010, LNCS b f , x :[f 0 = fac(n)]
FSpec =
6445, pp137-156. b f , x := 1, 2 ; (x 6 n) ~ f , x := f ∗ x , x + 1
FProg =
2010, , “Denotational Semantics of Handel-C”, Formal Aspects of
Computing, 23, (2), 2011, p153 - 170. Using the partial correctness theory only:
2012, R. Bresciani, , “A probabilistic theory of designs based on 5.1 State clearly the proofs that need to be done.
distributions”, UTP 2012 LNCS 7681, pp105 - 123.
2012, Andrew Butterfield, “The Logic of UTP2”, UTP 2012 LNCS 5.2 Determine a suitable invariant.
7681, pp124 - 143. 5.3 Prove the statement that states that FSpec is
2012, R. Bresciani, , “A UTP semantics of pGCL as a homogeneous refined appropriately (Hint: one of the proofs in the
relation”, IFM 2012 LNCS 7321, pp191-205. answer to 5.1).
2013, R. Bresciani, , “From Distributions toProbabilistic Reactive
(due in next Friday week, 2pm, in class)
Programs”, ICTAC 2013, LNCS 8049, pp94 - 111.

Class 18 quite a lot of Handwaving !
I In the proofs so far, we have seen proof-step justifications

like
I “ arithmetic ”
I “ defn. of 6 ”
I “ 5 < x < 3 clearly impossible ”
I Such justifications are “hand-waving” and not formally
rigorous.
I How do we formalise these proof steps so they are part of
our formal game ?
“Theory” as an organising Principle A small theory of equality
It will prove useful to have a theory of equality

I In order to formalise arithmetic, say, we have to: I Syntax: e, f ∈ Expr ::= . . . | e1 = e2 | e1 6= e2
I extend our language syntax to cover arithmetic notation I Axioms:
I extend our axioms to cover the new notation
I build a collection of useful theorems from those axioms hh =-reflii e=e
I A “Theory ” is a collection of all the above pieces of
hh =-commii (e = f ) ≡ (f = e)
information, along with any necessary support material.
hh=-transii (e = f ) ∧ (f = g) ⇒ (e = g)
hh6=-def ii (e 6= f ) =
b ¬ (e = f )
I We shall briefly explore two theories:
I Arithmetic Equality is an equivalence relation (reflexive, symmetric,
I Lists
transitive)
I We will extend this theory as needed.

A Theory of Arithmetic (Syntax) Some axioms for arithmetic
We use m,n for numeric expressions
Axioms cover the basic building blocks
m, n ∈ Expr ::= ... I Zero is a natural number
hh0-is-Nii 0:N
| 0 | 1 | 2 | ... numeric constants
| succ n | pred n basic operations I If n is a natural number then so is the successor of n
| m+n |m−n additive operators hhsucc-is-Nii (n : N) ⇒ (succ n : N)
| m ∗ n | m/n | . . . multiplicative operators I The successor of a natural number is never zero
| mn . . . exponential operators hhsucc-not-0ii succ n 6= 0
We use r and s for atomic predicates over numeric values I Successor maps different values to different results
hhsucc-injectiveii (n = m) ≡ (succ n = succ m)
r , s ∈ Expr ::= ... I If P (0) is true, and whenever P (n) is true, we can show
| m = n | m 6= n equalities that P (n + 1) is true, them P (x ) is true for all x : N
| m<n|m>n comparisons (strict)
| m6n|m>n comparisons (non-strict) hh
N-inductionii P [0/x ] ∧ (∀ n • P [n/x ] ⇒ P [succ n/x ])
| n:T numeric type assertions ⇒ (∀ x | x : N • P )
(T ∈ N, Z, Q, R, C)
Some definitions for arithmetic Some theorems for arithmetic
0-+-def ii
hh 0+m =m hh+-0-unit ii n+0=n
hhsucc-+-def ii (succ n) + m = succ(n + m)
+-succ-commii
hh (succ n) + m = n + (succ m)
hh0-∗-def ii 0∗m =0 hh+-comm ii n+m =m+n
hhsucc-∗-def ii (succ n) ∗ m = m + (n ∗ m) hh+-associi ` + (m + n) = (` + m) + n
hhˆ-0-def ii m0 = 1 hh∗-comm ii n∗m =m∗n
hhˆ-succ-def ii m succ n = m ∗ m n hh∗-0-def ii
hh1-def ii
n∗0=0
1 = succ 0 hh∗-associi
hh2-def ii
` ∗ (m ∗ n) = (` ∗ m) ∗ n
2 = succ 1 hh∗-+-distr ii
hh3-def ii
` ∗ (m + n) = ` ∗ m + ` ∗ n
3 = succ 2
..
. 1+1-equals-2ii
hh 1+1=2
(Strictly speaking we need to model digit strings and their 2+2-equals-4ii
hh 2+2=4
valuations in order to do the last three definitions properly)

Proof of hh1+1-equals-2ii Proof of hh+-0-unit ii
Goal: 1 + 1 = 2
Strategy: reduce to true Goal: n + 0 = n
Strategy: ???
1+1=2 I A traditional proof of this uses induction, on n.
= “ hh1-def ii, hh2-def ii ”
I We show it is true for n = 0, i.e. that 0 + 0 = 0
(succ 0) + (succ 0) = succ 1
= “ hhsucc-+-def ii, hh1-def ii ” I We then assume it (i.e. n + 0 = n) and show it is true for
succ(0 + succ 0) = succ(succ 0) succ n,
= “ hh0-+-def ii ” succ n + 0 = succ n
succ(succ 0) = succ(succ 0)
= “ hh=-reflii ” I We have an induction principle (law hhN-inductionii), but how
true
do we use it in our proof system ?

Developing an Induction Strategy The Induction Strategy

I The induction law has the general form A ⇒ B
I Any such law suggests that if we want to show B to be true, I Assume an Induction Principle, i.e., a law of the form
then one such way is to prove A.
I Given A ⇒ B, the use of hh⇒-joinii transforms this to Q1 ∧ Q2 ∧ . . . Qn ⇒ ∀ x • P
B≡B∨A
I Now, consider our proof of B:
I In order to prove ∀ x • P , we now know it suffices to prove
B individually each of the Qi
= “ by alternate form of law above ” I So, given goal ∀ x | x : N • P an inductive proof allows us
B∨A to prove it via the following two sub-goals:
= “ given a proof of A ”
B ∨ true P [0/x ]
= “ hh∨-zeroii ” P [n/x ] ⇒ P [succ n/x ]
true
I So from a proof of A, we may construct a proof of B.

∀ and Theoremhood Proof of hh+-0-unit ii (again)
I Goal: n + 0 = n
I What does it mean to say that P is a theorem I Strategy: Induction on n using hhN-inductionii.
(or axiom/law) ?
I 1st sub-goal (a.k.a. “the base case”)
I It means that P evaluates to true, regardless of the
environment. 0+0 = 0
I This is the same as stating that [P ] is a theorem
Remember: [P ] is true only if P is true for all environments.
I We have quantified over nothing (P ), and everything ([P ]), I 2nd sub-goal (a.k.a. “the inductive step”)
but what about ∀ xs • P ?
∀ n • (n + 0 = n) ⇒ (succ n) + 0 = succ n
I If P is a theorem, then so is ∀ xs • P
I It turns out, regardless of what the xs are, that if any of the
following is a theorem, they all are: I However showing the above a theorem is the same as
showing the following to be a theorem
P (∀ xs • P ) [P ] I
(n + 0 = n) ⇒ (succ n) + 0 = succ n
Proof of hh+-0-unit ii (base case) Proof of hh+-0-unit ii (inductive step)
(sub-)Goal: (n + 0 = n) ⇒ (succ n) + 0 = succ n

(sub-)Strategy: assume antecedent hh+-0-def.hypii n + 0 = n,
(sub-)Goal: 0 + 0 = 0 Show consequent (reduce to true):
(sub-)Strategy: reduce lhs to rhs
(succ n) + 0 = succ n
0+0 = “ hhsucc-+-def ii ”
= “ hh+-0-unitii ” succ (n + 0) = succ n
0 = “ hh+-0-def.hypii ”
succ n = succ n
= “ hh=-reflii ”
true

Arithmetic Theory: summary
I Induction using hhN-inductionii is the main proof technique

for the laws of arithmetic.
I Most if not all of the laws shown are done this way
I For example, hh+-succ-commii can be proven by induction
on n, and using hh+-0-unitii to assist in the base-case.
Class 19

More Arithmetic Theory Hold on ! What about − and / ?
We can also define numeric ordering, and supply some

theorems
I Definitions
0-6-def ii
hh 06n
hh succ-6-def ii (succ n) 6 (succ m) ≡ n 6 m I I hoped you wouldn’t notice !
hh0-6-bottom ii ¬ (succ n 6 0) I Ok, lets have a look at some definitions/theorems
I What’s wrong with the simple life anyway ?
I Theorems
1-lessthan-2ii
hh 162
2-not-lessthan-1ii
hh ¬ (2 6 1)
hh+-increasesii n 6n+m
hh+-0-sameii n+m 6n ⇒m =0
Definitions and Theorems for Subtraction Proof of hh3-minus-2-is-1ii

Goal: 3 − 2 = 1
I Definitions: Strategy: reduce lhs to rhs3 .
−-0-def ii
hh n−0=n
3−2
hh−-succ-def ii (succ n) − (succ m) = n − m
= “ hh3-def ii, hh2-def ii ”
(succ 2) − (succ 1)
I Theorems2 : = “ hh−-succ-def ii ”
2−1
hh+-−-invii (m + n) − n = m = “ hh2-def ii, hh1-def ii ”
hh−-+-invii (m − n) + n = m (succ 1) − (succ 0)
hh−-decreasesii (m − n) 6 m = “ hh−-succ-def ii ”
1−0
hh 3-minus-2-is-1ii 3−2=1 = “ hh−-0-def ii ”
hh 1-minus-3-lt-1ii 1−361 1
I Let’s prove some of these.
2 CS4003 Formal Methods 3 CS4003 Formal Methods

probably ? works for theorems using = as well as ≡.
Proof of hh+-−-invii Proof of hh+-−-invii, Base Case
Goal: (m + 0) − 0 = m
Strategy: reduce lhs to rhs
I Goal: (m + n) − n = m
(m + 0) − 0
I Strategy: Induction on n
= “ hh+-0-unitii ”
I Base-Case: (m + 0) − 0 = m m−0
I Inductive Step: = “ hh−-0-def ii ”
((m + n) − n = m) ⇒ ((m + (succ n)) − (succ n) = m) m
Proof of hh+-−-invii, Inductive Step Proof of hh1-minus-3-lt-1ii

Goal: ((m + n) − n = m) ⇒ ((m + (succ n)) − (succ n) = m)
Strategy: assume antecedent Goal: 1 − 3 6 1
hh+-−-ind-hypii (m + n) − n = m Strategy: reduce to true
and reduce consequent lhs to rhs
1−361
(m + (succ n)) − (succ n) = “ hh1-def ii, hh3-def ii ”
= “ hh+-commii ” (succ 0) − (succ 2) 6 (succ 0)
((succ n) + m) − (succ n) = “ hh−-succ-def ii ”
= “ hhsucc-+-def ii ” 0 − 2 6 (succ 0)
succ(n + m) − (succ n) = “ ??? no law applies ??? ”
= “ hh−-succ-def ii ”
(n + m) − n
I It turns out that hh1-minus-3-lt-1ii is not a theorem!
= “ hh+-−-ind-hypii ”
m I Neither is its negation!
I Whazzup?


Definitions for Subtraction (reminder) Subtraction is partial
I Natural number subtraction as just described is partial :

I it is not defined for all values of its arguments
I in fact m − n is only defined if n 6 m
I Definitions:
I This means that the value of m − n is undefined if m < n
−-0-def ii
hh n−0=n I For example, hh−-+-invii as stated (m − n) + n = m)
hh−-succ-def ii (succ n) − (succ m) = n − m is not a theorem.
I If we revise it to n 6 m ⇒ ((m − n) + n = m),
then it becomes a theorem.
I The big question for us now is how do we handle the
issues of partiality and undefinedness?
Handling Undefinedness (I - make it go away) Problems with
I Our problems arose because subtraction is partially

defined I The “theorem” (m n) + n = m is still not true
I Why don’t we “totalise” it? (take m = 1, n = 2, for example)
I remember ?
I we still need that side-condition (n 6 m)
I To avoid confusion, we use to denote the totalised I In general we find that most laws using (−) requiring
version, which satisfies hh−-0-def ii, hh−-succ-def ii and side-conditions like n 6 m, still require these
side-conditions if we use instead.
hh−-totaliseii 0 m =0 I We get more problems with division
I What should m/0 be?
I Careful ! A wrong choice here allows us to prove that “black
I We can now easily prove that 1 3 6 1 is white”!
I Sorted ?

Problems with “Totalisation” Handling Undefinedness (II - live with it)
I Division’s partiality is a minor nuisance

I Just remember to add y 6= 0 whenever we see x /y
I However in computer science we have a more fundamental
I If a naturally partial function is to be totalised, be careful ! problem
I Laws may become unsound unless side-conditions are I Consider a possibly partial function f : N → N
added implemented faithfully as a program progF :
I If f (x ) is defined, then progF terminates on input x with the
I The side-conditions will frequently coincide with those that
right answer
determine when that function is defined. I If f (x ) is undefined, then progF may not terminate
I The question “is f defined on x ” is then equivalent to
solving the halting problem for progF
I The Halting Problem is undecidable — no algorithm can
ever solve it in all cases.
Consider this Handling Undefinedness (III - living with it)
I Consider the following code, (assuming n : N):
(n > 1) ~ n := n/2 even n n := (3 · n + 1)/2 I In the computer science domain, undefinedness is a fact of
life
I However, there is no universal agreement on how to handle
I Prove it refines the following (total-correctness)
it in formal logics.
specification: n > 0 ` n 0 = 1
I Some approaches:
I Done yet ? I Lots of definedness side-conditions
I If so, well done, take a bow, leave the class, go to MIT, I Giving “meanings” to undefined expressions
Stanford, Microsoft Research, wherever … I Triple-valued logics
I It is the so-called Collatz Conjecture (1937): it is known to
terminate for all n 6 260 (May 2011), but no proof that it
terminates for all n has been found.

Handling Undefinedness (IV - how we shall live with it) A Theory of Lists (Syntax)
I The use of a partial function/operator implies its We use σ, τ for lists (a.k.a. sequences)
definedness side-condition
e.g. the term (x + y ) − z implies a condition z 6 x + y . σ, τ ∈ T ∗ ::= ...
I When replacing a term by one that is equal, we shall | hi empty list
explicitly add in definedness conditions if the term that | x oo σ list construction
required it disappears. | hx1 , . . . xn i list enumeration
| head (σ) | tail (σ) list destruction (1)
I e.g consider predicate v = ((x + y ) − z ) − ((x + y ) − z )
and law e − e = 0 | front (σ) | last (σ) list destruction (2)
I The term has an implicit side-condition: z 6 x + y | σaτ list concatenation
I if we replace the term by 0 we get v = 0 | #σ list length
but we have lost information about the side-condition. | σ6τ list prefix relation
I We shall re-introduce the side-condition explicitly, so getting
v = 0 ∧ z 6 x + y.
Some axioms for lists Some definitions for lists (!) (??)
hhhead -def ii head (x oo σ) = x

hhtail -def ii tail (x oo σ) = σ
Axioms cover the basic building blocks
hhenumeration-def ii hx1 , x2 , . . . , xn i = x1 oo (x2 oo (. . . (xn oo hi)))
hhhi-is-T ∗ ii hi : T ∗ hha-hi-def ii hi a τ = τ
∗ x : T ∧ σ : T ∗ ⇒ (x oo σ) : T ∗
o-is-T ii
hho
hha-o o-def ii (x oo σ) a τ = x oo (σ a τ )
hhhi-not-o
oii hi =
6 x oo σ hh#-hi-def ii #hi = 0
o-injectiveii
hho (x = y ) ∧ (σ = τ ) ≡ (x oo σ) = (y oo τ ) hh#-o o-def ii #(x oo σ) = 1 + #σ
hhT ∗ -Inductionii P [hi/σ] ∧ (∀ v , τ • P [τ /σ] ⇒ P [(v oo τ )/σ]) hhfront -single-def ii front hx i = xs
⇒ (∀ σ | σ : T ∗ • P ) hhfront -o o-def ii front (x oo σ) = x oo front (σ)
hhlast -single-def ii last hx i = x
hhlast -o o-def ii last (x oo σ) = last (σ)
Note that head , tail , front and last are partial , defined only for
non-empty lists.
Some theorems for lists Proof of hha-r-unitii (I)
I Goal: σ a hi = σ
a-r-unit ii
hh σ a hi = σ I Strategy: induction over σ
hh#-a-morphism ii #(σ a τ ) = #σ + #τ b σ a hi = σ
Property P (σ) =
Base Case Show P (hi)
Proofs in class
Inductive Step Show P (τ ) ⇒ P (x oo τ )
Proof of hha-r-unitii (II) Proof of hha-r-unitii (III)
Inductive Step P (τ ) ⇒ P (x oo τ )
Goal: (τ a hi = τ ) ⇒ ((x oo τ ) a hi = x oo τ )
Strategy: assume LHS to show RHS
Base Case P (hi) ≡ (hi a hi = hi)
Strategy: reduce LHS to RHS
hhind-hypii τ a hi = τ
hi a hi (x oo τ ) a hi = x oo τ
= “ hha-hi-def ii ” = “ hha-oo-def ii ”
hi x oo (τ a hi) = x oo τ
= “ hhind-hypii ”
x o τ = x oo τ
o
= “ hh=-reflii ”
true

Some definitions for lists (!) (??) Gotcha !
front -single-def ii
hh front hx i = hi
hhfront -oo-def ii front (x oo σ) = x oo front (σ)
hhlast -single-def ii last hx i = x Explain in Class
hhlast -o
o-def ii last (x oo σ) = last (σ)
front and last are problematical, but not because they are
partial.
Ddefinitions for lists (Corrected, Safe) Lists Theory: summary
hhhead -def ii head (x oo σ) = x

hhtail -def ii tail (x oo σ) = σ
hhenumeration-def ii hx1 , x2 , . . . , xn i = x1 oo (x2 oo (. . . (xn oo hi)))
I Induction using hhT ∗ -Inductionii is the main proof technique
hha-hi-def ii hi a τ = τ
for the laws of lists.
hha-o o-def ii (x oo σ) a τ = x oo (σ a τ )
I Most if not all of the laws shown are done this way
hh#-hi-def ii #hi = 0
hh#-o #(x oo σ) = 1 + #σ
I Care needs to be taken when defining functions ‘by cases’
o-def ii
I Need to ensure that overlapping cases do not conflict.
hhfront -single-def ii front hx i = x
hhfront -o o-def ii front (x oo y oo σ) = x oo front (y oo σ)
hhlast -single-def ii last hx i = x
hhlast -o o-def ii last (x oo y oo σ) = last (y oo σ)
Note that head , tail , front and last are partial , defined only for
non-empty lists.
A Theory of Sets
Axioms:
¬ -in-{}ii
hh x ∈
/ {}
hhin-singletonii x ∈ {y } ≡ x = y
hhset-extensionalityii S = T ≡ ∀x • x ∈ S ≡ x ∈ T
Not a “traditional” axiomatization of set-theory !

Definitions:
hhin-∪ii x ∈ (S ∪ T ) ≡ x ∈ S ∨ x ∈ T
hhin-∩ii x ∈ (S ∩ T ) ≡ x ∈ S ∧ x ∈ T
hhin-\ii x ∈ (S \ T ) ≡ x ∈ S ∧ x ∈
/T
hhdef-⊆ii S ⊆ T ≡ ∀x • x ∈ S ⇒ x ∈ T
Class 20

Mini-Exercise 5 Tool Support
Q5 Given
n, f , x : N
fac(0) = 1
fac(n) = n ∗ fac(n − 1), n>0 I Formal Methods sounds like a good idea in theory
I What about in practise ?
b f , x :[f 0 = fac(n)]
FSpec =
b f , x := 1, 2 ; (x 6 n) ~ f , x := f ∗ x , x + 1
FProg = I Real-world problems result in lots of small, non-trivial proof,
each not quite the same as any other.
Using the partial correctness theory only: I Real-world use of formal methods requires tool support to
5.1 State clearly the proofs that need to be done. be practical.
5.2 Determine a suitable invariant.
5.3 Prove the statement that states that FSpec is
refined appropriately (Hint: one of the proofs in the
answer to 5.1).
(due in next Friday week, 2pm, in class)
Introducing U ·(TP )2 Getting and installing U ·(TP )2
I U ·(TP )2 is a theorem proving assistant designed for UTP I Follow link from Blackboard (“Tool Support” area)
I It is under development here at TCD I (Windows) Download the ZIP file
I A recet release suitable for CS4003 is now available I Copy everything into a new folder
I U ·(TP )2 0.97α8 I If using Unix/Mac OS X, you can build from source
I Open-source, has been built on Linux/Mac OS X; Binaries http://www.scss.tcd.ie/Andrew.Butterfield/Saoithin/
for Windows I requires Haskell, wxHaskell (good luck!)

Distribution Files Running U ·(TP )2
Binaries UTP2.exe
I Here we give examples on the Windows version
wxc-msw2.8.10-0.11.1.2.dll Un*x or OS X version will be much the same.
Saoithin-*.wav I To run, simply double-click on the .exe file
keep together I A MS-DOS console window appears, followed shortly by
the top-level window.
Documentation *.txt
I the screenshots shown here are from an earlier years
read !
version, but essentials are the same.
Workspaces Warnings
I Don’t mess with the files that appear in workspace folders

All your working files live in a workspace: I Only exit the application using the Quit menu item in the
I A directory holding your files top-level “Theories” Window.
I U ·(TP )2 allows you to give it a nickname I Avoid clicking the red X button in the top right corner of a
I You can generate many independent such workspaces window
(exception: do this to end the “Proof Key Shortcuts”
window)

U ·(TP )2 Top Level Window (first use) U ·(TP )2 Top-Level Theory Stack
I Related definitions, axioms and laws form a “Theory”

I U ·(TP )2 maintains a stack of theories, most general at the
bottom, most specific at the top
I Higher theories may depend on lower ones
I Theory 1 depends on Theory 2 if a proof in Theory 1 uses
a law from Theory 2
I Circular dependencies are not permitted.
U ·(TP )2 Top Level Window (theory loaded) U ·(TP )2 User-Interface
I We have the usual pull-down menus

I Double-clicking on some items will “open” or “activate”
them
I Right-clicking on some items or windows will bring up a
context-sensitive menu

U ·(TP )2 Theories U ·(TP )2 Top Level Window (TYPES in Theory)
I Theories consist of a series of tables:

LAWS Name → Law Laws
OBS Name → Type Observation Variables
LANGUAGE Theory-specific language constructs
PRECEDENCE Name → Type Binary Operator
Precedences
TYPEdef Name → Type Type Definitions
CONSTdef Name → Expr Constant Definitions
EXPRdef Name → Expr Expression Definitions
PREDdef Name → Pred Predicate Definitions
TYPES Var → Type Types
CONJ. Name → Law Conjectures
THEOREMS Name → Proof Theorems
U ·(TP )2 Top Level Window (Laws) U ·(TP )2 Top Level Window (Conjectures)

Proving Conjectures Proof Strategies
I To prove a conjecture, double-click on it Deduce Reduce Goal down to true.

I A proof window appears L2R Transform Goal LHS (of ≡) into RHS
I You have to pick a strategy for the proof. R2L Transform Goal RHS into LHS
I The goal predicate is shown with the current “focus” Red. Both Transform both LHS and RHS of Goal into same
underlined thing
I All prover commands work on the focus Law Reduce Transform named Law into Goal
I You move the focus with the arrow keys. Assume Assume Goal LHS (of ⇒) and prove RHS using
one of the first 4 strategies above.
Proof Actions Theorems
I The current focus in the goal is underlined, e.g. P ≡ Q

I Arrow keys allow the focus to be moved,
e.g., Down, then Left changes the above focus to P ≡ Q.
I Once a proof is complete it becomes a theorem and is
stored in the theorems table.
I Right-click brings up the laws that can be applied to the
focus
I The default is also to make the theorem a law, and to save
it to a file.
I Useful Key shortcuts I Right-clicking on a theory in the THEOREMS tab allows
(see Help menu in Proof window for more): you to save the proof in ASCII text or LaTeX form
u undoes the most recent proof step I (LATEX needs saoithin.sty — in installation zip)
p prints the current proof state to a text file
c switches between proof cases
(only applicable in certain strategies, like Red. Both)

Class 21

Design Lattice Design-Predicate Lattice
true ` false Miracle ¬ ok Miracle
true ` x 0 = 3 true ` x 0 = 6 ok ⇒ok 0 ∧x 0 =3 ok ⇒ok 0 ∧x 0 =6
true ` (x 0 = 3 ∨ x 0 = 6) v ok ⇒ok 0 ∧(x 0 =3∨x 0 =6) v
ok ⇒ok 0 ∧x 0 ∈{1...10}
true ` x 0 ∈ {1 . . . 10}
false ` true Chaos true Chaos
Theology of Computing
¬ ok Miracle
ok ⇒ok 0 ∧x 0 =3 ok ⇒ok 0 ∧x 0 =6
ok ⇒ok 0 ∧(x 0 =3∨x 0 =6) v
ok ⇒ok 0 ∧x 0 ∈{1...10}
true Chaos

Class 22 “Design-hood”?
I Consider the following:

¬ ok ∧ ok 0 ∧ x 0 = x + 1 ∧ S 0\x0 = S\x
I When started in a divergent state, we terminate, increment
x , and leave other variables unchanged.
I Clearly not possible for a real program
¬ ok means ‘not properly/yet started’)
I Is this predicate a design?
I Can we re-write it in the form ok ∧ P ⇒ ok 0 ∧ Q?
I if not, how can “prove” it is not a design?
When is a predicate a Design? Healthiness Conditions
I Our theory of total correctness is based on the notion of I We view designs as “healthy” predicates,
designs, i.e., those that describe real programs and specifications.
i.e. predicates of the form: ok ∧ P ⇒ ok 0 ∧ Q I We shall introduce “healthiness conditions” that test a
(or P ` Q) predicate to see if it is healthy.
I However, given an arbitrary predicate, how do we I These conditions capture key intuitions about how real
determine if it is a design ? programs behave
I Clearly one way is to transform it into the above form. I Some will be mandatory — all programs and specifications
I This can be quite difficult to do in some cases. will satisfy these.
I Is there an easier way? I Some will be optional — these characterise particulary
I Also, just what is it that characterises designs in any case? well-behaved programs

Healthiness Condition 1 (H1) H1 Example (1)
H1 P = (ok ⇒ P )
What about ¬ ok ∧ ok 0 ∧ x 0 = x + 1 ∧ S 0\x 0 = S\x ?
I P only ‘takes effect’ when ok is true — i.e. program has ok ⇒ ¬ ok ∧ ok 0 ∧ x 0 = x + 1 ∧ S 0\x 0 = S\x
started = “ hh⇒-def ii ”
I When ¬ ok , then P says nothing ¬ ok ∨ ¬ ok ∧ ok 0 ∧ x 0 = x + 1 ∧ S 0\x 0 = S\x
I H1 above is equivalent to satisfying both of the following
¬ ok
laws:
hhskip-; -unit ii skip ; P = P
So it is not H1-healthy
hh; -L-Zeroii Forever ; D = Forever
I Any design P ` Q satisfies the three laws above.
H1 Example (2) H1 Example (3)
What about x := e? What about P ` Q?

ok ⇒ x := e ok ⇒ (P ` Q)
= “ hh:=-def ii ” = “ hh`-def ii ”
ok ⇒ (ok ⇒ ok 0 ∧ x 0 = e ∧ S 0\x 0 = S\x ) ok ⇒ (ok ∧ P ⇒ ok 0 ∧ Q
= “ hhshuntingii ” = “ hhshuntingii ”
ok ∧ ok ⇒ ok 0 ∧ x 0 = e ∧ S 0\x 0 = S\x ok ∧ ok ∧ P ⇒ ok 0 ∧ Q
= “ hh∧-idemii ” = “ hh∧-idemii ”
ok ⇒ ok 0 ∧ x 0 = e ∧ S 0\x 0 = S\x ok ∧ P ⇒ ok 0 ∧ Q
= “ hh:=-def ii ” = “ hh`-def ii ”
x := e P `Q
So x := e is H1-healthy So any design is H1-healthy

Healthiness Condition 2 (H2) H2 Example (1)
H2 [P [False/ok 0 ] ⇒ P [True/ok 0 ]]
Again, lets try ¬ ok ∧ ok 0 ∧ x 0 = x + 1 ∧ S 0\x 0 = S\x .
I No specification can require non-termination.
(¬ ok ∧ ok 0 ∧ x 0 = x + 1 ∧ S 0\x 0 = S\x )[False/ok 0 ]
I if P is true when ok 0 is false, then it must also be true if ok 0
⇒ (¬ ok ∧ ok 0 ∧ x 0 = x + 1 ∧ S 0\x 0 = S\x )[True/ok 0 ]
is true.
I We introduce the following abbreviation: (¬ ok ∧ False ∧ x 0 = x + 1 ∧ S 0\x 0 = S\x )
Pb b P [b/ok 0 ]
= ⇒ (¬ ok ∧ True ∧ x 0 = x + 1 ∧ S 0\x 0 = S\x )
= “ simplify ”
False ⇒ (¬ ok ∧ x 0 = x + 1 ∧ S 0\x 0 = S\x )
I so H2 becomes [P f ⇒ P t ] = “ hhGS3.75ii ”
(with f and t the obvious abbreviations for False and True. true
I It is equivalent to satisfying the following law:
So it is H2-healthy !
hh ; -H2-R-Unitii P; J = P
hhJ -def ii J=b (ok ⇒ ok 0 ) ∧ S 0 = S
H2 Example (2) H2 Example (3)

Finally, what about P ` Q,
Now, try ok ⇒ ¬ ok 0 (i.e requiring non-termination). or ok ∧ P ⇒ ok 0 ∧ Q ?
(ok ⇒ ¬ ok 0 )[False/ok 0 ] ⇒ (ok ⇒ ¬ ok 0 )[True/ok 0 ] (ok ∧ P ⇒ ok 0 ∧ Q)f ⇒ (ok ∧ P ⇒ ok 0 ∧ Q)t

= “ substitution ” = “ substitution, noting P and Q do not mention ok 0 ”
(ok ⇒ ¬ False) ⇒ (ok ⇒ ¬ True) (ok ∧ P ⇒ False ∧ Q) ⇒ (ok ∧ P ⇒ True ∧ Q)
= “ simplify ” = “ simplify ”
(ok ⇒ True) ⇒ (ok ⇒ False) (ok ∧ P ⇒ False) ⇒ (ok ∧ P ⇒ Q)
= “ hh⇒-r-zeroii, hh¬ -def ii ” = “ hh¬ -def ii ”
True ⇒ ¬ ok ¬ (ok ∧ P ) ⇒ (ok ∧ P ⇒ Q)
= “ hh⇒-l-unitii ” = “ hh⇒-def ii, hh¬ -involii ”
¬ ok ok ∧ P ∨ ¬ (ok ∧ P ) ∨ Q
= “ hhexcluded-middleii, simplify ”
So it is not H2-healthy true
So designs are H2-healthy

Designs are H1,H2 are Designs are H1,H2 are … Healthiness Condition 3 (H3)
I Any Design satisfies both H1 and H2

H3 P = P ; skip
I Any predicate satisfying both H1 and H2 is a Design
I So H1 and H2 are our mandatory healthiness conditions.
I All programs and specifications (incl. Chaos and miracle) I Running skip afterwards makes no difference
satisfy these. I Not true of all Designs (which fail this?)
I Two more conditions (H3, H4) characterise more I If fails for a design P ` Q iff P is not a condition (i.e. has
“well-behaved” predicates. dashed variables).
H3 Example (1) H3 Example (1, cont.)
I Let’s try x 0 = 2 ` true

expands to ok ∧ x 0 = 2 ⇒ ok 0 ok ∧ x 0 = 2 ⇒ ok 0 ; skip
“If started, and x ends up equal to 2, then I terminate” = “ hhskip-def ii ”
I ok ∧ x 0 = 2 ⇒ ok 0 ; ok ⇒ ok 0 ∧ S 0 = S
ok ∧ x 0 = 2 ⇒ ok 0 = “ hh⇒-def ii, hh; -def ii, 6-way (!) simplification ”
= “ hh⇒-def ii, hhdeMorganii ” ¬ ok ∨ (∃ xm , okm • ¬ (xm = 2) ∧ ¬ okm ) ∨ ok 0 ∨ (. . .)
¬ ok ∨ x 0 6= 2 ∨ ok 0 = “ witness, xm = 1, okm = False ”
= “ hh⇒-def ii ” ¬ ok ∨ true ∨ ok 0 ∨ (. . .)
ok ⇒ x 0 6= 2 ∨ ok 0 = “ hh∨-zeroii ”
“If started, either x ends up different from 2, or I terminate” true
I It’s a design, so H1,H2-healthy Not equal to ok ∧ x 0 = 2 ⇒ ok 0 , so not H3-healthy

H3 Example (2) Healthiness Condition 4 (H4)
Now, try miracle, a.k.a. ¬ ok
¬ ok ; skip
= “ hhskip-def ii, hh⇒-def ii ”
¬ ok ; ¬ ok ∨ ok 0 ∧ S 0 = S H4 P ; true = true
= “ hh; -def ii,substitution ”
∃ okm , Sm • ¬ ok ∧ (¬ okm ∨ ok 0 ∧ S 0 = Sm ) I A H4-healthy program cannot force termination of what
= “ hh∧-∨-distr ii, hh∃-distr ii ”
runs afterward.
(∃ okm , Sm • ¬ ok ∧ ¬ okm ) ∨
(∃ okm , Sm • ¬ ok ∧ ok 0 ∧ S 0 = Sm )
I All real programs satisfy this property.
= “ simplify ” I H4 states that a predicate is Feasible.
¬ ok ∨ ¬ ok ∧ ok 0 There is a program that has this behaviour.
¬ ok
So miracle is H3-healthy
H4 Example (1) Healthiness: Summary

I We have 2 mandatory healthiness conditions for designs
What about miracle? H1 P = ok ⇒ P

It satisfies any specification? (skip; P = P ) ∧ (true; P = true)
Is it feasible? H2 [P f ⇒ P t ]
P = P; J
miracle; true
= “ miracle is ¬ ok ”
¬ ok ; true I We have 2 additional conditions capturing better behaviour
= “ hh; -def ii, substitution ”
∃ okm , Sm • ¬ ok ∧ true H3 P = P ; skip
= “ drop quantifiers, simplify ” H4 P ; true = true
¬ ok
I If P and Q are Hi-healthy (i ∈ 1 . . . 4), then so are
It is not feasible, thankfully !
P; Q P uQ P c Q c ~P

Design Semantics of true ~ skip Choosing fixpoint for meaning of true ~ skip
I Any design satisfies the loop-unrolling law for true ~ skip

I As before, we try to find something that satisfies the
(a.k.a. Forever ).
loop-unrolling law for Forever , namely:
I We have a good reason to want the least such design,
X = skip; X namely false ` true (which reduces to true).
Forever -def ii
hh Forever =
b true
I However, now we restrict ourselves to designs only, and
use the design definition for skip
I Does it give us the desired laws ?
I Under what conditions does design D(= P ` Q) satisfy the
above law ? hh; -L-Zeroii Forever ; D = Forever
I All designs satisfy it ! hh; -R-Zeroii D; Forever = Forever
It is just law hhskip-; -unitii, already proven.
Here D are designs
Proof of hh; -L-Zeroii Proof of hh; -L-Zeroii, cont.
Goal: Forever ; D = Forever

Strategy: reduce rhs to lhs
Forever ; D ∃ Sm , okm • ¬ okm ∨ ¬ P [Sm /S] ∨ ok 0 ∧ Q[Sm /S]

= “ hhForever -def ii, D = P ` Q ” = “ shrink ∃ scope ”
true; P ` Q (∃ okm • ¬ okm ) ∨ (∃ Sm • ¬ P [Sm /S] ∨ ok 0 ∧ Q[Sm /S])
= “ hh`-def ii ” = “ witness, okm = False ”
true; ok ∧ P ⇒ ok 0 ∧ Q true ∨ (∃ Sm • ¬ P [Sm /S] ∨ ok 0 ∧ Q[Sm /S])
= “ hh; -def ii, with substitution ” = “ simplify ”
∃ Sm , okm • true ∧ (okm ∧ P [Sm /S] ⇒ ok 0 ∧ Q[Sm /S]) true
= “ simplify, hh⇒-def ii ” = “ hhForever -def ii ”
∃ Sm , okm • ¬ (okm ∧ P [Sm /S]) ∨ ok 0 ∧ Q[Sm /S] Forever
= “ hhdeMorganii ”
∃ Sm , okm • ¬ okm ∨ ¬ P [Sm /S] ∨ ok 0 ∧ Q[Sm /S]

Proof of hh; -R-Zeroii Design Coda
I Goal: D; Forever = Forever

I You have been introduced to Predicate Calculus as a
Formal Language “game”.
I Strategy: reduce rhs to lhs
I You have seen how the language can be extended so that
I
D; Forever you can play with the meanings of programs.
= “ hhForever -def ii ” I You have seen how the key concepts of loop invariant and
D; true variant respectively allow you to reason formally about the
correctness and termination of while-loops.
I But stating this equals Forever , i.e. true, is the same as I You have (just) encountered the notion of a Design,
stating that D is H4-healthy (feasible)! namely a predicate describing a specification or program
I We need to revise our law: as an explicit pre-/post-pair, with termination handled
implicity.
; -R-Zeroii
hh D is H4 ⇒ (D; Forever = Forever ) I We have seen that Designs, and interesting sub-classes
can be characterised as healthiness conditions on
predicates.

Class 23 Using U ·(TP )2
I This class is a live demo of the U ·(TP )2 proof assistant

I Uses a theory based on the Gries & Schneider book “A
Logical Approach to Discrete Math”, Springer, 1995.
I Some proofs will be done in class.
I More will be left as an exercise
See Blackboard for details

Class 24 Formalising Healthiness
I We want to formalise our notion of healthiness

I Remember, the following are our conditions
H1 P = ok ⇒ P
H2 P = P; J
H3 P = P ; skip
H4 P ; true = true
I They all (except H4) have the same form: P = H(P )

where H describes the appropriate “function” of P .
I We shall now formalise this notion
Formalising H1 Higher-Order Logic
I We shall define a function that takes a predicate as I Up to now, we have been using “First-Order predicate
parameter, and returns True if the predicate is H1-healthy: calculus”
I we have built predicates from basic parts using fixed
b P = (ok ⇒ P )
isH1(P ) = operators.
I Any functions have only existed inside the expression
(sub-)language
I We refine this further by introducing another function that I All quantification variables have been limited to expression
given a predicate returns an appropriately modified variables only
predicate I Now we are moving towards “Higher-Order Logic”
mkH1(P ) = b ok ⇒ P I We are introducing predicates about predicates (e.g. isH1)
isH1(P ) = b P = mkH1(P ) I We are introducing functions
that transform predicates (e.g. mkH1)
I UTP also allows quantifier variables
I What we have done is to start a new formal game to range over predicates
altogether !

2nd-Order Predicates Predicate Transformers
I A first-order predicate P is a function over environment
variables, returning True or False:
I A predicate-transformer F is a function over predicates,
[[P ]] : Env → B returning a predicate as a result:
[[F]] : Pred → Pred

I A second-order predicate P is a function from predicates to
True or False:
[[P]] : Pred → B I We can expand this also as
[[F]] : (Env → B) → (Env → B)

I We can expand this as:
[[P]] : (Env → B) → B I Function mkH1 is a predicate transformer
I So isH1 is just such a 2nd-order predicate.

Changing the Game (I) Changing the Game (II)
I Given H(P ) =
b body , we have a new law:
I We add a new category to our language: that of a
higher-order definition H (MyPred ) = body [MyPred /P ]
P , Q, R, S ∈ PVar predicate (meta-)variables
Where we now have substitution notation extended to allow
H, F ∈ HOF higher order functions
predicates to replace predicate variables.
HOFDef ::= H(P ) =b body HOF definition
I The addition of higher-order functions
(i.e. those that take predicates as arguments) gives
I We extend our notion of predicate to allow the application “monadic 2nd-order logic”
of a HOF to a predicate argument I If we also allow quantification over predicates
P ∈ Pred ::= . . . | H(P )
Pred ::= . . . | ∀ P • H(P )
we get “full 2nd-order logic”

2nd-order Logic Revisiting Healthiness
I We can now formalise our healthiness conditions as

I 2nd-order logic is strictly more powerful than 1st-order
follows:
I When quantifying over a predicate, it is interpreted as a
function from the environment to boolean mkH1(P ) =
b ok ⇒ P
I so mkH2(P ) =
b P; J
∀ P • H(P ) mkH3(P ) =
b P ; skip
is interpreted as meaning : isHi(P ) =
b P = mkHi(P ), i ∈ 1, 2, 3
“ for all functions F : Env → B, the predicate isH4(P ) =
b P ; true = true
H(F ) evaluates to true in any environment ”
I Apart from H4, we have the same pattern:
I UTP is based on full 2nd-order logic
I a predicate transformer mkH
I needed to treat recursion properly I a predicate condition isH, defined in terms of the former
I needed to reason about healthiness.
I We shall take a closer look at mkH.
The Nature of mkH A Notational Convention (obvious, yet confusing!)
I Consider the application mkH(P)

I We can interpret mkH as a “healthifying” function
(i.e. it makes predicates healthy) I We have definitions provided for mkH
I What if P is already healthy? I We define isH as P = mkH(P )
I Then it satisifes isH, which says P = mkH(P )
I So mkH should not change an already healthy predicate
I It is standard practise in the UTP literature to use H to
denote both of these functions
I We are led to the following requirement for any “healthifier”
mkH:
I Which of mkH or isH is meant can (usually) be deduced
mkH(mkH(P )) = mkH(P ) from context
mkH ◦ mkH = mkH I We shall adopt this convention from now on.
i.e. all such HOFs must be idempotent .
I Once a predicate has been “made healthy”, then further
attempts to do so should bring about no further change.

H1 is idempotent H2 is idempotent
We want to show that H1 ◦ H1 = H1

Reduce Lhs to Rhs We want to show that H2 ◦ H2 = H2
Reduce Lhs to Rhs
H1(H1(P ))
= “ defn. H1 (a.k.a mkH1) ” H2(H2(P ))
ok ⇒ (ok ⇒ P ) = “ defn. H2 ”
= “ hh⇒-def ii ” (P ; J ); J
¬ ok ∨ ¬ ok ∨ P = “ hh; -associi ”
= “ hh∨-idemii ” P ; (J ; J )
¬ ok ∨ P = “ Lemma: J ; J = J ”
= “ hh⇒-def ii ” P; J
ok ⇒ P = “ defn. H2 ”
= “ defn. H1 ” H2(P )
H1(P )
Lemma Proof (I) Lemma Proof (II)

Goal: J ; J = J
S 0 = S ∧ (∃ okm •
Reduce lhs to rhs
¬ ok ∧ ¬ okm ∨ ¬ ok ∧ ok 0
J; J ∨ okm ∧ ¬ okm ∨ okm ∧ ok 0 )
= “ defn. J ” = “ hhcontradictionii, shrink scope, simplify ”
0
S = S ∧ (¬ ok ∧ (∃ okm • ¬ okm )
((ok ⇒ ok 0 ) ∧ S 0 = S); ((ok ⇒ ok 0 ) ∧ S 0 = S)
= “ hh⇒-def ii, hh; -def ii, substitution ” ∨ ¬ ok ∧ ok 0
∃ okm , Sn • ∨ (∃ okm • ¬ okm ) ∧ ok 0 )
(¬ ok ∨ okm ) ∧ Sm = S ∧ (¬ okm ∨ ok 0 ) ∧ S 0 = Sm = “ witness, simplify ”
= “ hh∃-1pt ii, Sm = S ” S 0 = S ∧ (¬ ok ∨ ¬ ok ∧ ok 0 ∨ ok 0 )
∃ okm • (¬ ok ∨ okm ) ∧ (¬ okm ∨ ok 0 ) ∧ S 0 = S = “ hh∨-∧-absorbii ”
= “ shrink scope, hh∧-∨-distr ii, hh∨-∧-distr ii ” S = S ∧ (¬ ok ∨ ok 0 )
0
0
S = S ∧ (∃ okm • = “ hh⇒-def ii, ”
¬ ok ∧ ¬ okm ∨ ¬ ok ∧ ok 0 S = S ∧ (ok ⇒ ok 0 )
0
∨ okm ∧ ¬ okm ∨ okm ∧ ok 0 ) = “ defn. J ”

J
Aside: the (un-)Healthiness of J H3 is idempotent
We want to show that H3 ◦ H3 = H3

I We have just seen that J ; J = J , i.e. that J is H2-healthy Reduce Lhs to Rhs
I What about H1(J ) and H3(J )? H3(H3(P ))
I Careful calculation shows = “ defn. H3 ”
(P ; skip); skip
H1(J ) = ok ⇒ J = skip = “ hh; -associi ”
H3(J ) = J ; skip = skip P ; (skip; skip)
= “ hhskip-; -unit ii, with P = skip ”
I So J is not H1 or H3, and attempts to “healthify” it using P ; skip
either H1 or H3 turn it into skip = “ defn. H3 ”
H3(P )
Designs: a final comment Other Useful Properties of Healthiness
I Given D which we know is a design

(because we have shown it to be H1 and H2) I We require healthiness transformers to be idempotent
can we write it in the form P ` Q I Another useful property is having independence of
I Can we determine P and Q, given D ? healthiness conditions:
I Yes I the order in which most healthiness transformers are
I If D is H1- and H2-healthy, then applied is immaterial.
I e.g.
D = (¬ D f ` D t ) H1 ◦ H2 = H2 ◦ H1
H1 ◦ H3 = H3 ◦ H1
H3 ◦ H2 = H2 ◦ H3
I The precondition is those situations that do not lead to
ok 0 = False, i.e. ¬ D[False/ok 0 ] We say that H1, H2 and H3 “commute”.
I The post condition is those situations that end with
ok 0 = True, i.e. D[True/ok 0 ]

Why Commuting is good Proof that H1 and H2 commute
I Commuting healthiness is very convenient.

Knowing P is both H1 and H2 allows us to replace it by
either H1(P ) or H2(P ) in a proof.
I If Ha and Hb (say) don’t commute, then Ha(Hb(P )) and I Goal: H1 ◦ H2 = H2 ◦ H1
Hb(Ha(P )) are different. I alternatively
I If P is (Ha ◦ Hb)-healthy,
then we can replace P in a proof by H1(H2(P )) = H2(H1(P ))
Ha(P ) or Ha(Hb(P ))
I Strategy: reduce both sides to same
but not by
Hb(P ).
I Why/Why not? (do in class)
Proof that H1 and H2 commute (LHS) Proof that H1 and H2 commute (RHS)
H2(H1(P ))
= “ defns., H1, H2 ”
H1(H2(P ))
(ok ⇒ P ); J
= “ defns., H1, H2 ”
= “ hh∨-; -distr ii (see below) ”
ok ⇒ (P ; J )
(¬ ok ; J ) ∨ (P ; J )
= “ defn. H2 ”
¬ ok ∨ (P ; J )
H2(¬ ok ) ∨ (P ; J )
= “ ¬ ok (a.k.a. miracle) is a design and hence H2 ”

H2(¬ ok ) ∨ (P ; J )
We have used hh∨-; -distr ii: (P ∨ Q); R ≡ (P ; R) ∨ (Q; R)
whose proof is left as a (voluntary) exercise.

Class 25 Monotonicity of HOFs
I We have an ordering on predicates based on refinement
I If P refines S, then we view S as having less information
than P , and we write S v P .
I We see Chaos, the “whatever” specification as least by this
ordering
I We view miracle, the “satisfy-anything” (infeasible) program
as top-most
I We now introduce the notion of monotonicity for HOFs
I HOF F is monotonic if, forall predicates P and Q
(P v Q) ⇒ (F(P ) v F(Q))
I Note how monotonicity can be defined as a 2nd-order

predicate!
I This property states that if F is monotonic then refining its
argument refines its result.
Program Language Constructs as HOFs 2-place HOFs
I With 2-place HOFs we can define the other language

I We can re-cast much of our program language constructs constructs
as HOFs. I
I For example, consider the while loop: c ~ P SEQ(P , Q) =b P; Q
I We can consider this a function of P (how?) b P c Q
CONDc (P , Q) =
I Simple, define
I We say a 2-place HOF F( , ) is:
WLOOPc (P ) =
b c ~P I Monotonic in 1st arg. if P v Q ⇒ F(P , R) v F(Q, R)
I Monotonic in 2nd arg. if P v Q ⇒ F(R, P ) v F(R, Q)
I F( , ) is simply Monotonic, if it is monotonic in both
I It turns out that WLOOPc is monotonic
arguments
I So if P v Q then
I Both SEQ and CONDc are (simply) Monotonic
WLOOPc (P ) v WLOOPc (Q),
i.e. c ~ P v c ~ Q I The notion of monotonicity extends to n-place HOFs in the
obvious way.

Monotonicity preserved by composition Testing for Monotonicity
I There are two ways to test F to see if it is monotonic.

I The hard (direct) way:
If F and G are monotonic, then so is F ◦ G Prove the relevant (2nd-order) theorem:
P vQ ∀ P , Q • (P v Q) ⇒ (F(P ) v F(Q))
⇒ “ G is monotonic ”
G(P ) v G(Q)
⇒ “ F is monotonic ” I An easier (indirect way):
F(G(P )) v F(G(Q)) Consider the definition of F, which will look something like:
This generalises to n-place HOFs as well F(P ) =

b a predicate mentioning P somewhere
I By analysing the “predicate mentioning P ” we can

determine (to a great extent) if F is monotonic.
Monotonicity Analysis Anti-Monotonicity
I F(P ) is monotonic if every occurrence of P in its definition

is at a “positive” location.
I A location is positive if we pass down through an even
number of negations to get to it. I HOF F is anti-monotonic if, forall predicates P and Q
I a negation here is either
(i) going through an application of ¬ , or (P v Q) ⇒ (F(Q) v F(P ))
(ii) going down the lhs of ⇒ (why?)
I A location is negative if we pass down through an odd
number of negations to get to it. I F(P ) is anti-monotonic if every occurrence of P is in a
I If P occurs in both positive and negative locations, then its negative location.
occurrences are said to be mixed .
I passing through either argument of ≡ results in a mixed
occurrence.
I U ·(TP )2 keeps track of a location’s polarity as focus is
moved into a predicate.
Monotonicity Example I Monotonicity Example II
b P ∧ (∃ x • Q ⇒ P ) monotonic?
Is F(P ) = b P ∧ (∃ x • Q ⇒ P ) monotonic?
Is F(Q) =
P ∧ (∃ x • Q ⇒ P ) P ∧ (∃ x • Q ⇒ P )
“ mark occurrence polarity ” “ mark occurrence polarity ”
P + ∧ (∃ x • Q − ⇒ P + )+ P + ∧ (∃ x • Q − ⇒ P + )+
“ both P are labelled with + ” “ the sole Q is labelled with − ”
F confirmed monotonic F confirmed non-monotonic
Monotonicity Example III Monotonicity Example V
b P ∧ (P ≡ Q) monotonic?
Is F(P ) =
P ∧ (P ≡ Q)
b P ∧ ¬ (∃ x • P ⇒ Q) monotonic?
Is F(P ) =
“ mark occurrence polarity ”
P ∧ ¬ (∃ x • P ⇒ Q) P ∧ (P ± ≡ Q ± )+
+
“ mark occurrence polarity ” “ so, not monotonic then... ”

P + ∧ (¬ (∃ x • P + ⇒ Q − )− )+ = “ logic (exercise) ”
“ both P are labelled with + ” P ∧Q
F confirmed monotonic “ mark occurrence polarity ”
P+ ∧ Q+
“ so is monotonic after all !!! ”
This example shows the limitations of this technique for testing

for monotonicity

Polarity Testing: preparation Fixpoints
I The last example shows a limitation of polarity marking for
assessing monotonicity
I The problem area was any operator that introduces mixed I For a function f whose input and output types are the same
polarity (endofunction), a fixed point (fixpoint) is a solution to the
I One strategy is to simplify the predicate by replacing equation
P ≡ Q by either x = f (x )
(P ⇒ Q) ∧ (Q ⇒ P )
I Fixpoints crop up everywhere in CS theory
or I any time iteration or recursion is involved
(P ∧ Q) ∨ (¬ P ∧ ¬ Q) I There are at least two uses of fixpoints in UTP:
1. defining the meaning of recursion/iteration
2. healthy predicates are fixpoints of “healthifiers”
I Then do further simplification, down to the “the or-ing of the
and-ing of possibly negated atomic predicates”
I However this is getting almost as complicated as doing a
direct proof of monotonicity.
Further Significance of Monotonicity Healthy Lattices
I Knaster-Tarski Fixpoint Theorem (1955)

I Let L be a complete lattice,
I and F : L → L be a monotonic function,
I then the fixpoints of F form a complete lattice
I A complete lattice is non-empty, so at least one fixpoint I Healthy Predicates are fixpoints of “healthifier” functions
must exist I If those “healthifiers” are monotonic, then the healthy
I We must have a least and greatest fixpoint predicates themselves form a complete lattice w.r.t.
I Under the right conditions (F continuous, or n ranging refinement
transfinitely), then we can compute the least fixpoint as I Are H1, H2 and H3 monotonic?
lub{Fn (⊥) | n ∈ 0 . . .}
F0 (x ) =
b x
F n+1 b F(Fn (x ))
(x ) =
where lub is the least upper bound

Monotonicity Check: H Recursion in UTP
H1 I Healthy predicates (H1,H2,H3) form a complete lattice

H1(P ) = ok ⇒ P + under the refinement ordering
(monotonic) I All our programming language HOFs are monotonic
I So we can define the while loop semantics as the least
H2 fixed point of an appropriate HOF w.r.t the refinement
H2(P ) = P ; J ordering:
= ∃ Om • P + [Om /O0 ] ∧ J [Om /O]
(monotonic) c ~P b lfp(λ W • P ; W c Skip)
=
H3 I Our functions are usually continuous, so we can compute

H3(P ) = P ; Skip the fixpoint:
= ∃ Om • P + [Om /O0 ] ∧ Skip[Om /O] V n
lfp F = {F (Chaos) | n ∈ 0 . . .}
(monotonic)
Calculating While-Loop Semantics Refinement Revisited
I We are now in a position to look at refinement again

I A key property we want of refinement is that it be
So often we can calculate the while-loop semantics as compositional:
I we should be able to refine a specification into code in small
c ~P = ⊥ steps.
∧ P ; ⊥ c Skip I This breaks into two aspects:
∧ P ; (P ; ⊥ c Skip) c Skip I Transitivity : we want to proceed by stages
∧ P ; (P ; (P ; ⊥ c Skip) c Skip) c Skip
.. (S v D) ∧ (D v P ) ⇒ SvP
.
We can refine S first to D, and then refine that to P
where ⊥ = Chaos = true I Monotonicity : we want to work on sub-parts
(D v P ) ⇒ F(D) v F(P )
We can refine F(D) by refining component D into P .

Spec-/Program-Construct Monotonicity Designs, Frames and (Anti-)Monotonicity
I Having specification and programming constructs that are I Expand our definitions of SPECw and DSGN :
monotonic is very important in allowing practical
refinement. SPECw (P , Q) = ok ∧ P ⇒ ok 0 ∧ Q ∧ S 0 = S
DSGN (P , Q) = ok ∧ P ⇒ ok 0 ∧ Q
I We have seen that the program constructs (SEQ, CONDc ,
WLOOPc ) are monotonic
I What about specification frames (w :[P , Q]), I We find that both are monotonic in their second argument,
or designs (P ` Q) ? but anti -monotonic in their first .
I Lets define HOFs for these: I This explain why in refinement laws, in order to show that
SPECw (P , Q) =
b w :[P , Q] (P ` Q) v (R ` S)
b P `Q
DSGN (P , Q) =
it is necessary to show R v P , rather than vice-versa.
Are they monotonic ? I In other words, preconditions appear in a negative position.

Class 26 Live Proof Demo using U ·(TP )2
That’s all, folks!

Class 27 Correctness via Verification Conditions
I Introduce notion of assertion statements

I Programmer adds assertions to program at appropriate
points
I Verification Conditions are automatically extracted
I Verification conditions are proven (automatically?).
I Technique tailored for sequential imperative programs
Assertions Verification Conditions
I An assertion c⊥ is a (specification) statement that a

condition holds. I A verification condition (VC) is a predicate relating two
I if c is true, then c⊥ behaves like Skip assertions
I if c is false, then c⊥ behaves like Chaos
I
I Verification conditions depend on the program fragment
c⊥ b Skip c Chaos
= between the two assertions.
I Given (suitably) annotated program pre⊥ ; prog; post⊥ :
I we can automatically derive a VC involving pre⊥ and post⊥
I Often written as as {c} in the literature I that depends on the structure and contents of prog.
I In UTP we can reason about them directly (e.g.): I Hope: VCs are simple enough to be proven automatically.
I Think of them as machine-readable (machine-verifiable?)
b⊥ ; c⊥ = (b ∧ c)⊥
comments !

Appropriate Annotations Annotation Example
A program is appropriately annotated if

The integer division algorithm from [Hoare69] with annotations:
I in a sequence P1 ; P2 ; · · · ; Pn there is an assertion before
every statement that is not an assignment or Skip. true⊥ ;
I in every while-loop there is an (invariant) assertion at the r := x ;
start of the loop body q := 0;
I The first assertion should be a consequence of the (y ≤ r )∗
pre-condition from the specification ( (x = r + y ∗ q)⊥ ;
r := r − y ;
I The last assertion should imply the specification
q := q + 1
post-condition.
);
I Note: this approach works for post-conditions that are (x = r + (y ∗ q) ∧ r < y )⊥
conditions (i.e. snapshots of state, and not before-after
relations).
Generating VCs VC generation (; )
I Given that the last statement is an assignment
genVC(p⊥ ; P1 ; . . . ; Pn−1 ; v := e; q⊥ )
= genVC(p⊥ ; P1 ; . . . ; Pn−1 ; q[e/v ]⊥ )
I VCs are generated for all the program statements
I We shall define VC generation recursively over program We drop the assignment and replace all free occurrences
structure of v in the last assertion by e.
genVC : Program → P VC I Given that the last statement is an not an assignment
genVC(p⊥ ; P1 ; . . . ; Pn−1 ; r⊥ ; Pn ; q⊥ )
= genVC(r⊥ ; Pn ; q⊥ )
∪ genVC(p⊥ ; P1 ; . . . ; Pn−1 ; r⊥ )
We process the last statement and the recursively treat the

rest of the sequence.

VC generation (:=) VC generation ( )
I
b {p ⇒ q[e/x ]}
genVC(p⊥ ; x := e; q⊥ ) =
The pre-condition must imply the post-condition with v
replaced by e.
I
I Example:
genVC(p⊥ ; P1 c P2 ; q⊥ )
genVC(p⊥ ; r := r − y ; q⊥ ) =
b {p ⇒ q[r − y /r ]} = genVC((p ∧ c)⊥ ; P1 ; q⊥ )
∪
genVC((p ∧ ¬ c)⊥ ; P2 ; q⊥ )
I So, given (x = r + y ∗ q)⊥ ; r := r − y , what assertion at
the end will work? We add the branch condition to the pre-condition of the
I Not (x = r + y ∗ q)⊥ , because then-branch, and its negation to that of the else-branch.
x =r +y ∗q 6⇒ x = r − y + y ∗ q
I Assertion x = r + y ∗ (q + 1)⊥ does work, because

x =r +y ∗q ⇒ x = r − y + y ∗ (q + 1)
VC generation (∗) VCs generated by our example.
I
I Do in class
genVC(p⊥ ; c ∗ (i⊥ ; P ); q⊥ )
= {p ⇒ i , i ∧ ¬ c ⇒ q} I Solution
∪ true ⇒ x =x ∧0=0
genVC((i ∧ c)⊥ ; P ; i⊥ ) r =x ∧q=0 ⇒ x = r + (y ∗ q)
x = r + y ∗ q ∧ ¬ (y ≤ r ) ⇒ x = r + (y ∗ q) ∧ r < y
I These correspond closely to our proof technique for loops:
x =r +y ∗q ∧y ≤r ⇒ x = r − y + (y ∗ (q + 1))
I p⇒i
— pre-condition sets up invariant
I i ∧¬c ⇒q I These are simple enough to do by hand (or with U ·(TP )2 ).
— invariant and termination satisfies postcondition I Automated provers with good arithmetic facilities should
I (i ∧ c)⊥ ; P ; i⊥
— invariant and loop-condition preserve the invariant
also handle these.

VCs in the “real world” Avoiding Annotations
VC generation and proof is used in a wide range of verification

tools: I Using VCs requires lots of annotations by the programmer
I SparkADA — dialect of ADA used by Praxis used in the I Can be good discipline for documention code
Tokeneer project I Can it be avoided ?
I Java/ESC — Extended Static Checker for Java (uses Java I Can it be automated ?
Modelling Language for assertion annotations) Given pre⊥ ; prog; post⊥ can we generate the internal
I Spec# — Mircosofts Specification/Verification oriented assertions, and then the VCs ?
language
Another look at refinement Weakest Precondition

I We define a new language construct
I We want to determine if pre ` post 0 is refined by prog prog wp post
pre ` post 0 v prog It means the weakest pre-condition under which running
= [prog ⇒ pre ` post 0 ] prog will guarantee outcome (condition) post .
= [prog ⇒ (ok ∧ pre ⇒ ok 0 ∧ post 0 )] I In UTP we can define it as
= [ok ∧ pre ⇒ (prog ⇒ ok 0 ∧ post 0 )]
= [ok ∧ pre ⇒ ∀ okm , Sm • prog ⇒ ok 0 ∧ post 0 ] Q wp r b ¬ (Q; ¬ r 0 )
=
= [ok ∧ pre ⇒ ¬ ∃ okm , Sm • prog ∧ (ok 0 ⇒ ¬ post 0 )]
Look familiar ?
= [ok ∧ pre ⇒ ¬ (prog; ¬ post 0 )]
I It can be shown to obey the following laws:
I ¬ (prog; ¬ post 0 ) is the weakest condition under which x := e wp r ≡ r [e/x ]
prog is guaranteed to achieve post 0 P ; Q wp r ≡ P wp (Q wp r )
(P c Q) wp r ≡ (P wp r ) c (Q wp r )
(P u Q) wp r ≡ (P wp r ) ∧ (Q wp r )
Using WP The problem with WP
I The idea is to start with the post-condition and work

backwards, generating weakest conditions. I Where is the while-loop ?
I We can show the following for WP and while-loops:
P1 ; . . . ; Pn−2 ; Pn−1 ; Pn wp post
≡ P1 ; . . . ; Pn−2 ; Pn−1 wp (Pn wp post ) (c ∗ P ) wp r b w
= such that
≡ P1 ; . . . ; Pn−2 wp (Pn−1 wp (Pn wp post )) w ⇒ (¬ c ⇒ r )
.. w ⇒ c ⇒ P wp w
.
≡ P1 wp (. . . Pn−2 wp (Pn−1 wp (Pn wp post )) . . .) w is the weakest such predicate
I We then show that the precondition pre implies the overall I Calculating c ∗ P wp r involves some form of a search for
weakest precondition such a w .
I Automating it successfully is equivalent to solving the
pre ⇒ P1 ; . . . ; Pn−2 ; Pn−1 ; Pn wp post Halting Problem (impossible).
WP for while loops
I If the user supplies an Invariant inv and variant V , then we

can define c ∗ P wp r
I If we ignore termination, we can define the following
(c ∗ P ) wp r b inv
=
∧ (c ∧ inv ⇒ P wp inv )
∧ (¬ c ∧ inv ⇒ r )
(Technically this is weakest liberal precondition — WLP)

I We can automatically put in placeholder names for inv
(and V ), but at some stage the user will have to decide
what they should be.

Class 28 Laws of WP
This class was live proofs of the wp laws from the previous class

Class 29 Real Life: Mondex Electronic Purse
Goal — Smart card as electronic purse (1990s),
certified to ITSEC E6.
Verified security protocol.
http://www.mondex.com
Approach —required by E6:
I formal model of security policy
I formal model of security architecture
I refinement proof that architecture satisfies
policy.
Method — Z, based on predicate calculus and ZF set
theory
Who —
Susan Stepney (Logica)
David Cooper (NatWest)
Jim Woodcock (Oxford)
Mondex: Key Results Grand Challenge Pilot Project
I Susan Stepney, David Cooper and Jim Woodcock,

An Electronic Purse: Specification, Refinement, and Proof ,
Technical Monograph PRG-126, Oxford University I In January 2006, the Mondex verification was introduced
Computing Laboratory. July 2000. as a pilot-project for GC6 (Grand Challenge: Dependable
http://www-users.cs.york.ac.uk/~susan/bib/ss/z/monog.htm Systems Evolution)
I Design was proved correct I Original Mondex verification used hand proofs.
I Scale (380 pages): I Idea: ask formal tool developers to apply their tools to the
I abstract model: 20 pages verification problem
I concrete model: 60 pages I At least 8 took up the challenge:
I hand proof: 200 pages I Alloy, ASM, KIV, Event-B, USE, RAISE, Z/Eves, Perfect
I support stuff: 100 pages Developer, π-calculus
I FM within process:
I found logging protocol error
I under budget, ahead of schedule

Mondex Pilot Project outcomes Real Life: Needham-Schroeder Public Key Protocol
I The formalisms and tools used varied a lot in terms of I Want to establish mutual authentication between initiator A
power and expressiveness. and responder B.
I Surprisingly almost all of the groups got very similar I Using public-key protocol:
results, finding similar errors. I Agents have public keys known to all (Ka , Kb )
I Key conclusions: I Agents have secret keys, known only to themselves (Ka−1 ,
I Using tool-support to formally analyse a real-world system K − 1b )
like Mondex is quite feasible. I Agents can generate nonces (random numbers) (Na ,Nb )
I The precise choice of tool is often not that important. I The Needham-Schroeder Public Key Protocol (NS-PKP)
I A special issue (Vol. 20, No. 1, Jan 2008) of the Formal I published in 1978
Aspects of Computing journal has papers detailing these
I uses a 7-message sequence to ensure A and B know they
are talking to each other.
results.
A Formalism(?) for Describing Protocols NS-PKP (3-step version)
I We shall focus on a shorter 3-step version

I If agent A includes its own name in a message, we denote
I The protocol:
that simply as A. 1. A → B : A.B.{Na .A}PK (B)
A sends B his name and nonce, encoded with B’s public
I {M }k denotes message M encrypted with key k . key.
I We denote A’s public/secret keys respectively as 2. B → A : B.A.{Na .Nb }PK (A)
PK (A), SK (A). B uses his private key to decode A’s message, and replies
with A’s nonce and his own, encrypted for A’s eyes only
I We build up composite messages using dots (A.b.{X }k ). 3. A → B : A.B.{Nb }PK (B)
I A message m.n from A to B is described as A decodes the previous message and send B’s nonce back
A→B : m.n.o I At the end both A and B are convinced they are talking to
each other, because there is no way anyone else could get
at the nonces …

17 years later CSP Tool Support
Gavin Lowe, then a postdoc at Oxford, encodes NS-PKP in
CSP.
a, b, a.b, a.b.c, . . . ∈ Events Events (possibly structured)
g ∈ Guard guard predicates I A proof by hand of correctness would be hard and
P , Q, R, ∈ Proc ::= Processes
error-prone
| Stop do nothing, not even terminate
I Gavin Lowe used a tool called “FDR”
| Skip do nothing and terminate
I “FDR” — Failures-Diverence Refinement
| a→P do a, then act like P I Reads an ASCII syntax version of CSP
| g &P guarded process I Does exhaustive search to check an assertion
| P; Q sequential composition I See http://www.fsel.com
| P uQ internal choice
| P Q external choice
| P kA Q parallel composition
| P \A event hiding
| Chaos do anything
Failure ! The Attack
I The check with FDR failed

I NS-PKP was found to be vulnerable to a I It interleaves two runs α and β, one between A and I, the
“man-in-the-middle” attack other between I imitating A to B (here denoted as I(A).
I Gavin Lowe, “An Attack on the Needham-Schroeder I
Public-Key Authentication Protocol” Inf. Process. Lett, A→I : A.I.{Na .A}PK (I)
1995, 56, 3, pp131–133. I(A) → B : A.B.{Na .A}PK (B)
I Gavin Lowe, “Breaking and Fixing the B → I(A) : B.A.{Na , Nb }PK (A)
Needham-Schroeder Public-Key Protocol Using FDR”, in I →A : I.A.{Na , Nb }PK (A)
Tools and Algorithms for Construction and Analysis of A→I : A.I.{Nb }PK (I)
Systems, Second International Workshop, Springer LNCS I(A) → B : A.B.{Nb }PK (B)
1055, pp147–166, 1996.
I This attack had gone unnoticed for 17 years !

Corrections Real Life: SparkADA
I Gavin Lowe then derived a corrected protocol:

1. A → B : A.B.{Na .A}PK (B)
A sends B his name and nonce, encoded with B’s public
key. I SparkADA: a subset of ADA with a formal semantics
2. B → A : B.A.{Na .Nb .B}PK (A) I Spark Examiner: tool supporting correct refinement to
B uses his private key to decode A’s message, and replies
SparkADA
with A’s nonce and his own, and his own identity, encrypted
for A’s eyes only I Developed and marketed by Praxis High Integrity Systems
3. A → B : A.B.{Nb }PK (B) I http://www.praxis-his.com/sparkada/
A decodes the previous message and send B’s nonce back
I He checked it also with FDR — it came up clean.
I This protocol know known (in educated circles) as the
Needham-Schroeder-Lowe protocol.
The big idea Tokeneer Project
I The Tokeneer project was done by Praxis for the U.S.

National Security Agency.
I SparkADA is full ADA without any language constructs that
(biometric access control)
make formal reasoning (too) difficult
I Key results:
I Tools support a very high degree of rigorous formal
lines of code: 9939
development
total effort (days): 260
I Programmer productivity is much higher than normal productivity (lines of code per day, overall) : 38
I Errors found after product shipped are way lower. productivity (lines of code per day, coding phase) : 203
defects discovered by NSA after delivery: 1
I Very high quality outcome by industry standards

Tokeneer Project (ongoing) Recent FM Research at TCD: overview
I NSA did project to demonstrate that their requirement for

formal methods was reasonable and cost-effective. I Handel-C semantics
I NSA release it open-source I UTP, esp. slotted Circus
http://www.adacore.com/home/gnatpro/tokeneer/ I Flash Memory modelling
(requirements; specification; code; proofs)
I Global Computation (Matthew Hennessey, et al.)
I 4 more bugs uncovered in code
I OS kernel verification
I Work by Jim Woodcock uncovered nine
requirements-related defects
Recent Research at TCD: “slotted Circus” Recent Research at TCD: “slotted Circus++”
I We are using UTP to model hardware languages like I One project looked at giving a semantics to priority
Handel-C I Concept of event priority is non-trivial and involves time in
I program-like syntax (C with parallelism) an essential way
I synchronous clocks — assignments synchronise with clock I PhD, Paweł Gancarski (2011)
I true parallelism — x , y := y , x works directly
I inter-thread channel communication
I Another project looked at giving a UTP semantics to
probability
I The language Circus describes concurrent/shared-variable I Done already, relating starting state to sets of final
programs
distributiuons
I has a UTP semantics I The trick was to get a homogeneous relations (same
I key auxiliary observation: start/finish type)
Traces : sequences of Events (tr , and tr 0 ) I We relate start distributions to final ones (harder than it
I Developed by Jim Woodcock and Ana Cavalcanti at York sounds)
I In TCD we have slotted-Circus I PhD, Riccardo Bresciani (2012)
I Language has a Wait (for clock tick) primitive. I Both projects looked at extensions to slotted Circus.
I Traces are chopped into discrete time-slots.

Recent Research at TCD: Flash Memory Recent Research at TCD: Kernel Verification (I)
I One of the grand challenge pilot studies was proposed by I Current spacecraft have many special purpose computers
NASA JPL I ESA wants to merge these into one general purpose
I verify a POSIX filesystem built on Flash Memory computing platform
I We looked at modelling the Flash Memory devices I to save weight
themselves (in Z) I known as Integrated Modular Avionics (IMA)
I Aircraft did this 20 years ago
I We also looked at modelling the hardware/software
interface and verifying Flash Memory internal control FSMs
I IMA requires an operating system that securely partitions
applications
against that interface
I each app has its own partition
I We found errors in the Nand Flash Specification I all inter-app communication and access to hardware
I Open Nand Flash interface (ONFi) resources is via o/s kernel
Recent Research at TCD: Kernel Verification (II) FM & FP — a teaching history
I The availability of courses on both formal methods (FM)

I Our task: and functional programming has changed in recent years
I develop a (informal) Reference Specification for a on the CS B.A. (Mod.), now the ICS.
separating partitioning µkernel.
I Scope out and choose a formalism and tools to formally
I Academic year 2010/11 and before:
verify a kernel implementation, to CC EAL5+ (probably I CS3001, Formal Methods, JS Elective, 5 ECTS
EAL7+) I CS4011, Functional Programming, SS Elective, 10 ECTS
We chose Isabelle/HOL I Academic year 2011/12 and after:
I Formalise the specification using the chosen formalism I CS4003, Formal Methods, SS Elective, 5 ECTS
I Do a dry run at the verification to get an idea of feasibility I CS3016, Functional Programming, JS Mandatory, 5 ECTS
and cost. I CS4012, Topics in Functional Programming , SS Elective, 5
ECTS

2011/12 — a transition year What’s wait all about?
I At the start of 2011/12:

I JS students had no FM, and no choice to do it, and had to
do FP. I For reactive systems (I/O performing) weneed to
I SS students had no FP, but some had chosen it. Also, distinguish non-termination from unrecoverable errors
some had done FM, and wanted more
I Add extra boolean auxiliary variable: wait
I Academic year 2011/12 I wait = True — process is waiting for events (not terminated)
I CS4003 was a follow-on to CS3001 from 2010/11 I wait = False — process has terminated, no longer waiting
I CS3016/CS4012 Functional Programming was a joint
JS/SS class.
I We have three valid combinations of ok and wait :
I ¬ ok — divergence has occurred
I Academic year 2012/13/14 … I ok ∧ wait — process is stable and still running
I CS4003 is basically CS3001 from 2010/11 and before, I ok ∧ ¬ wait — process has terminated successfully.
called CS3BA31 back in 2008/09
I CS3016 is a reduced version of CS3016/CS4012 from
2011/12, with some content overlapping with CS4011 in
2010/11.

Class 30 FM & FP — a teaching history
I The availability of courses on both formal methods (FM)

and functional programming has changed in recent years
on the CS B.A. (Mod.), now the ICS.
I Academic year 2010/11 and before:
I CS3001, Formal Methods, JS Elective, 5 ECTS
I CS4011, Functional Programming, SS Elective, 10 ECTS
I Academic year 2011/12 and after:
I CS4003, Formal Methods, SS Elective, 5 ECTS
I CS3016, Functional Programming, JS Mandatory, 5 ECTS
I CS4012, Topics in Functional Programming , SS Elective, 5
ECTS
2011/12 — a transition year CS4003: relevant exam papers
I At the start of 2011/12:

I JS students had no FM, and no choice to do it, and had to
do FP.
I SS students had no FP, but some had chosen it. Also,
some had done FM, and wanted more 3BA31 2008/09 (Q4 a bit off-topic)
I Academic year 2011/12
CS3001 2009/10
I CS4003 was a follow-on to CS3001 from 2010/11
I CS3016/CS4012 Functional Programming was a joint 3BA31 2010/11
JS/SS class. But not CS4003 2011/12 !
I Academic year 2012/13/14 …
I CS4003 is basically CS3001 from 2010/11 and before,
called CS3BA31 back in 2008/09
I CS3016 is a reduced version of CS3016/CS4012 from
2011/12, with some content overlapping with CS4011 in
2010/11.

Class 31 Good Luck
I CS3001 has been an introduction to Formal Methods

I You have been exposed to key ideas about very rigourous
reasoning about program correctness
I Even if you never apply these techniques, hopefully they
have given you key intellectual tools for program problem
solving:
I pre/post-conditions
I loop invariants and variants
I specification-to-program refinement
I Thank you all for your attention and involvement.

CS4003 All Slides 4up

Uploaded by

Copyright:

Available Formats

You might also like

CS4003 All Slides 4up

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CS4003 All Slides 4up

Uploaded by

Copyright:

Available Formats

CS4003: Approach

CS4003: Formal Methods

CS4003 Formal Methods CS4003 Formal Methods

CS4003: Assessment CS4003: Resources

CS4003 Formal Methods CS4003 Formal Methods

I Goal: convert a starting I-Thing into a H-Thing

CS4003 Formal Methods CS4003 Formal Methods

CS4003 Formal Methods CS4003 Formal Methods

We present a Formal System, called Predicate

CS4003 Formal Methods CS4003 Formal Methods

Expressions Expressions (Aggregates)

We build basic expressions out of constants (k ∈ Const ),

e ∈ Expr ::= k | v constants, variables e ∈ Expr ::= (e1 , . . . , en ) | {. . .} aggregates

CS4003 Formal Methods CS4003 Formal Methods

I We define function application without brackets, so f x

CS4003 Formal Methods CS4003 Formal Methods

We make use of a rich variety of given types and type

CS4003 Formal Methods CS4003 Formal Methods

I I Sometimes we use type annotations embedded in

CS4003 Formal Methods CS4003 Formal Methods

CS4003 Formal Methods CS4003 Formal Methods

I What is our intended meaning for an expression ?

“meaning : values(x , y ) → value”

I Alternatively, we can view the meaning as a function from

CS4003 Formal Methods CS4003 Formal Methods

Environments Evaluating Expressions against Environments

Given an environment (as per previous slide), it is possible to

CS4003 Formal Methods CS4003 Formal Methods

I We usually model Environments mathematically as a finite

CS4003 Formal Methods CS4003 Formal Methods

I What is the meaning of expression

ix + offset 6 length list

I We shall see how to define [[ ]] later.

CS4003 Formal Methods CS4003 Formal Methods

Identities Predicate Logic Syntax

Given atomic predicates we can build a richer language using

This gives us the same power as propositional calculus, a.k.a.

CS4003 Formal Methods CS4003 Formal Methods

The predicate meaning function can be described as follows:

The type annotations (: T ) are optional and are often omitted P1 ⇒ P2 = ¬ P1 ∨ P2

CS4003 Formal Methods CS4003 Formal Methods

Manipulating Environments (Maps) The Meaning of Quantifiers (I)

CS4003 Formal Methods CS4003 Formal Methods

CS4003 Formal Methods CS4003 Formal Methods

∀ n : N • prime(n) ∧ n > 2 ⇒ ¬ prime(n + 1)

CS4003 Formal Methods CS4003 Formal Methods

Under what circumstances is the following true?

CS4003 Formal Methods CS4003 Formal Methods

Example I Commentary Implication Truth-Table

(x < 3 ∧ x > 5) ⇒ x = x + 1 The truth table for implication is as follows:

CS4003 Formal Methods CS4003 Formal Methods

The following statement is true: ∀ n : N • n > 2 ⇒ (prime(n) ⇒ ¬ prime(n + 1))

∀ n : N • n > 2 ⇒ prime(n) ⇒ ¬ prime(n + 1)

CS4003 Formal Methods CS4003 Formal Methods

Quantifier Expansion Logic Example III

CS4003 Formal Methods CS4003 Formal Methods

[[∀ x • ∃ x • x < y ]]ρ [[∀ x • x < y ]]ρ

Example III Commentary (3) Logic Example IV

Define the following in terms of other predicates: