An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

95
An Algebra for Program Designs Tony Hoare Moscow July 2011
  • date post

    19-Dec-2015
  • Category

    Documents

  • view

    214
  • download

    0

Transcript of An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Page 1: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

An Algebra for Program Designs

Tony HoareMoscow July 2011

Page 2: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

With ideas from

• Ian Wehrman• John Wickerson• Stephan van Staden• Peter O’Hearn• Bernhard Moeller• Georg Struth• Rasmus Petersen• …and others

Page 3: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Summary

operational rules

denotational models

algebraic laws

deduction rules

Page 4: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Part 1Algebra and Hoare logic

• Some familiar algebraic laws• their application to program designs• derivation of Hoare logic from them

Page 5: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Part 1Algebra and Hoare logic

algebraic laws

deduction rules

Page 6: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Subject matter: designs

• variables (p, q, r) stand for programs, designs, specifications,…

• they all describe what happens inside/around a computer that is executing a program.

• The program itself is the most precise.• The specification is the most abstract.• Designs come in between.

Page 7: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Binary relation: p ⊑ q

• Everything described by pis also described by q , e.g.,– spec p implies spec q– prog p satisfies spec q– prog p more determinate than prog q

• stepwise development is– spec ⊒ design ⊒ program

• stepwise analysis is the reverse– program ⊑ design ⊑ spec

Page 8: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

p ⊑ q

• below• lesser• stronger• lower bound• more precise• …deterministic• included in • antecedent =>

• above• greater• weaker• upper bound• more abstract• ...non-deterministic• containing (sets)• consequent (pred)

Page 9: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

⊑ is a partial order

•⊑ transitive• p ⊑ r if p ⊑ q and q ⊑ r• needed for stepwise

development/analysis

• ⊑ antisymmetric and reflexive• p = r iff p ⊑ r and r ⊑ p• needed for abstraction

Page 10: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Binary operator: p ; q

• sequential composition of p and q•an execution of p;q consists of– all events x from an execution of p – and all events y from an execution of q

•subject to an ordering constraint….

Page 11: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Three ordering constraints

•strong sequence: x must precede y•weak sequence: y must not precede x•no constraint

•all our algebraic laws will apply to all three alternatives

Page 12: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Hoare triple: {p} q {r}

• defined as p;q ⊑ r – starting in the final state of an execution of p,

q ends in the final state of some execution of r– p and r may be arbitrary designs.

•example: {..x+1 ≤ n} x:= x + 1 {..x ≤ n} • where ..b (finally b) describes all executions that

end in a state satisfying a single-state predicate b .

Page 13: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

monotonicity

• Law: ( ; is monotonic wrto ⊑) :– p;q ⊑ p’;q’ if p ⊑ p’ and q ⊑ q’– like addition of numbers

• monotony justifies modular evolution– p’ and q’ are developed independently

• Theorem (rule of consequence):– p’ ⊑ p & {p} q {r} & r ⊑ r’ implies {p’} q

{r’}

• Law is also provable from the theorem

Page 14: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

associativity

• Law (; is associative) :– (p;q);q’ = p;(q;q’)

• Theorem (sequential composition):– {p} q {s} & {s} q’ {r} implies {p} q;q’

{r}

• half the law provable from theorem

Page 15: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Conditional correctness

• disregards unending executions• ..b is re-interpreted as including them all:– ‘if the execution terminates, it will end in a state

satisfying b‘.• definition of triple stays the same• all laws apply also to conditional correctness

logic as well as total correctness logic.

Page 16: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Unit(skip):

• a program that does nothing• Law ( is the unit of ;):– p; = p = ;p

• Theorem (nullity)– {p} {p}

• a quarter of the law is provable from theorem

Page 17: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

concurrent composition: p | q

• execution of (p|q) consists of – all events x of an execution of p,– and all events y of an execution of q

• same laws apply to both:– interleaving: x precedes or follows y– true concurrency: x neither precedes nor

follows y.

• Laws: | is associative, commutative and monotonic

Page 18: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Separation Logic

• Law (locality):– (s|p) ; q ⊑ s |(p;q) (left locality)– p ; (q|s) ⊑ (p;q) | s (right locality) – a weak version of associativity– a weak version of distribution

• Theorem (frame rule) :– {p} q {r} implies {p|s} q {r|s}– in Hoare logic, & replaces | , with side-

condition that q does not make s false

• Left locality provable from the theorem!

Page 19: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Concurrency law

