TOWARDS A FINITE MODEL THEORY FOR HIGHER-ORDER PROGRAM VERIFICATION Dimitrios Vytiniotis, Koen Claessen, Simon Peyton Jones, Dan Rosén WG2.8 – Annapolis,

Slides:



Advertisements
Similar presentations
Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 1 Summer school on Formal Models.
Advertisements

Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Completeness and Expressiveness
HASKELL TO LOGIC THROUGH DENOTATIONAL SEMANTICS Dimitrios Vytiniotis, Koen Claessen, Simon Peyton Jones, Dan Rosén POPL 2013, January
Static Contract Checking for Haskell Dana N. Xu University of Cambridge Ph.D. Supervisor: Simon Peyton Jones Microsoft Research Cambridge.
Type-based termination analysis with disjunctive invariants Dimitrios Vytiniotis, MSR Cambridge with Byron Cook (MSR Cambridge) and Ranjit Jhala (UCSD)
Computer Science CPSC 322 Lecture 25 Top Down Proof Procedure (Ch 5.2.2)
Techniques for Proving the Completeness of a Proof System Hongseok Yang Seoul National University Cristiano Calcagno Imperial College.
Extended Static Checking for Haskell (ESC/Haskell) Dana N. Xu University of Cambridge advised by Simon Peyton Jones Microsoft Research, Cambridge.
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
Working with Discourse Representation Theory Patrick Blackburn & Johan Bos Lecture 3 DRT and Inference.
UIUC CS 497: Section EA Lecture #2 Reasoning in Artificial Intelligence Professor: Eyal Amir Spring Semester 2004.
Situation Calculus for Action Descriptions We talked about STRIPS representations for actions. Another common representation is called the Situation Calculus.
Logic.
Functional Design and Programming Lecture 11: Functional reasoning.
CPSC 322, Lecture 19Slide 1 Propositional Logic Intro, Syntax Computer Science cpsc322, Lecture 19 (Textbook Chpt ) February, 23, 2009.
1 Introduction to Computability Theory Lecture12: Reductions Prof. Amos Israeli.
Lecture 9 Recursive and r.e. language classes
1 Module 9 Recursive and r.e. language classes –representing solvable and half-solvable problems Proofs of closure properties –for the set of recursive.
0 PROGRAMMING IN HASKELL Chapter 4 - Defining Functions.
Some administrative stuff Class mailing list: –send to with the command “subscribe”
Sparkle A theorem prover for the functional language Clean Maarten de Mol University of Nijmegen February 2002.
Review: forward E { P } { P && E } TF { P && ! E } { P 1 } { P 2 } { P 1 || P 2 } x = E { P } { \exists … }
CS 330 Programming Languages 09 / 16 / 2008 Instructor: Michael Eckmann.
Type Inference: CIS Seminar, 11/3/2009 Type inference: Inside the Type Checker. A presentation by: Daniel Tuck.
Simon Peyton Jones Microsoft Research Joint work with Dana Xu, University of Cambridge Dec 2007.
1 Module 10 Recursive and r.e. language classes –representing solvable and half-solvable problems Proofs of closure properties –for the set of recursive.
Equational Reasoning Math Foundations of Computer Science.
1 Static Contract Checking for Haskell Dana N. Xu INRIA France Work done at University of Cambridge Joint work with Simon Peyton Jones Microsoft Research.
1 Knowledge Based Systems (CM0377) Lecture 4 (Last modified 5th February 2001)
Inferring Specifications to Detect Errors in Code Mana Taghdiri Presented by: Robert Seater MIT Computer Science & AI Lab.
Extended Static Checking for Java  ESC/Java finds common errors in Java programs: null dereferences, array index bounds errors, type cast errors, race.
Interpretation Environments and Evaluation. CS 354 Spring Translation Stages Lexical analysis (scanning) Parsing –Recognizing –Building parse tree.
Slide 1 Propositional Definite Clause Logic: Syntax, Semantics and Bottom-up Proofs Jim Little UBC CS 322 – CSP October 20, 2014.
Sound Haskell Dana N. Xu University of Cambridge Joint work with Simon Peyton Jones Microsoft Research Cambridge Koen Claessen Chalmers University of Technology.
Introduction to ACL2 CS 680 Formal Methods for Computer Verification Jeremy Johnson Drexel University.
Semantics In Text: Chapter 3.
Great Theoretical Ideas in Computer Science.
Great Theoretical Ideas in Computer Science.
Math 344 Winter 07 Group Theory Part 2: Subgroups and Isomorphism
1 CS 457/557: Functional Languages Lists and Algebraic Datatypes Mark P Jones Portland State University.
Lecture 5 1 CSP tools for verification of Sec Prot Overview of the lecture The Casper interface Refinement checking and FDR Model checking Theorem proving.
1 Static Contract Checking for Haskell Dana N. Xu University of Cambridge Joint work with Simon Peyton Jones Microsoft Research Cambridge Koen Claessen.
SAT-Based Model Checking Without Unrolling Aaron R. Bradley.
1 Static Contract Checking for Haskell Dana N. Xu University of Cambridge Joint work with Simon Peyton Jones Microsoft Research Cambridge Koen Claessen.
This Week Lecture on relational semantics Exercises on logic and relations Labs on using Isabelle to do proofs.
1 Temporal logic. 2 Prop. logic: model and reason about static situations. Example: Are there truth values that can be assigned to x,y simultaneously.
1 Propositional Logic Limits The expressive power of propositional logic is limited. The assumption is that everything can be expressed by simple facts.
CS357 Lecture 13: Symbolic model checking without BDDs Alex Aiken David Dill 1.
Bounded Model Checking A. Biere, A. Cimatti, E. Clarke, Y. Zhu, Symbolic Model Checking without BDDs, TACAS’99 Presented by Daniel Choi Provable Software.
Daniel Kroening and Ofer Strichman 1 Decision Procedures An Algorithmic Point of View Basic Concepts and Background.
June 21, Reasoning about explicit strictness in a lazy language using mixed lazy/strict semantics Marko van Eekelen Maarten de Mol Nijmegen University,
Metalogic Soundness and Completeness. Two Notions of Logical Consequence Validity: If the premises are true, then the conclusion must be true. Provability:
Knowledge Repn. & Reasoning Lecture #9: Propositional Logic UIUC CS 498: Section EA Professor: Eyal Amir Fall Semester 2005.
1 Proving Properties of Recursive List Functions CS 270 Math Foundations of CS Jeremy Johnson.
MA/CSSE 474 Theory of Computation Decision Problems, Continued DFSMs.
Logical Agents. Outline Knowledge-based agents Logic in general - models and entailment Propositional (Boolean) logic Equivalence, validity, satisfiability.
1 Interactive Computer Theorem Proving CS294-9 October 19, 2006 Adam Chlipala UC Berkeley Lecture 9: Beyond Primitive Recursion.
Gödel's Legacy: The Limits Of Logics
Sparkle a functional theorem prover
Computability and Complexity
Reasoning About Code.
Reasoning about code CSE 331 University of Washington.
Great Theoretical Ideas in Computer Science
Complexity 6-1 The Class P Complexity Andrei Bulatov.
Lecture 5 Floyd-Hoare Style Verification
Extended Static Checking for Haskell (ESC/Haskell)
Finite-Trace Linear Temporal Logic: Coinductive Completeness
Search techniques.
Static Contract Checking for Haskell
Presentation transcript:

