Dynamic-frame specifications in DafnyK. Rustan M. LeinoRiSE, Microsoft Research

1 Dec 2008Invited talk, working group meetingCOST Action IC0701, Formal Verification of Object-Oriented SoftwareMadrid, Spain

Dafnyexperimental languagesequential, object based (no subclassing)specifications in the style of dynamic framescoarse-grained frames (at the level of whole objects, not individual memory locations)

Functional-correctness verifications

queuelinked list with head/tail pointers

in-situ list reversalinteger set

binary treeSchorr-Waite marking algorithm

Dafny grammarProgram ::=

Class*Class ::=

class C<TypeParam*> { Member* }Member ::=

FieldMethodFunction

Fieldsvar x : T;

TypesT ::=

boolintset<T>seq<T>C<T*>object

Methodsmethod M<TypeParam*>

(Param*) returns (Param*) Spec*{ Stmt*}

StatementsStmt ::=

var x: T;x := E;E.f := E’;x := new C<T*>;call x* := E.M(E*);if (E) { Stmt* } else { Stmt* }while (E) invariant J; decreases F; { Stmt* }foreach (x in S) { x.f := E; }

SpecificationsSpec ::=

requires E;modifies S;ensures E;

where “modifies S” meansmodifies Heapensures ( o,f

Heap[o,f] = old(Heap)[o,f] o old(S) ¬ old(Heap)[o,alloc])

modifies clauses are enforced atevery update

Functionsfunction F<TypeParam*> (Param*): T

reads Rd;{

Expr}produces definitional axiom:

( Heap,this,x F(Heap,this,x) = Expr)

What is the reads clause good for?

ensures definitional axioms are consistent

reading o.f requires o Rdcalling a function G requires RdG Rd

produces frame axiom:( h0,h1,this,x

( o,f o Rd h0[o,f] = h1[o,f])F(h0,this,x) = F(h1,this,x))

That’s all!

*) well, pretty much…

*

*

Specification idiom: footprints and validity

class C {var footprint: set<object>;function Valid(): bool

reads {this},footprint;{

this footprint …}

…

Specification idiom: initializermethod Init()

modifies {this};ensures Valid()

fresh(footprint – {this});

Specification idiom: mutating method

method M()requires Valid();modifies footprint;ensures Valid()

fresh(footprint – old(footprint));

Demo: Queue

:Queue

:Node :Node :Node :Node

head

tail

Demo: Schorr-WaiteSpecification (excerpt):

ensures root.marked;ensures ( n, i

n.marked 0 ≤ i < |n.children|n.children[i] = null

n.children[i].marked);Loop invariant (excerpt):

invariant t.marked;invariant ( n, i

n.marked 0 ≤ i < |n.children| nnodeStack

n.children[i] = null

n.children[i].marked);

Schorr-Waite terminationdecreases

{ n | ¬ n.marked },|nodeStack|,|t.children| – t.childrenVisited;

Schorr-Waite: garbage unmarked

ensures root.marked;ensures ( n, i

n.marked 0 ≤ i < |n.children|n.children[i] = null

n.children[i].marked);ensures ( n Reach(root,n) ¬n.marked);

Lessons, 0Dynamic-frame specifications are useful and flexibleA language design around dynamic frames can be simpleThus good in teaching?Specifications are verbose, but perhaps simplification techniques can be applied (like in Spec# or Chalice)Currently missing in Dafny: scopes for axioms

Lessons, 1Pure methods are hard, functions are easySMT solvers work better with ghost fields than with functionsReachability is not always necessary in specificationsSets and sequences are nice as value typesGenerics are a cinchDecreases bound checks can be more liberal than naïve translation

Lessons, 2SMT solvers can be used for functional-correctness verificationInductive predicates seem useful

cases fit nicely with matching triggerstake us in the direction of the input languages of interactive theorem provers

Need: better views/visualizations of program states to clarify error messages and, generally, what’s going on

Parting noteTry it for yourself:http://research.microsoft.com/boogie/dafny