• Law (; exchanges with *)– (p|q) ; (p’|q’) ⊑ (p;p’) | (q;q’)– a weak kind of mutual distribution

• Theorem (| compositional)– {p} q {r} & {p’} q’ {r’} implies

{p|p’} q|q’ {r|r’}

• the law is provable from the theorem

Page 20: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

p|q ; p’|q’

p p’

q’q

Page 21: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

p|q ; p’|q’

⊑p p’

q’qp;p’ | q;q’

Page 22: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Regular language model

• p, q, r,… are sets of strings (languages).

• p ⊑ q is inclusion of languages• p;q is (lifted) concatenation of

strings• p|q is (lifted) interleaving of strings

Page 23: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Left locality

•Theorem: (s|p) ; q ⊑ s |(p;q)in lhs: s interleaves with just p ,

and all of q comes at the end.in rhs: s interleaves with all of p;qso lhs is a special case of rhs• right locality is similar

Page 24: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Exchange

• Theorem: (p|q) ; (p’|q’) ⊑ (p;p’) | (q;q’)– in lhs: all of p and q comes before

all of p’ and q’ .– in rhs: p may interleave with q’

and p’ with q– the lhs is a special case of the rhs.

Page 25: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Conclusion

• regular expressions satisfy all our laws for ⊑ , ; , and |

• and other operators introduced later

Page 26: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Part 2. more operators and laws

• Complete lattices• Iteration, recursion, fixed points• Subroutines, abstraction• Basic commands

Page 27: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Subject matter

• variables (p, q, r) stand for programs, designs, specifications,…

• they are all descriptions of what happens inside and around a computer that is executing a program.

• the differences between programs and specs are often defined from their syntax.

Page 28: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Specification syntax includes

• disjunction (or) to express abstraction, or to keep options open– ‘it may be painted green or blue’

• conjunction (and) to combine requirements– it must be cheaper than x and faster than y

• negation (not) for safety and security– it must not explode

• implication to define contracts– if the user observes the protocol, so will the system

Page 29: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Program syntax excludes

• disjunction– non-deterministic programs difficult to test

• conjunction– inefficient to find a computation satisfying both

• negation– Incomputable

• implication– there is no point in executing it

Page 30: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

programs include

• sequential composition (;)• concurrent composition (|)• iteration• recursion• interfaces• transactions• assignments, inputs, outputs, jumps,…

• So let’s include these in our specification/designs

Page 31: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Bottom •A specification that has no implementation

like the false predicate

•A program that has no executione.g., because of some syntactic error

• Define as the least solution of _ ⊑ q– r ⊑ q implies ⊑ r

• Law ( is the zero of ;) :– ; p = = p ;

• Theorem :– {p} {q}

Page 32: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Top ⊤

• a program with a run-time error– for which the programmer is responsible– e.g., subscript error, division by zero,

divergence,…

• defined as the least solution of q ⊑ _• Law: it is a zero of ;• ⊤; p = ⊤ = p ;⊤ if p ≠

• Theorem: none

Page 33: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Non-determinism (or): p ⊔ q

• describes all executions that either satisfy p or satisfy q .

• The choice is not (yet) determined.• It may be determined later– in development of the design– or in writing the program– or by the compiler – or even at run time

Page 34: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

lub (join): ⊔

• Define p⊔q as least solution ofp ⊑ _ & q ⊑ _

• Theorem– p ⊑ r & q ⊑ r iff p⊔q ⊑ r

• Theorem– ⊔ is associative, commutative,

monotonic, idempotent and increasing– it has unit ⊥ and zero ⊤

Page 35: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

glb (meet): ⊓

• Define p⊓q as greatest solution of_ ⊑ p & _ ⊑ q

Page 36: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Distribution

• Law ( ; distributive through ⊔ )– p ; (q⊔q’) = p;q ⊔ p;q’– (q⊔q’) ; p = q;p ⊔ q’;p

• Theorem (non-determinism)– {p} q {r} & {p} q’ {r} implies {p}

q⊔q’ {r}– i.e., to prove something of q⊔q’ prove the same thing of both q and q’

• quarter of law provable from theorem

Page 37: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Conditional: p if b else p’• Define p ⊰b⊱ p’ as

b.. ⊓ p ⊔ not(b).. ⊓ p’– where b.. describes all executions that

begin in a state satisfying b .

• Theorem. p ⊰b⊱ p’ is associative, idempotent, distributive, and– p ⊰b⊱ q = q ⊰not(b)⊱ p (symm)– (p ⊰b⊱ p’ ) ⊰c⊱ (q ⊰b⊱ q’) =

