Lecture 12: Minding your Ps & Qs:

Slides:



Advertisements
Similar presentations
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Advertisements

David Evans CS655: Programming Languages University of Virginia Computer Science Lecture 20: Total Correctness; Proof-
Reasoning About Code; Hoare Logic, continued
David Evans CS655: Programming Languages University of Virginia Computer Science Lecture 19: Minding Ps & Qs: Axiomatic.
ISBN Chapter 3 Describing Syntax and Semantics.
1 Design by Contract Building Reliable Software. 2 Software Correctness Correctness is a relative notion  A program is correct with respect to its specification.
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
CS 355 – Programming Languages
CS 330 Programming Languages 09 / 18 / 2007 Instructor: Michael Eckmann.
CS 330 Programming Languages 09 / 16 / 2008 Instructor: Michael Eckmann.
Describing Syntax and Semantics
Test Preparation Strategies
Cs3102: Theory of Computation Class 18: Proving Undecidability Spring 2010 University of Virginia David Evans.
Introduction Algorithms and Conventions The design and analysis of algorithms is the core subject matter of Computer Science. Given a problem, we want.
CSI 3125, Axiomatic Semantics, page 1 Axiomatic semantics The assignment statement Statement composition The "if-then-else" statement The "while" statement.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
CS 363 Comparative Programming Languages Semantics.
1 cs205: engineering software university of virginia fall 2006 Avoiding Software Disasters.
Reasoning about programs March CSE 403, Winter 2011, Brun.
CS216: Program and Data Representation University of Virginia Computer Science Spring 2006 David Evans Lecture 3: Levels of Abstraction
3.2 Semantics. 2 Semantics Attribute Grammars The Meanings of Programs: Semantics Sebesta Chapter 3.
Chapter 3 Part II Describing Syntax and Semantics.
Semantics In Text: Chapter 3.
David Evans CS150: Computer Science University of Virginia Computer Science Lecture 36: Modeling Computing.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
CSCI1600: Embedded and Real Time Software Lecture 28: Verification I Steven Reiss, Fall 2015.
CSSE501 Object-Oriented Development. Chapter 10: Subclasses and Subtypes  In this chapter we will explore the relationships between the two concepts.
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
CORRECTNESS ISSUES AND LOOP INVARIANTS Lecture 8 CS2110 – Fall 2014.
David Evans CS200: Computer Science University of Virginia Computer Science Class 26: Halting Problem It is plain at any.
(Thunking about Thunks)
Lecture 4: Metacircles Eval Apply David Evans
Describing Syntax and Semantics
Lecture 6: Lambda Calculus
Axiomatic Number Theory and Gödel’s Incompleteness Theorems
Correctness issues and Loop invariants
Matching Logic An Alternative to Hoare/Floyd Logic
Reasoning About Code.
Reasoning about code CSE 331 University of Washington.
Lambda Calculus Revisited
Formative Feedback The single most powerful influence on enhancing achievement is feedback. Hattie, 2009 At best, students receive ‘moments’ of feedback.
Lesson 2 Programming constructs – Algorithms – Scratch – Variables Intro.
Lecture 5 Floyd-Hoare Style Verification
Axiomatic semantics Points to discuss: The assignment statement
Programming Languages and Compilers (CS 421)
How to Become an Expert on Any Topic!
CSCE 489- Problem Solving Programming Strategies Spring 2018
Semantics In Text: Chapter 3.
Lecture 25: Metalinguistics > (meval '((lambda (x) (* x x)) 4)
Lecture 21: Crosscutting Aspect-Oriented Programming Background
Lecture 10: The Return of Paco Background just got here last week
Axiomatic Verification I
Lecture 10: Using Object-Oriented Languages
Class 24: Computability Halting Problems Hockey Team Logo
SSEA Computer Science: Track A
Tonga Institute of Higher Education IT 141: Information Systems
Lecture 19: Proof-Carrying Code Background just got here last week
Lecture 5: Writing Page
Axiomatic Verification I
Lecture 10: Fixed Points ad Infinitum M.C. Escher, Moebius Ants
David Evans Lecture 19: ||ism I don’t think we have found the right programming concepts for parallel computers yet.
Lecture 13: Proof-Carrying Code Background just got here last week
Lecture 14: Mocking Mockingbirds
Program correctness Axiomatic semantics
Lecture 15: Crazy Eddie and the Fixed Points Background
Programming Languages and Compilers (CS 421)
EE 194/BIO 196: Modeling biological systems
Group 4: Song Li, Ying Lu, Hexin Wang, and Michael Walker May 1, 2000
Lecture 23: Computability CS200: Computer Science
Presentation transcript:

David Evans http://www.cs.virginia.edu/~evans 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 Background just got here last week finished degree at MIT week before Philosophy of advising students don’t come to grad school to implement someone else’s idea can get paid more to do that in industry learn to be a researcher important part of that is deciding what problems and ideas are worth spending time on grad students should have their own project looking for students who can come up with their own ideas for research will take good students interested in things I’m interested in – systems, programming languages & compilers, security rest of talk – give you a flavor of the kinds of things I am interested in meant to give you ideas (hopefully even inspiration!) but not meant to suggest what you should work on CS655: Programming Languages University of Virginia Computer Science David Evans http://www.cs.virginia.edu/~evans

University of Virginia CS 655 Menu Position Paper 3 Results Axiomatic Semantics Program Verification 2 May 2019 University of Virginia CS 655

University of Virginia CS 655 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 2 May 2019 University of Virginia CS 655

University of Virginia CS 655 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. 2 May 2019 University of Virginia CS 655

University of Virginia CS 655 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 2 May 2019 University of Virginia CS 655

University of Virginia CS 655 Pick a good time: for most academics: early afternoon (Friday best) for industrial types: mid-week mornings (?) Don’t wait until you are up against a deadline. Date: 4 Feb 2000 13:08:15 -0500 From: David Evans <evans@cs.virginia.edu> To: liskov@lcs.mit.edu Subject: CLU and Ada Professor Liskov, 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 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? Best regards, Dave <signature with email and URL removed> Introduce yourself and context. 2 sentences! Flattery Ask a pointed question – but do your homework first (better than I did). All project groups should be emailing experts on your topic. 2 May 2019 University of Virginia CS 655

University of Virginia CS 655 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 2 May 2019 University of Virginia CS 655

University of Virginia CS 655 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.) 2 May 2019 University of Virginia CS 655

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. 2 May 2019 University of Virginia CS 655

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? 2 May 2019 University of Virginia CS 655

