Static Contract Checking for Haskell Dana N. Xu University of Cambridge Ph.D. Supervisor: Simon Peyton Jones Microsoft Research Cambridge.

Slides:



Advertisements
Similar presentations
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Advertisements

Demand-driven inference of loop invariants in a theorem prover
Program Verification Using the Spec# Programming System ETAPS Tutorial K. Rustan M. Leino, Microsoft Research, Redmond Rosemary Monahan, NUIM Maynooth.
Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 1 Summer school on Formal Models.
Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 0 Summer school on Formal Models.
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Types and Programming Languages Lecture 4 Simon Gay Department of Computing Science University of Glasgow 2006/07.
Functional Programming Lecture 10 - type checking.
Copyright W. Howden1 Programming by Contract CSE 111 6/4/2014.
Tom Schrijvers K.U.Leuven, Belgium with Manuel Chakravarty, Martin Sulzmann and Simon Peyton Jones.
De necessariis pre condiciones consequentia sine machina P. Consobrinus, R. Consobrinus M. Aquilifer, F. Oratio.
An Abstract Interpretation Framework for Refactoring P. Cousot, NYU, ENS, CNRS, INRIA R. Cousot, ENS, CNRS, INRIA F. Logozzo, M. Barnett, Microsoft Research.
Synthesis, Analysis, and Verification Lecture 04c Lectures: Viktor Kuncak VC Generation for Programs with Data Structures “Beyond Integers”
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists Dan Grossman Winter 2013.
Extended Static Checking for Haskell (ESC/Haskell) Dana N. Xu University of Cambridge advised by Simon Peyton Jones Microsoft Research, Cambridge.
- Vasvi Kakkad.  Formal -  Tool for mathematical analysis of language  Method for precisely designing language  Well formed model for describing and.
ICE1341 Programming Languages Spring 2005 Lecture #6 Lecture #6 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.
Verification of Functional Programs in Scala Philippe Suter (joint work w/ Ali Sinan Köksal and Viktor Kuncak) ÉCOLE POLYTECHNIQUE FÉDÉRALE DE LAUSANNE,
Verifying Executable Object-Oriented Specifications with Separation Logic Stephan van Staden, Cristiano Calcagno, Bertrand Meyer.
1 Dependent Types for Termination Verification Hongwei Xi University of Cincinnati.
Functional Design and Programming Lecture 11: Functional reasoning.
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
Software Reliability Methods Sorin Lerner. Software reliability methods: issues What are the issues?
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
A Type System for Expressive Security Policies David Walker Cornell University.
From last time S1: l := new Cons p := l S2: t := new Cons *p := t p := t l p S1 l p tS2 l p S1 t S2 l t S1 p S2 l t S1 p S2 l t S1 p L2 l t S1 p S2 l t.
1 Advanced Material The following slides contain advanced material and are optional.
CS 330 Programming Languages 09 / 16 / 2008 Instructor: Michael Eckmann.
Adding Contracts to Ada Ehud Lamm Adding Design By Contract to Ada.
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.
Cormac Flanagan University of California, Santa Cruz Hybrid Type Checking.
Using Types Slides thanks to Mark Jones. 2 Expressions Have Types: The type of an expression tells you what kind of value you might expect to see if you.
PRAGMATIC PARANOIA Steven Hadfield & Anthony Rice.
Software Engineering Prof. Dr. Bertrand Meyer March 2007 – June 2007 Chair of Software Engineering Static program checking and verification Slides: Based.
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.
Aditya V. Nori, Sriram K. Rajamani Microsoft Research India.
Contracts for Concurrency - Contracts & Inheritance Aryabrata Basu University of Georgia.
Checking Reachability using Matching Logic Grigore Rosu and Andrei Stefanescu University of Illinois, USA.
Sound Haskell Dana N. Xu University of Cambridge Joint work with Simon Peyton Jones Microsoft Research Cambridge Koen Claessen Chalmers University of Technology.
Reasoning about programs March CSE 403, Winter 2011, Brun.
Chapter 3 Part II Describing Syntax and Semantics.
Advanced Formal Methods Lecture 3: Simply Typed Lambda calculus Mads Dam KTH/CSC Course 2D1453, Some material from B. Pierce: TAPL + some from.
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
1 Static Contract Checking for Haskell Dana N. Xu University of Cambridge Joint work with Simon Peyton Jones Microsoft Research Cambridge Koen Claessen.
CATCH 1 : Case and Termination Checking for Haskell Neil Mitchell (supervised by Colin Runciman) 1 Name courtesy of Mike Dodds.
Recursion on Lists Lecture 5, Programmeringsteknik del A.
SWE 4743 Abstract Data Types Richard Gesick. SWE Abstract Data Types Object-oriented design is based on the theory of abstract data types Domain.
CMSC 330: Organization of Programming Languages Lambda Calculus and Types.
Advanced Functional Programming Tim Sheard 1 Lecture 17 Advanced Functional Programming Tim Sheard Oregon Graduate Institute of Science & Technology Lecture:
1 Static Contract Checking for Haskell Dana N. Xu University of Cambridge Joint work with Simon Peyton Jones Microsoft Research Cambridge Koen Claessen.
Institute for Applied Information Processing and Communications (IAIK) – Secure & Correct Systems 1 Static Checking  note for.
COMP 412, FALL Type Systems II C OMP 412 Rice University Houston, Texas Fall 2000 Copyright 2000, Robert Cartwright, all rights reserved. Students.
Shifting the Blame A blame calculus with delimited control Taro Sekiyama* Atsushi Igarashi Soichiro Ueda Kyoto University Gradual typing.
Combining Static and Dynamic Reasoning for Bug Detection Yannis Smaragdakis and Christoph Csallner Elnatan Reisner – April 17, 2008.
Faithful mapping of model classes to mathematical structures Ádám Darvas ETH Zürich Switzerland Peter Müller Microsoft Research Redmond, WA, USA SAVCBS.
Types and Programming Languages Lecture 3 Simon Gay Department of Computing Science University of Glasgow 2006/07.
Haskell With Go Faster Stripes Neil Mitchell. Catch: Project Overview Catch checks that a Haskell program won’t raise a pattern match error head [] =
An introduction to functional programming using Haskell CENG242 –Recitation 1.
1 Interactive Computer Theorem Proving CS294-9 October 5, 2006 Adam Chlipala UC Berkeley Lecture 7: Programming with Proofs.
GADTs meet their match George Karachalias(Ghent University, Belgium) Tom Schrijvers (KU Leuven, Belgium) Dimitrios Vytiniotis(Microsoft Research Cambridge,
CS314 – Section 5 Recitation 9
Theory of Computation Lecture 4: Programs and Computable Functions II
Topics: jGRASP editor ideosyncrasies assert debugger.
Specifications What? Not how!.
Stateful Manifest Contracts
Blame Analysis for Components
Extended Static Checking for Haskell (ESC/Haskell)
Language-based Security
Static Contract Checking for Haskell
Presentation transcript:

Static Contract Checking for Haskell Dana N. Xu University of Cambridge Ph.D. Supervisor: Simon Peyton Jones Microsoft Research Cambridge

From Types to Contracts head [] = BAD head (x:xs) = x head :: [a] -> a …(head 1)… head {xs | not (null xs)} -> {r | True} …(head [])… Bug! Contract (arbitrary Haskell boolean expression) Type null :: [a] -> Bool null [] = True null (x:xs) = False BAD means should not happen: crash

What we want Adapt Findler-Felleisens ideas for dynamic (high-order) contract checking. Do static contract checking for a lazy language. Contract Haskell function Glasgow Haskell Compiler (GHC) Where the bug is Why it is a bug

Three Outcomes (1) Definitely Safe (no crash, but may loop) (2) Definite Bug (definitely crashes) (3) Possible Bug

5 Sorting sorted [] = True sorted (x:[]) = True sorted (x:y:xs) = x <= y && sorted (y : xs) insert :: Int -> [Int] -> [Int] insert {i | True} -> {xs | sorted xs} -> {r | sorted r} merge :: [Int] -> [Int] -> [Int] merge {xs | sorted xs}->{ys | sorted ys}->{r | sorted r} bubbleHelper :: [Int] -> ([Int], Bool) bubbleHelper {xs | True} -> {r | not (snd r) ==> sorted (fst r)} insertsort, mergesort, bubblesort {xs | True} -> {r | sorted r} (==>) True x = x (==>) False x = True

AVL Tree balanced :: AVL -> Bool balanced L = True balanced (N t u) = balanced t && balanced u && abs (depth t - depth u) <= 1 data AVL = L | N Int AVL AVL insert, delete :: AVL -> Int -> AVL insert {x | balanced x} -> {y | True} -> {r | notLeaf r && balanced r && 0 <= depth r - depth x && depth r - depth x <= 1 } delete {x | balanced x} -> {y | True} -> {r | balanced r && 0 <= depth x - depth r && depth x - depth r <= 1} (&&) True x = x (&&) False x = False

The Contract Idea for Higher-Order Function [Findler/Felleisen] f1 :: (Int -> Int) -> Int f1 ({x | x > 0} -> {y | y >= 0}) -> {r | r >= 0} f1 g = (g 0) - 1 f2 :: {r | True} f2 = f1 (\x -> x – 5) Blame f1 : f1 calls g with wrong argument f1 does not satisfy its post-condition Blame f2 : f2 calls f1 with wrong argument f3 :: {r | True} f3 = f1 (\x -> x – 1) f3 is Ok. Cant tell at run-time

What is a Contract? Contract t ::= {x | p} Predicate Contract | x:t 1 -> t 2 Dependent Function Contract | (t 1, t 2 ) Tuple Contract | Any Polymorphic Any Contract 3 { x | x > 0 } (3, []) Any 3 { x | True } (3, []) (Ok, {ys | null ys}) Ok = {x | True} arbitrary Haskell boolean expression inc x:{x | x>0} -> {y | y == x + 1} Precondition Postcondition Postcondition can mention argument arbitrary constructor

What we want? Check f If main Ok, then the whole program cannot crash. If not, show which function to blame and why. Beauty of Contract Checking

Define e t Construct e t (e ensures t) Main Theorem e t iff e t is crash-free (related to Blume&McAllester:JFP06) some e Symbolically simplify (e t) See if BAD is syntactically in e. If yes, DONE ; else give BLAME [POPL10] ESC/Haskell [Haskell06]

e {x | p} = case p[e/x] of True -> e False -> BAD e x:t 1 -> t 2 = v. (e (v t 1 )) t 2 [(v t 1 )/x] e (t 1, t 2 ) = case e of (e 1, e 2 ) -> (e 1 t 1, e 2 t 2 ) e Any = UNR Wrappers and ( pronounced ensures pronounced requires) related to [Findler-Felleisen:ICFP02]

Wrappers and ( pronounced ensures pronounced requires) related to [Findler-Felleisen:ICFP02] e {x | p} = case p[e/x] of True -> e False -> UNR e x:t 1 -> t 2 = v. (e (v t 1 )) t 2 [v t 1 /x] e (t 1, t 2 ) = case e of (e 1, e 2 ) -> (e 1 t 1, e 2 t 2 ) e Any = BAD

Some Interesting Details Practice Theory Adding tags, e.g. BAD f Achieves precise blaming More tags to trace functions to blame Achieves the same goal of [Meunier:POPL06] Using a theorem prover Counter-example guided unrolling Contracts that loop Contracts that crash Lovely Lemmas

Summary Static contract checking is a fertile and under-researched area Distinctive features of our approach – Full Haskell in contracts; absolutely crucial – Declarative specification of satisfies – Nice theory (with some very tricky corners) – Static proofs – Modular Checking – Compiler as theorem prover

After Ph.D. Postdoc project in 2009: probabilistic contract for component base design [ATVA2010] Current project at Xavier Leroys team (INRIA) - a verifying compiler: 1. Apply the idea to OCaml compiler by allowing both static and dynamic contract checking 2. Connect with Coq to verify more programs statically. 3. Use Coq to prove the correctness of the framework. 4. Apply new ideas back to Haskell (e.g. GHC).

Static and Dynamic Program with Specifications Run time error attributes blame to the right place Compile time error attributes blame to the right place Dynamic checking Static checking No blaming means Program cannot crashs Or, more plausibly: If you guarantee that f t, then the program cannot crash

What exactly does it mean to say that et e satisfies contract t? e t

When does e satisfy a contract? Brief, declarative… inc x:{x | x > 0} -> {y | y == x + 1} Precondition Postcondition Postcondition can mention argument

When does e satisfy a contract? The delicate one is the predicate contract. Our decision: e {x | p} iff e is crash-free crash-free Question: What expression is crash-free ? crash-free e is crash-free iff no blameless context can make e crash e is crash-free iff C. BAD s C. C[e] * BAD

Crash-free Examples Lemma: e is syntactically safe => e is crash-free. Crash-free? \x -> x YES (1, True)YES (1, BAD) NO \x -> if x > 0 then x else (BAD, x) NO \x -> if x*x >= 0 then x + 1 else BAD Hmm.. YES

When does e satisfy a contract? See the paper for … Why e must be crash-free to satisfy predicate contract? Why divergent expression satisfies all contract? What if contract diverges (i.e. p diverges)? What if contract crashes (i.e. p crashes)?

How can we mechanically check that et e satisfies contract t? e t ???

Example head { xs | not (null xs) } -> Ok = \v. head (v { xs | not (null xs)}) Ok e Ok = e = \v. head (v { xs | not (null xs)}) = \v. head (case not (null v) of True -> v False -> UNR) head:: [a] -> a head [] = BAD head (x:xs) = x

\v. head (case not (null v) of True -> v False -> UNR) null :: [a] -> Bool null [] = True null (x:xs) = False not :: Bool -> Bool not True = False not False = True = \v. head (case v of [] -> UNR (p:ps) -> p) Now inline not and null Now inline head = \v. case v of [] -> UNR (p:ps) -> p head:: [a] -> a head [] = BAD head (x:xs) = x So head [] fails with UNR, not BAD, blaming the caller

Static and Dynamic Program with Specifications Run time error attributes blame to the right place Compile time error attributes blame to the right place Dynamic checking Static checking [Findler, Felleisen, Blume, Hinze, Loh, Runciman, Chitil] [Flanaghan, Mitchell, Pottier]