towards a finite model theory for higher-order program verification

39
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

Upload: krista

Post on 24-Feb-2016

45 views

Category:

Documents


0 download

DESCRIPTION

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. The problem: verify Haskell programs. Automatic verification of easy properties, but many of those. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: TOWARDS  A Finite model theory for higher-order program verification

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

Page 2: TOWARDS  A Finite model theory for higher-order program verification

POPL 2013

The problem: verify Haskell programsAutomatic verification of easy properties, but many of those

D.V. @ last WG 2.8 meeting

www.github.com/danr/contractsTool works on subset of Haskell,uses GHC as frontend

Page 3: TOWARDS  A Finite model theory for higher-order program verification

Programs and propertiesrisers [] = []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?

risers CF && {xs | not (null xs)} -> CF && {ys | not (null ys)}

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)

Page 4: TOWARDS  A Finite model theory for higher-order program verification

Design

module Foof x y = …g x = …

g C-- Preludedata [a] = [] | a : asdata Bool = True | False… Functions over these…

𝑇 𝑝𝑟𝑒𝑙𝑢𝑑𝑒

𝜑𝑛𝑒𝑔

𝑇 𝑑𝑒𝑓

HaskellSource

First Order Logic

Formulae

Unsatisfiable Contract holds!

HALOtranslation to First Order

Logic

Z3/Equinox/E/Vampire/Paradox

Theorem Prover

Satisfiable Probably contract doesn’t hold but who knows

<loop>Can’t tell anything

Page 5: TOWARDS  A Finite model theory for higher-order program verification

Function definitions become FOL axioms

Theory

Theorem:

head (Cons x xs) = xhead _ = error

Key insight: standard denotational model, used

as a FOL structure!

NB: Will only consider top-level case/λ

Page 6: TOWARDS  A Finite model theory for higher-order program verification

Axiomatize (some) true facts about

Theorem:

Theory

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

Page 7: TOWARDS  A Finite model theory for higher-order program verification

Higher-order functionshead (Cons x xs) = xhead _ = error

∀ 𝑥 𝑥𝑠 .𝑎𝑝𝑝(h𝑒𝑎𝑑𝑝𝑡𝑟 , 𝑥)=h𝑒𝑎𝑑(𝑥 )

double f x = f (f x)

∀ 𝑥 𝑦 .𝑑𝑜𝑢𝑏𝑙𝑒 (𝑥 , 𝑦 )=𝑎𝑝𝑝 (𝑥 ,𝑎𝑝𝑝 (𝑥 , 𝑦 ))

∀ 𝑥 𝑦 .𝑎𝑝𝑝 (𝑎𝑝𝑝 (𝑑𝑜𝑢𝑏𝑙 𝑒𝑝𝑡𝑟 ,𝑥 ) , 𝑦 )=𝑑𝑜𝑢𝑏𝑙𝑒 (𝑥 , 𝑦 )

Interpreted as the apply(.,.) combinator in

Page 8: TOWARDS  A Finite model theory for higher-order program verification

Contracts denotationally and logically

≙ ≙ ≙ ≙

Logically

Denotationally

Page 9: TOWARDS  A Finite model theory for higher-order program verification

Soundness via denotational semantics

• Assume that:

• Then:

• By previous theorems:

• … hence:

• … which is equivalent to:

Page 10: TOWARDS  A Finite model theory for higher-order program verification

HappyZ3 rocks for provable contracts!

Disclaimer:• 40-80 FOL axioms/problem• Use of fixpoint induction; not

going to talk about it today

Page 11: TOWARDS  A Finite model theory for higher-order program verification

Happy?Here is what happens for unprovable properties Paradox Equinox Z3 Vampire E-proverAnyMorphism.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.01Loop.sat_id_recursive_true P:---- X:---- Z:---- V:---- E:0.01PredLog.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 …

Page 12: TOWARDS  A Finite model theory for higher-order program verification

The reason: loss of finite models

Consider any model and a program that uses and

Z

S(Z)

(1) =/=

S(S(Z))

(1) =/=

(1) (2)

(2) =/=

etc.

There must be an infinite number of elements in the model: Z, S(Z), S(S(Z)),…

Page 13: TOWARDS  A Finite model theory for higher-order program verification

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 [] = Zlength (x:xs) = S (length xs)isZero Z = TrueisZero _ = False

length ∈ CF → {x | isZero x}

[Z] … duh!

Page 14: TOWARDS  A Finite model theory for higher-order program verification

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

Page 15: TOWARDS  A Finite model theory for higher-order program verification

The ideal modified translationSound

implies

Has the finite model propertyIf (or weaker) then there exists finite M,

Complete (i.e. doesn’t introduce more fake counterexamples)

implies

Page 16: TOWARDS  A Finite model theory for higher-order program verification

The quest for …

Page 17: TOWARDS  A Finite model theory for higher-order program verification