An Algorel Program Fragment while n <= x do result := result * n; n := n + 1; end % Post-condition: result = x! 2 May 2019 University of Virginia CS 655

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 2 May 2019 University of Virginia CS 655

University of Virginia CS 655 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 2 May 2019 University of Virginia CS 655

University of Virginia CS 655 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) 2 May 2019 University of Virginia CS 655

Go backwards: Inv & ~Pred  Q Inv & ~(n <= x)  result = x0! Guess an Invariant: Inv = result = (n - 1)! & x = x0 & n <= x + 1 n <= x + 1 & ~(n <= x)  n = x + 1 result = ((x + 1) – 1)!  result = x! x = x0  result = x0! 2 May 2019 University of Virginia CS 655

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 } 2 May 2019 University of Virginia CS 655

Push: result := result * n 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 2 May 2019 University of Virginia CS 655

University of Virginia CS 655 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 2 May 2019 University of Virginia CS 655

University of Virginia CS 655 Progress Checklist We need to pick P to make this work. 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  Trivial since Pred = (n <= x)   2 May 2019 University of Virginia CS 655

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 2 May 2019 University of Virginia CS 655

University of Virginia CS 655 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! 2 May 2019 University of Virginia CS 655

Total Correctness: Must show termination also Define an energy function, E  integer Show P  E is finite, non-negative Show Pred does not change E Show loop body decreases E e0 = E & Pred { Statement } E < e0 Show E = 0  ~Pred (termination) Remind you of anything? 2 May 2019 University of Virginia CS 655

University of Virginia CS 655 Termination Proof Energy Function E = x + 1 – n P  E is finite, non-negative n = 0 & x >= 0  E = x + 1 – 0 x is >= 0, so x + 1 is finite, non-negative Pred does not change E Trivial, Pred is n <= x 2 May 2019 University of Virginia CS 655

Termination Proof, Part 2 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. Show termination: x + 1 - n = 0  ~(n <= x) x + 1 = n  ~(x + 1 <= x) 2 May 2019 University of Virginia CS 655

University of Virginia CS 655 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 2 May 2019 University of Virginia CS 655

University of Virginia CS 655 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) 2 May 2019 University of Virginia CS 655