Lecture 12:
Minding your Ps & Qs:
Axiomatic Semantics and
Program Verification
It is easier to write an incorrect program than
understand a correct one.
Alan Perlis
CS655: Programming Languages
David Evans
University of Virginia
http://www.cs.virginia.edu/~evans
Computer Science
Menu
• Position Paper 3 Results
• Axiomatic Semantics
• Program Verification
27 July 2016
University of Virginia CS 655
2
Position Paper 3
• Average on Position Paper 3 = 1.04
• Good papers with 3 different answers:
– Yes, they should have started with CLU
– No, CLU wouldn’t have helped much because of different
requirements
– Its a silly question – of course they looked at and were
influenced by CLU
• Two interpretations of requirements
– General goals: high-level language for programming reliable
embedded systems
– Specific goals: specific language requirements set out in
STEELMAN, etc.
– Best: analyze the specific requirements in terms of the general
ones
• Be resourceful: easy way to get “check++” on this
position paper
27 July 2016
University of Virginia CS 655
3
From: Barbara Liskov <liskov@piano.lcs.mit.edu>
Subject: Re: CLU and Ada
To: evans@cs.virginia.edu
Date: Fri, 4 Feb 2000 13:38:45 -0500 (EST)
Actually CLU was known at the time the initial work on Ada
happened and so was Alphard (this was Bill Wulf's language). Both Bill
and I were at the preliminary meetings on Ada and both of us worked as
consultants in various ways.
The requirements for Ada were larger than what CLU provided. In
particular there were requirements for concurrency, for fixed point
arithmetic, and even maybe real-time processing (I can't remember about
this). And certainly at that point there was a requirement for explicit
storage management!
In fact, my recollection was that the requirements were a huge
problem. They were tremendously over constrained, with reqs for very
specific solutions. This by itself was enough to lead to a convoluted
design. Of course we are talking about politics here: how this particular
set of requirements came to be accepted as defining what had to be done.
27 July 2016
University of Virginia CS 655
4
It is probably still possible to get the original requirements documents (the
"Strawman", "Tinman", etc.) You might also look at the book on history of
programming languages.
Another point is that many of the issues that caused design problems at
the time were more difficult then than they are now, since programming
languages are much better understood. This is partly the reason why the
requirements were not what they should have been, and also partly why
the solutions in the language were more complex than necessary.
But of course there was also "not invented here" problems. And because
the whole project was structured in a way that effectively prevented the
best language designers from doing the design, the obvious thing
happened.
b
27 July 2016
University of Virginia CS 655
5
Date: 4 Feb 2000 13:08:15 -0500 Pick a good time:
From: David Evans <evans@cs.virginia.edu>
for most academics: early afternoon (Friday best)
To: liskov@lcs.mit.edu
for industrial types: mid-week mornings (?)
Subject: CLU and Ada
Don’t wait until you are up against a deadline.
Professor Liskov,
Introduce yourself and context. 2 sentences!
I'm teaching the graduate programming languages course at UVA this
term, and week after next we'll be focusing mostly on CLU. I plan to assign to the
students the task of writing position papers on whether or not developing Ada was
necessary in light of what had already been done with CLU.
To me it seems extremely unnecessary, as nearly every feature of Ada
was done in a more principled way in CLU. Do you know if the Ada committees
were aware of CLU and considered it?
It seems reasonable that it wasn't on the list of languages they Flattery
considered in 1976, but shocking if they weren't aware of it when they started the
language design contracts in 1977 in light of what had already been published
about CLU at this time. Are you aware of any technical or political reasons why
they felt the need to design a new language?
Ask a pointed question – but do your
homework first (better than I did).
Best
regards,
All project
groups should be
Dave
<signature
with
URL removed>
emailing
experts
onemail
your and
topic.
27 July 2016
University of Virginia CS 655
6
Axiomatic Semantics
• Reason about programs using axioms
(mathematical rules about program text
fragments)
• What’s wrong with operational semantics?
– Limited deductive power (simulates a particular
execution)
– Depends on understanding of virtual machine
• What’s wrong with static semantics?
– Limited to simple properties
• Axiomatic: prove more interesting properties
about programs without simulating executions
27 July 2016
University of Virginia CS 655
7
Floyd-Hoare Rules
pre-condition
post-condition
P { code fragment } Q
Partial correctness:
For all execution states which satisfy P, if the
code fragment terminates, the resulting
execution state satisfies Q.
Total correctness:
For all execution states which satisfy P, the
code fragment terminates and the resulting
execution state satisfies Q. (Sometimes
people write: P [ code fragment ] Q.)
27 July 2016
University of Virginia CS 655
8
A simple example
{ true } while true do x := 1 { 2 + 2 = 5 }
Partial correctness:
Yes!
Since code doesn’t terminate,
any post-condition is satisfied.
Total correctness:
No!
Since code doesn’t terminate,
no total correctness post-condition
could be satisfied.
27 July 2016
University of Virginia CS 655
9
A Toy Language: Algorel
Program ::= Statement
Statement ::=
Variable := Expression
| Statement ; Statement
| while Pred do Statement end
Expression ::= Variable | IntLiteral
| Expression + Expression | Expression * Expression
Pred ::= true | false | Expression <= Expression
Why not use BARK?
27 July 2016
University of Virginia CS 655
10
An Algorel Program Fragment
while n <= x do
result := result * n;
n := n + 1;
end
% Post-condition: result = x!
27 July 2016
University of Virginia CS 655
11
Goal: find weakest pre-condition
P & x0 = x
{ while n <= x do
result := result * n;
n := n + 1
end
}
result = x0!
Elevator speech: group 3
27 July 2016
University of Virginia CS 655
12
Rule for while
P  Inv,
Inv { Pred }  Inv,
Inv & Pred { Statement } Inv,
(Inv & ~Pred)  Q,
while Pred do Statement end terminates
P { while Pred do Statement end } Q
27 July 2016
University of Virginia CS 655
13
What can go wrong?
• Invariant too weak
– Can’t prove (Inv & ~Pred)  Q
• Invariant too strong
– Can’t prove Inv & Pred { Statement } Inv
– Can’t prove P  Inv
(for sufficiently weak P)
27 July 2016
University of Virginia CS 655
14
Go backwards: Inv & ~Pred  Q
Inv & ~Pred  Q
Inv & ~(n <= x)  result = x0!
Guess an Invariant:
Inv = result = (n - 1)! & x = x0 & n <= x + 1
Inv & ~(n <= x)  result = x0!
n <= x + 1 & ~(n <= x)  n = x + 1
result = ((x + 1) – 1)!  result = x!
x = x0  result = x0!
27 July 2016
University of Virginia CS 655
15
Inv & Pred { Statement } Inv
result = (n - 1)! & x = x0 & n <= x + 1 & n <= x
{ result := result * n; n := n + 1; }
result = (n - 1)! & x = x0 & n <= x + 1
Rule for sequences:
{ A } s0 { B }, { B } s1 { C }
{ A } s0 ; s1 { C }
27 July 2016
University of Virginia CS 655
16
Push: result := result * n
result0 = result &
result = (n - 1)! & x = x0 & n <= x + 1 & n <= x
{ result := result * n }
B
Substitute result = result0 * n:
B = result = (n – 1)! * n & rest is same
B = result = n! & rest is same
27 July 2016
University of Virginia CS 655
17
Reminder: Inv = result = (n - 1)! & x = x0 & n <= x + 1
Push: n := n + 1
n0 = n & result = n0! & x = x0 & n0 <= x + 1 & n0 <= x
{ n := n + 1 }
Q
Substitute n = n0 + 1 (n0= n – 1) :
result = (n – 1)! & x = x0 & (n – 1) <= x + 1 & (n – 1)
<= x
 result = (n – 1)! & x = x0 & n <= x + 2 & n <= x + 1
 result = (n – 1)! & x = x0 & n <= x + 1  Inv
27 July 2016
University of Virginia CS 655
18
Progress Checklist
We need to pick P to make this work.


P  Inv,
Inv { Pred }  Inv,  Trivial since Pred = (n <= x)
Inv & Pred { Statement } Inv,
(Inv & ~Pred)  Q,
while Pred do Statement end terminates
P { while Pred do Statement end } Q
27 July 2016
University of Virginia CS 655
19
Find weakest pre-condition
• Need to show
P & x = x0  result = (n - 1)! & x = x0 & n <= x + 1
• Weakest:
P = result = (n – 1)! & n <= x + 1
• More intuitive (but stronger):
P = result = 1 & n = 0 & x >= 0
 result = 0! & n <= x + 1
 Inv
27 July 2016
University of Virginia CS 655
20
What have we proved?
Partial correctness of:
result = 1 & n = 0 & x >= 0 & x0 = x
{ while n <= x do
result := result * n; n := n + 1
end }
result = x0!
27 July 2016
University of Virginia CS 655
21
Total Correctness:
Must show termination also
1. Define an energy function,
E  integer
2. Show P  E is finite, non-negative
3. Show Pred does not change E
4. Show loop body decreases E
e0 = E & Pred { Statement } E < e0
5. Show E = 0  ~Pred (termination)
Remind you of anything?
27 July 2016
University of Virginia CS 655
22
Termination Proof
1. Energy Function
E=x+1–n
2. P  E is finite, non-negative
n = 0 & x >= 0  E = x + 1 – 0
x is >= 0, so x + 1 is finite, non-negative
3. Pred does not change E
Trivial, Pred is n <= x
27 July 2016
University of Virginia CS 655
23
Termination Proof, Part 2
4. Show loop body decreases E
e0 = x + 1 – n & n <= x & n0 = n
{result := result * n; n := n + 1; }
x + 1 - n < e0
True: x + 1 – (n0 + 1) < x + 1 - n0.
5. Show termination:
x + 1 - n = 0  ~(n <= x)
x + 1 = n  ~(x + 1 <= x)
27 July 2016
University of Virginia CS 655
24
Summary
• Once you have the right invariant, proving
partial correctness is tedious but easy
– Computers can do this quickly
• Picking the right invariant is hard and not well
understood
– Computers can do this slowly in special
circumstances, often need help (from programmer
or language designer)
• Next time: Proof-Carrying Code
– Can quickly and automatically prove interesting
properties (type safety, memory safety, etc.) about
arbitrary code if you are given the right invariants
27 July 2016
University of Virginia CS 655
25
Charge
• Rest/catch up on your other classes
– Unless you are prosecution attorney
• Only one paper to read (Necula & Lee)
• Nothing to write until March 23
(preliminary project report)
– Except for attorneys
• Keep making progress on your projects
(especially if you won’t during Spring
Break)
27 July 2016
University of Virginia CS 655
26