TOWARDS A FINITE MODEL THEORY FOR HIGHER-ORDER PROGRAM VERIFICATION Dimitrios Vytiniotis, Koen Claessen, Simon Peyton Jones, Dan Rosén WG2.8 – Annapolis, MD, November 2012

POPL 2013 The problem: verify Haskell programs Automatic verification of easy properties, but many of those last WG 2.8 meeting Tool works on subset of Haskell, uses GHC as frontend

Programs and properties risers [] = [] risers [x] = [[x]] risers (x:y:ys) = case risers (y:ys) of [] -> error “urk” (s:ss) -> if x <= y then (x:s):ss else [x]:s:ss 1.Can this code crash? 2.non-empty input ⟶ non-empty result? Syntax of “contracts” (“refinements” more appropriate): C ::= {x | p} | (x:C) -> C | C && C | CF Just a Haskell expression of type Bool “crash-free” (will ignore today)

Design module Foo f x y = … g x = … -- Prelude data [a] = [] | a : as data Bool = True | False … Functions over these… Haskell Source First Order Logic Formulae Unsatisfiable Contract holds! HALO translation to First Order Logic Z3/Equinox/E/ Vampire/Paradox Theorem Prover Satisfiable  Probably contract doesn’t hold but who knows Can’t tell anything

Function definitions become FOL axioms head (Cons x xs) = x head _ = error Key insight: standard denotational model, used as a FOL structure! NB: Will only consider top- level case/λ

data List a = Cons a (List a)| Nil

Higher-order functions head (Cons x xs) = x head _ = error double f x = f (f x)

Contracts denotationally and logically Logically Denotationally

Soundness via denotational semantics

Happy Z3 rocks for provable contracts! Disclaimer: FOL axioms/problem Use of fixpoint induction; not going to talk about it today