(p ⊰c⊱ q) ⊰b⊱ (p’ ⊰c⊱ q’) (exchange)

Page 38: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Transaction

• Defined as (p ⊓..b) ⊔ (q ⊓..c)– where ..b describes all executions that

end satisfying single-state predicate b .

• Implementation:– execute p first– test the condition b afterwards– terminate if b is true– backtrack on failure of b– and try an alternative q with condition c.

Page 39: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Transaction (realistic)

• Let r describe the non-failing executions of a transaction t .– r is known when execution of t is complete.– any successful execution of t is committed – a single failed execution of t is undone, – and q is done instead.

• Define: (t if r else q) = t if t ⊑ r

= (t ⊓ r) ⊔ q otherwise

Page 40: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Least upper bound

• Let S be an arbitrary set of designs

•Define ⊔S as least solution of

∀s∊ S . s ⊑ _– ∀s∊ S . s ⊑ r ⇒ r ⊑ ⊔S (all r)

• everything is an upper bound of { } ,

so ⊔ { } = – a case where ⊔S ∉ S

Page 41: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

similarly

• ⊓S is greatest lower bound of S

• ⊓ { } = ⊤

Page 42: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Iteration (Kleene *)

• q* is least solution of – (ɛ ⊔ (q; _) ) ⊑ _

• q* =def ⊔{s| ɛ ⊔ q; s ⊑ s} – ɛ ⊔ q; q* ⊑ q* – ɛ ⊔ q; q’ ⊑ q’ implies q* ⊑ q’

– q* = ⊔ {qⁿ | n ∊ Nat} (continuity)

• Theorem (invariance):– {p}q*{p} if {p}q{p}

Page 43: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Infinite replication

• !p is the greatest solution of _ ⊑ p|_– as in the pi calculus

• all executions of !p are infinite– or possibly empty

Page 44: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Recursion

• Let F(_) be a monotonic function between programs.

• Theorem: all functions defined by monotonic operators are monotonic.

• μF is strongest solution of F(_) ⊑ _• νF is weakest solution of _ ⊑ F(_)• Theorem (Knaster-Tarski): These

solutions exist.

Page 45: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Interfaces

• Let q be the body of a subroutine• Let s be its specification• Let (q .. s) assert that q meets s• Programmer error (⊤) if incorrect • Caller of subroutine may assume

that s describes all itsexecutions• Implementeation may execute q

Page 46: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Subroutine with interface: q .. s

• Define (q..s) as glb of the setq ⊑ _ & _ ⊑ s

• Theorem: (q.. s) = q if q ⊑ s = ⊤ otherwise

Page 47: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Basic statements/assertions

• skip • bottom • top ⊤• assignment: x := e(x)• assertion: assert b• assumption: assume b• finally ..b• initially b..

Page 48: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

more

• assign thru pointer: [a] := e• output: c!e• input: c?x• points to: a|-> e– a |-> _ =def exists v . a|-> v

• throw• catch

Page 49: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Laws(examples)

• assume b =def b..⊓• assert b =def b..⊓ ⊔ not(b).. • x:=e(x) ; x:=f(x) = x :=

f(e(x))– in languages without interleaving

Page 50: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

more

• p|-> _ ; [p] := e ⊑ p|-> e– in separation logic

• c!e | c?x = x := e– in CSP but not in CCS or Pi

• throw x ; (catch x; p) = p

Page 51: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Part 3Unifying Semantic Theories

• Six familiar semantic definition styles. • Their derivation from the algebra• and vice versa.

Page 52: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

operational rules

algebraic laws

deduction rules

Page 53: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Hoare Triple

• a method for program verification• {p} q {r} ≝ p;q ⊑ r– one way of achieving r

is by first doing p and then doing q

• Theorem:– {p} q {s} & {s} q’ {r} implies {p}

q;q’ {r}– proved by associativity

Page 54: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Plotkin reduction

• a method for program execution• <p , q> -> r =def p ; q ⊒ r– if p describes state before execution of q

then r describes a possible final state, eg.

–<..(x2 = 18) , x := x+1> -> ..(x = 37)

• Theorem:• <p, q> -> s & <s, q’> -> r

implies <p, q;q’> r

Page 55: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Milner transition

• method of execution of concurrent processes

• p – q -> r ≝ p ⊒ q;r– one of the ways of executing p is by first

executing q and then executing r .– e.g., (x := x+3) –(x:=x+1)-> (x:=x+2)