What is a counterexample?Assume:

By adequacy: and

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

Page 18: TOWARDS  A Finite model theory for higher-order program verification

When a term does not satisfy its spec

≙ ≙ ≙ … ≙ …

Previously

≙ ≙ ≙ … ≙ …

Modified translation

Page 19: TOWARDS  A Finite model theory for higher-order program verification

An example

length ∈ CF → {x | isZero x}

Counterexample:

Ask for a model of

Key intuition: Any counter-trace must contain terms:length x isZero (length x)

Page 20: TOWARDS  A Finite model theory for higher-order program verification

Propagation of minIf a strict function application is in a trace, then so must be its argument!

Theory

head (Cons x xs) = xhead _ = error

∧ ∧ ∧ ∧

Page 21: TOWARDS  A Finite model theory for higher-order program verification

A requirement for completenessGoal:

implies

Amounts to:

implies

Page 22: TOWARDS  A Finite model theory for higher-order program verification

Completeness guides designLemma A:If then

Proof• Proof theoretically • Model theoretically • By adequacy and induction on the

evaluation of “e”!

More interestingly, it tells us how to modify theory

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

Page 23: TOWARDS  A Finite model theory for higher-order program verification

Provable bottoms and completenessLemma B:If then

The adequacy + induction trick does not work any more! No finite number of steps until non-termination

Fortunately:If then has a model but so does !

In simple words, if we ever prove that it must be the case that just gets “stuck” after a finite number of steps, not that it diverges! So, the same technique as Lemma A can prove Lemma B!

f x = f (S x)

Page 24: TOWARDS  A Finite model theory for higher-order program verification

Finite modelsGiven a counter-trace, need to construct finite model:

Page 25: TOWARDS  A Finite model theory for higher-order program verification

Constructing finite models from traces

$3

$2

$1

$1$4 $5

isZero($2) = $1length($4) = $2Cons($6,$5) = $4Nil = $5Z = $3f($3) = $6S($3) = $2MIN={$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

Page 26: TOWARDS  A Finite model theory for higher-order program verification

Arrow contractsAssume but

So is there a (finite) model for:

These 2 are fine! What about that

translation!!?

Page 27: TOWARDS  A Finite model theory for higher-order program verification

Completeness forces positive translation

≙ ≙ ≙ ≙ Provably sound and complete wrt unmodified translation

Page 28: TOWARDS  A Finite model theory for higher-order program verification

Soundness is for babies!

implies

… or

implies

Easy model theoretic argument!

Page 29: TOWARDS  A Finite model theory for higher-order program verification

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

g ∈ …

∀ 𝑥 .𝑚𝑖𝑛 ( 𝑓 (𝑥 ) )⇒ 𝑓 (𝑥 )=𝑥

∀ 𝑥 .𝑚𝑖𝑛 ( 𝑓 (𝑥 ) )∧…

Hence: !!!!

Page 30: TOWARDS  A Finite model theory for higher-order program verification

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!

Page 31: TOWARDS  A Finite model theory for higher-order program verification

Is completeness really lost?• Assume: • In the unmodified world:

• In the modified world:

If we can derive then we are good!

If not, then, if p can only assert information about

*, we are also done!

* HANDWAVE ARG WARNING

Page 32: TOWARDS  A Finite model theory for higher-order program verification

… and does it matter?• All timeouts for SAT problems ~ a second each

• Also helps prove things faster! (except for Z3 magic )

Page 33: TOWARDS  A Finite model theory for higher-order program verification

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?

Page 34: TOWARDS  A Finite model theory for higher-order program verification

Thanks!

… (∗ )𝑀?? ?

Page 35: TOWARDS  A Finite model theory for higher-order program verification

Extra material

Page 36: TOWARDS  A Finite model theory for higher-order program verification

Key idea: use denotational semanticsA λ/case-lifted

language

𝐷∞≈ (Π𝑛1𝐷∞+…+Π𝑛𝑘

𝐷∞+ (𝐷∞⇒𝐷∞ )+1𝑏𝑎𝑑)⊥Standard

construction

One product of cpos for e ach constructor of arity

Continuous function space Distinguished

one-element cpo

Lifting

Page 37: TOWARDS  A Finite model theory for higher-order program verification

… and use itself as FOL structure

Logical language:

A translation of expressions to logical terms:𝓔𝓔𝓔

Interpreted as the ‘apply’ combinator in

apply (,_) = apply (,_) = apply(fun(d),d’) = d(d’) apply(_,_) =

Interpreted as injection into the appropriate product

Page 38: TOWARDS  A Finite model theory for higher-order program verification

Question: what about completeness? ≙ …

≙ … ≙ ≙ Assume:

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 …

Page 39: TOWARDS  A Finite model theory for higher-order program verification

Ask for information on the whole closure?

≙ … ≙ … ≙ ≙