Happy? Here is what happens for unprovable properties Paradox Equinox Z3 Vampire E-prover AnyMorphism.big_sat_app_any_morphism_fail_step P:---- X:---- Z:---- V:---- E:---- Loop.sat_id_loop_pred P:0.00 X:0.01 Z:0.01 V:---- E:0.01 Loop.sat_id_recursive_true P:---- X:---- Z:---- V:---- E:0.01 PredLog.sat_concatMap_cf_missing_step P:---- X:---- Z:---- V:---- E:---- PredLog.sat_concatMap_retains_missing_step P:---- X:---- Z:---- V:---- E:---- PredLog.sat_flattenAnd_cf_missing_step P:---- X:---- Z:---- V:---- E:---- PredLog.sat_flattenAnd_retains_missing_step P:---- X:---- Z:---- V:---- E:---- Recursion.big_sat_exp_accum_cf_broken_step P:---- X:---- Z:---- V:---- E:---- Recursion.sat_exp_cf_broken_step P:---- X:---- Z:---- V:---- E:---- Recursion.sat_fac_cf_broken_step P:---- X:---- Z:---- V:---- E:---- Recursion.sat_mul_cf_broken_step P:---- X:---- Z:---- V:---- E:---- Recursion.sat_mult_cf_broken_step P:---- X:---- Z:---- V:---- E:---- Recursion.sat_qfac_cf_broken_step P:---- X:---- Z:---- V:---- E:---- Recursion.sat_rev_cf_broken_step P:---- X:---- Z:---- V:---- E:---- Risers.big_sat_risersBy_nonEmpty_broken2_step P:---- X:---- Z:---- V:---- E:---- Risers.big_sat_risersBy_nonEmpty_broken_step P:---- X:---- Z:---- V:---- E:---- Risers.sat_risers_broken2_step P:---- X:---- Z:---- V:---- E:---- Risers.sat_risers_broken3_step P:---- X:---- Z:---- V:---- E:---- Risers.sat_risers_broken_step P:---- X:---- Z:---- V:---- E:---- Risers.sat_risers_missing_le_step P:---- X:---- Z:---- V:---- E:---- Shrink.big_sat_shrink_lazy_step P:---- X:---- Z:---- V:---- E:---- Timeouts … 

The reason: loss of finite models S(Z) (1) =/= S(S(Z)) (1) =/= (2) =/= etc. There must be an infinite number of elements in the model: Z, S(Z), S(S(Z)),…

Loss of finite models is bad Theorem prover loops trying to construct an infinite model User never gets to see a counterexample – be it a real counterexample or a result of incompleteness Even if the counterexample is dead-simple length [] = Z length (x:xs) = S (length xs) isZero Z = True isZero _ = False length ∈ CF → {x | isZero x} [Z] … duh!

Two (fine) ways out of this situation Roll-your-own decision procedures (e.g. Leon) Modify translation to FOL (e.g. Nitpick) Our choice: let’s try to re-use existing technology

The ideal modified translation

What is a counterexample? A bunch of finite evaluation traces! Key intuition: try to capture “minimal core” of the terms and function behaviors that are involved in a counterexample trace

When a term does not satisfy its spec Previously Modified translation

An example length ∈ CF → {x | isZero x} Key intuition: Any counter-trace must contain terms: length x isZero (length x)

Propagation of min If a strict function application is in a trace, then so must be its argument! head (Cons x xs) = x head _ = error

A requirement for completeness

Proof Proof theoretically  Model theoretically  By adequacy and induction on the evaluation of “e”! data List a = Cons a (List a)| Nil

Provable bottoms and completeness The adequacy + induction trick does not work any more! No finite number of steps until non-termination f x = f (S x)

Finite models

Constructing finite models from traces $3 $2 $1 $4$5 isZero($2) = $1 length($4) = $2 Cons($6,$5) = $4 Nil = $5 Z = $3 f($3) = $6 S($3) = $2 MIN={$1,$2,$3,$4,$5} Construction idea (roughly): Take all terms that were evaluated (finite) in β-equivalence classes to be in min() Take all terms that were not equivalent to a term in the first group (also finite) in β-equivalence classes. Add appropriate function tables. $6

Arrow contracts These 2 are fine! What about that translation!!?

Completeness forces positive translation Provably sound and complete wrt unmodified translation

Soundness is for babies! Easy model theoretic argument!

Sadly we lost finite models again … f x = x f ∈ CF → {y|p} -- Already proved g ∈ …

Idea: weaken arrow contracts Intuition: only if you are interested in an application can you use information about it Open: how do finite models get affected? Open: how does completeness get affected? Tension!

Is completeness really lost? * HANDWAVE ARG WARNING

… and does it matter? All timeouts for SAT problems  ~ a second each Also helps prove things faster! (except for Z3 magic )

It’s really verification vs. model checking We are aiming to use the same hammer on two maybe very different problems …. We design a logic for proving specifications … which is also good in finding counterexamples! Is it reasonable to try and reconcile both? Should we be looking at each separately?

Thanks!

Extra material

Key idea: use denotational semantics A λ/case-lifted language Continuous function space Distinguished one-element cpo Lifting

Interpreted as injection into the appropriate product

Question: what about completeness? For those f(t) that would be called we have all “knowledge”. For those f(t) that /are not called/ the unmodified theory must have been able to prove the goal assuming they were just unr. Oh, what about functions that were both defined and given a contract? Then we are in trouble, when they yield information about some other variable in the closure …

Ask for information on the whole closure?