• Theorem:– p –q-> s & s –q’-> r => p –(q;q’)-> r

(big-step rule for ; )

Page 56: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

test generation

• method of test case generation• p[q]r =def p ⊑ q;r– if r describes erroneous states

resulting from execution of q , then p describes some initial states in which a test-run of q will certainly reveal the error.

• Theorem:• p [q] s & s [q’] r implies p [q;q’] r

Page 57: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Summary

• {p} q {r} =def p;q ⊑ r– Hoare triple

• <p,q>->r =def p;q ⊒ r– Plotkin reduction

• p –q->r =def p ⊒ q;r–Milner transition

• p [q] r =def p ⊑ q;r– test generation

Page 58: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Sequential composition

• Law: ; is associative• Theorem: sequence rule is valid for all four

triples.

• the Law is provable from the conjunction of all of them

Page 59: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Skip

• Law: p ; = p = ; p

• Theorems: {p} {p} p [] p

p − → p <p, > –>p

• Law follows from conjunction of all four theorems

Page 60: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Left distribution ; through ⊔

• Law: p;(q ⊔ q’) = p;q ⊔ p;q’ • Theorems:– {p} (q⊔q’) {r} if {p}q{r} and {p}q’{r} – <p,q⊔q’>-> r if <p,q>-> r or <p, q’>-> r – p [q⊔q’] r if p [q] r or p [q’] r – p -(q⊔q’)-> r if p –q->r and p -q’->r

(not used in CCS)

• law provable from either and rule together with either or rule.

Page 61: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

locality and frame

• left locality (s|p) ; q ⊑ s | (p;q)• Hoare frame: {p} q {r} ⇒ {s|p} q {s|r}

• right locality p ; (q|s) ⊑ (p;q) | s• Milner frame: p -q-> r ⇒(p|s) - q-> (r|s)

• Full locality requires both frame rules

Page 62: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Separation logic

•Exchange law: – (p | p’) ; (q| q’) (p ; q) | (p’;q’)

•Theorems– {p} q {r} & {p’} q’ {r’} ⇒ {p|p’} q|q’ {r|

r’}– p -q -> r & p’–q’-> r’ => p|p’ –q|q’-> r|r’

• the law is provable from either theorem• For the other two triples, the rules are

equivalent to the converse exchange law.

Page 63: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

usual restrictions on triples

• in {p} q {r} , p and r are of form ..b, ..c

• in p [q] r , p and r are of form b.., c..• in <p,q>->r, p and r are of form ..b, ..c• in p –q->r, p and r are programs • in p –q->r (small step), q is atomic • (in all cases, q is a program)

• all laws are valid without these restrictions

Page 64: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Weakest precondition (-;)Specification statement (;-)

•(q -; r) =def the weakest solution of ( _ ;q ⊆ r)

– the same as Dijkstra’s wp(q, r)– for backward development of programs

•(p ;- r) =def the weakest solution of ( p ; _ ⊆ r)

– Back/Morgan’s specification statement– same as p⇝r in RGSep– for stepwise refinement of designs

Page 65: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Weakest precondition (-;)

• Law (-; adjoint to ;)– p ⊑ q -; r iff p;q ⊑ r (galois)

• Theorem– (q -; r) ; q ⊑ r– p ⊑ q -; (p ; q)

• Law provable from the theorems– cf. (r div q) q ≤ r– r ≤ (rq) div q

Page 66: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Theorems

• q’ ⊑ q & r ⊑ r’ => q-;r ⊑ q’-;r’• (q;q’)-;r ⊑ q-;(q’-;r)• q-;r ⊑ (q;s) -; (r;s)

Page 67: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Law of consequence

Page 68: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Frame laws

Page 69: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Part 4Denotational Models

A model is a mathematical structure that satisfies the axioms of an algebra, and realistically describes a useful application, for example, program execution.

Page 70: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Modelsdenotational models

algebraic laws

Page 71: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Some Standard Models:

• Boolean algebra( {0,1}, ≤, , , not(_) )

• predicate algebra (Frege, Heyting)– (ℙS,├, , , not(_), => , ∃, ∀)

• regular expressions (Kleene):– (ℙA*, ⊆, ∪, ; , ɛ , {<a>} , | )

• binary relations (Tarski):– (ℙ(SS), ⊆, ∪, ∩, ; , Id , not(_), converse(_))

• algebra of designs is a superset of these

Page 72: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Model: (EV, EX, PR)

• EV is an underlying set of events (x, y, ..) that can occur in any execution of any program

• EX are executions (e, f,…), modelled as sets of events

• PR are designs (p, q, r,…), modelled as sets of executions.

Page 73: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Set concepts

• ⊑ is (set inclusion)• ⊔ is (set union) • ⊓ is (intersection of sets)• is { } (the empty set)• ⊤ is EV (the universal set)

Page 74: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

With (|)

• p | q = {e ∪ f | e ε p & f ε q & e∩f = { } }

– each execution of p|q is the disjoint union of an execution of p and an execution of q

– p|q contains all such disjoint unions

• | generalises many binary operators

Page 75: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Introducing time

• TIM is a set of times for events– partially ordered by ≤

•Let when : EV -> TIM – map each event to its time of occurrence.

Page 76: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Definition of <

•x < y =def not(when(y) ≤ when(x))– x < y & y < x means that x and y occur ‘in

true concurrency’.

• e < f =def ∀x,y . x∊e & y∊f => x < y– no event of f occurs before an event of e– hence e<f implies ef = { }

•If ≤ is a total order, – there is no concurrency, – executions are time-ordered strings

Page 77: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Sequential composition (then)

• p ; q = {ef | e∊p & f∊q & e<f}

• special case: if ≤ is a total order, – e < f means that ef is concatenation

(e⋅f) of strings– ; is the composition of regular

expressions

Page 78: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Theorems

• These definitions of ; and | satisfy the locality and exchange laws.

•(s|p) ; q ⊑ s |(p;q)•(p|q) ; (p’|q’) ⊑ (p;p’) | (q;q’)– Proof: the lhs describes fewer

interleavings than the rhs.

• regular expressions satisfy all our laws for ⊑ , ⊔ , ; , and |

Page 79: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Disjoint concurrency (||)

• p||q =def (p ; q) (q ; p)– all events of p concurrent with all of q .– no interaction is possible between them.

• Theorems: (p||q) ; r p || (q ; r) (p||q) ; (p’||q’) (p;p’) || (q;q’)

– Proof: the rhs has more disjointness constraints than the lhs .

– the wrong way round!

• So make the programmer responsible for disjointness, using interfaces!

Page 80: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Interfaces

• Let q be the body of a subroutine• Let s be its specification• Let (q .. s) assert that q is correct • Caller may assume s• Implementer may execute q

Page 81: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Solution

• p*q =def (p|q => p||q) = p|q if p|q ⊑ p||q

⊤ otherwise – programmer is responsible for absence

of interaction between p and q .

• Theorem: ; and * satisfy locality and exchange.– Proof: in cases where lhs ≠ rhs, rhs =

Page 82: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Problem

• ; is almost useless in the presence of arbitrary interleaving (interference).

• It is hard to prove disjointness of p||q• We need a more complex model– which constrains the places at which a

program may make changes.

Page 83: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Separation

• PL is the set of places at which an event can occur

• each place is ‘owned’ by one thread,– no other thread can act there.

• Let where:EV -> PL map each event to its place of occurrence.

• where(e) =def {where(x) | x ∊ e }

Page 84: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Separation principle

• events at different places are concurrent

• events at the same place are totally ordered in time

• ∀x,y ∊ EV . where(x) = where(y) iff x≤y or y≤x

Page 85: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Picture

time

space

Page 86: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Theorem

• p || q = {ef | e ∊ p & f ∊ q& where(e) where(f) =

{ } }• proved from separation principle

Page 87: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Convexity Principle

• Each execution contains every event that occurs between any of its events.

• ∀e ∊ EX , y ∊ EV. ∀x, z ∊ e .when(x) ≤ when(y) ≤ when(z) => y ∊ e – no event from elsewhere can interfere

between any two events of an execution

Page 88: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

A convex execution of p;q

time

space

p q

Page 89: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

A non-convex ‘execution’ of p;q

time

space

p q

Page 90: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Conclusion:in Praise of Algebra

• Reusable• Modular• Incremental• Unifying

• Discriminative• Computational• Comprehensible• Abstract

• Beautiful!

Page 91: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Algebra likes pairs

• Algebra chooses as primitives– operators with two operands + , – predicates with two places = , – laws with two operators & v , + – algebras with two components rings

Page 92: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Tuples

• Tuples are defined in terms of pairs.– Hoare triples– Plotkin triples– Jones quintuples – seventeentuples …

Page 93: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Semantic Links

deductions transitions

denotations

algebra

Page 94: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Increments

algebra

Page 95: An Algebra for Program Designs Tony Hoare MoscowJuly 2011.

Filling the gaps

algebra