The following constructor does not work and fails at
parent !in Repr
Why can't Dafny proof the postcondition, that parent is not part of the Repr set?
constructor Init(x: HashObj, parent:Node?)
ensures Valid() && fresh(Repr - {this, data})
ensures Contents == {x.get_hash()}
ensures Repr == {this, data};
ensures left == null;
ensures right == null;
ensures data == x;
ensures parent != null ==> parent !in Repr;
ensures this in Repr;
{
data := x;
left := null;
right := null;
Contents := {x.get_hash()};
Repr := {this} + {data};
}
I'm guessing that HashObj is a trait? (If it's a class, then your example verifies for me.) The verification fails because the verifier thinks x might equal parent.
The verifier ought to know that Node is not a HashObj (unless, of course, your class Node really does extend HashObj), but it doesn't. You may file this as an Issue on https://github.com/dafny-lang/dafny to get that corrected.
In the meantime, you can write a precondition that says x and parent are different. Here, there's a wrinkle, too. You'd like to write
requires x != parent
but (unless Node really does extend HashObj) this does not type check. So, you would want to cast parent to object?. There's no direct syntax for such an up-cast, but you can do it with a let expression:
requires x != var o: object? := parent; o
Related
The example code will seem artificial as it is the smallest that I can find to illustrates my problem.
datatype Twee = Node(value : int, left : Twee, right : Twee) | Empty
method containsI(t : Twee, s : int) returns (r : bool)
{
var working :Twee := t;
if (working.Node?) {
r:= (working.value == s);
assert r==true ==> (working.value == s);
while working.Node?
decreases working
invariant r==true ==> (working.value == s)
{ //assert r==true ==> (working.value == s);
r:=false;
working:= working.right;
assert r==true ==> (working.value == s);
}
}
r:=false;
assert r==true ==> (working.value == s);
}
Dafny complains about working.value in the invariant. Stating that it can only be applied when working is a Node event though Dafny reports no problems when the invariant is commented out. Hence Dafny seems to know that working is a Node.
Any corrections to my understanding much appreciated.
a loop invariant needs to hold before and after each iteration of the loop; in particular, it should hold on loop termination, when the loop condition is returning false.
So for example, anything in the body of the loop is guarded by working.Node? (like the line working:= working.right;) which is why Dafny reports no problems there. However, Dafny reports a problem with the line
invariant r==true ==> (working.value == s) because this expression may need to be evaluated in a context where working.Node? does not hold.
Perhaps what you mean to do is write something like
invariant r==true ==> working.Node? ==> (working.value == s)
It's a little hard to tell what your intent is.
By the way, you may be wondering why the two lines at the end do not fail...
r:=false;
assert r==true ==> (working.value == s);
This is because the assertion is a vacuous predicate here (r==true always evaluates to false)
Hi Relatively new to Dafny and have defined methods set2Seq and seq2Set for conversion between sets and seqs. But can only find how to write a function fseq2Set from sets to sequences.
I can not find how to define fseq2Set. As Lemmas can not reference methods this makes proving the identity beyond me. Any help much appreciated?
Code:
function method fseq2Set(se: seq<int>) :set<int>
{ set x:int | x in se :: x }
method seq2Set(se: seq<int>) returns (s:set<int>)
{ s := set x:int | x in se :: x; }
method set2Seq(s: set<int>) returns (se:seq<int>)
requires s != {}
ensures s == fseq2Set(se)
decreases |s|
{
var y :| y in s;
var tmp ;
if (s=={y}) {tmp := [];} else {tmp := set2Seq(s-{y});}
se := [y] + tmp;
assert (s-{y}) + {y} == fseq2Set([y] + tmp);
}
/* below fails */
function fset2Seq(s:set<int>):seq<int>
decreases s { var y :| y in s ; [y] + fset2Seq(s-{y}) }
lemma cycle(s:set<int>) ensures forall s:set<int> :: fseq2Set(fset2Seq(s)) == s { }
Ok, there is kind of a lot going on here. First of all, I'm not sure if you intended to do anything with the methods seq2Set and set2Seq, but they don't seem to be relevant to your failure, so I'm just going to ignore them and focus on the functions.
Speaking of functions, Danfy reports an error on your definition of fset2Seq, because s might be empty. In that case, we should return the empty sequence, so I adjusted your definition to:
function fset2Seq(s:set<int>):seq<int>
decreases s
{
if s == {} then []
else
var y := Pick(s);
[y] + fset2Seq(s - {y})
}
function Pick(s: set<int>): int
requires s != {}
{
var x :| x in s; x
}
which fixes that error. Notice that I also wrapped the let-such-that operator :| in a function called Pick. This is essential, but hard to explain. Just trust me for now.
Now on to the lemma. Your lemma is stated a bit weirdly, because it takes a parameter s, but then the ensures clause doesn't mention s. (Instead it mentions a completely different variable, also called s, that is bound by the forall quantifier!) So I adjusted it to get rid of the quantifier, as follows:
lemma cycle(s:set<int>)
ensures fseq2Set(fset2Seq(s)) == s
Next, I follow My Favorite Heuristic™ in program verification, which is that the structure of the proof follows the structure of the program. In this case, the "program" in question is fseq2Set(fset2Seq(s)). Starting from our input s, it first gets processed recursively by fset2Seq and then through the set comprehension in fseq2Set. So, I expect a proof by induction on s that follows the structure of fset2Seq. That structure is to branch on whether s is empty, so let's do that in the lemma too:
lemma cycle(s:set<int>)
ensures fseq2Set(fset2Seq(s)) == s
{
if s == {} {
} else {
}
...
Dafny reports an error on the else branch but not on the if branch. In other words, Dafny has proved the base case, but it needs help with the inductive case. The next thing that fset2Seq(s) does is call Pick(s). Let's do that too.
lemma cycle(s:set<int>)
ensures fseq2Set(fset2Seq(s)) == s
{
if s == {} {
} else {
var y := Pick(s);
...
Now we know from its definition that fset2Seq(s) is going to return [y] + fset2Seq(s - {y}), so we can copy-paste our ensures clause and manually substitute this expression.
lemma cycle(s:set<int>)
ensures fseq2Set(fset2Seq(s)) == s
{
if s == {} {
} else {
var y := Pick(s);
assert fseq2Set([y] + fset2Seq(s - {y})) == s;
...
Dafny reports an error on this assertion, which is not surprising, since it's just a lightly edited version of the ensures clause we're trying to prove. But importantly, Dafny no longer reports an error on the ensures clause itself. In other words, if we can prove this assertion, we are done.
Looking at this assert, we can see that fseq2Set is applied to two lists appended together. And we would expect that to be equivalent to separately converting the two lists to sets, and then taking their union. We could prove a lemma to that effect, or we could just ask Dafny if it already knows this fact, like this:
lemma cycle(s:set<int>)
ensures fseq2Set(fset2Seq(s)) == s
{
if s == {} {
} else {
var y := Pick(s);
assert fseq2Set([y] + fset2Seq(s - {y})) == fseq2Set([y]) + fseq2Set(fset2Seq(s - {y}));
assert fseq2Set([y] + fset2Seq(s - {y})) == s;
...
(Note that the newly added assertion is before the last one.)
Dafny now accepts our lemma. We can clean up a little by deleting the the base case and the final assertion that was just a copy-pasted version of our ensures clause. Here is the polished proof.
lemma cycle(s:set<int>)
ensures fseq2Set(fset2Seq(s)) == s
{
if s != {} {
var y := Pick(s);
assert fseq2Set([y] + fset2Seq(s - {y})) == fseq2Set([y]) + fseq2Set(fset2Seq(s - {y}));
}
}
I hope this explains how to prove the lemma and also gives you a little bit of an idea about how to make progress when you are stuck.
I did not explain Pick. Basically, as a rule of thumb, you should just always wrap :| in a function whenever you use it. To understand why, see the Dafny power user posts on iterating over collecion and functions over set elements. Also, see Rustan's paper Compiling Hilbert's epsilon operator.
Currently, I'm trying to build a trait for a BinaryTree in Dafny.
The following error occurs for the implementation of the Insert method in the class:
the method must provide an equal or more permissive precondition than
in its parent trait
Why does this error occur, even if the same preconditions exist for the method in the trait and in the class?
This is the trait:
trait DataStorage {
ghost var Contents: set<int>
ghost var Repr: set<object>
method Insert(val: int)
modifies this, Repr
requires Valid()
ensures Valid() && fresh(Repr - old(Repr))
ensures Contents == old(Contents) + {val}
predicate Valid()
reads this, Repr
(...)
}
An this is the corresponding implementation
class BinaryTree extends DataStorage {
var root: Node?;
predicate Valid()
reads this, Repr
{
this in Repr &&
(root == null ==> Contents == {}) &&
(root != null ==>
root in Repr && root.Repr <= Repr && this !in root.Repr &&
root.Valid() &&
Contents == root.Contents)
}
method Insert(val: int)
requires Valid()
modifies Repr
ensures Valid() && fresh(Repr - old(Repr))
ensures Contents == old(Contents) + {val}
{
var n := insert_helper(root, val);
root := n;
Contents := root.Contents;
Repr := root.Repr + {this};
}
(...)
}
I have a class that allocates an iterator on the heap and calls MoveNext() on that iterator. I want to prove that if MoveNext() returns true, Valid() holds for the iterator.
iterator Iter()
{}
class MyClass
{
var iter : Iter;
constructor ()
{
iter := new Iter();
}
method next() returns (more : bool)
requires iter.Valid();
modifies iter, iter._new, iter._modifies;
{
more := iter.MoveNext();
// This assertion fails:
assert more ==> iter.Valid();
}
}
I took a look at the output of /rprint, and the method MoveNext() contains ensures more ==> this.Valid(), which seems to imply my desired assertion. If I change iter to be locally allocated within the method next(), then Dafny verifies the assertion.
The problem is that nothing is known about what's in iter._new and iter._modifies. If this is in one of those sets, then this.iter may have changed during the call to MoveNext().
This body for next() confirms what I just said:
var i := iter;
more := iter.MoveNext();
assert i == iter; // this assertion fails
assert more ==> iter.Valid();
So, under the assumption more, Valid() does still hold of the iterator, but the iterator may no longer referenced by iter:
more := iter.MoveNext();
assert more ==> old(iter).Valid(); // this holds
Probably the way you want to solve this problem is to add a precondition to next():
method next() returns (more : bool)
requires iter.Valid()
requires this !in iter._new + iter._modifies // add this precondition
modifies iter, iter._new, iter._modifies
{
more := iter.MoveNext();
assert more ==> iter.Valid(); // this now verifies
}
Rustan
I'm confused about Dafny's forall statement if the statement inside the forall is to update a variable such as c.arr[i].d, which is mixed with field and array element access. For instance, the example as follows can't be compiled.
I think, explicitly indicating modifies clause is very tedious, I need indicate: modifies top, modifies top.Cache[i]
datatype CACHE_STATE = I| S| E
datatype MSG_CMD = Empty| ReqS| ReqE| Inv| InvAck| GntS| GntE
type NODE=nat
type DATA=nat
type boolean=bool
class class_0 {
var
Data : DATA,
Cmd : MSG_CMD
}
class class_1 {
var
Data : DATA,
State : CACHE_STATE
}
class TopC{
var
AuxData : DATA,
MemData : DATA,
CurPtr : NODE,
CurCmd : MSG_CMD,
ExGntd : boolean,
ShrSet : array<boolean>,
InvSet : array<boolean>,
Chan3 : array<class_0 > ,
Chan2 : array<class_0 > ,
Chan1 : array<class_0 > ,
Cache : array<class_1 > }
method n_RecvReqS(top:TopC,i:nat, N0:nat )
requires 0<= i<N0
requires top.Chan1.Length ==N0
requires N0>0
requires top.InvSet.Length ==N0
requires N0>0
requires top.ShrSet.Length ==N0
requires N0>0
requires top.Cache.Length ==N0
requires ((top.Chan1[i].Cmd == ReqS) && (top.CurCmd == Empty))
modifies top.Chan1[i]
modifies top.InvSet
modifies top.ShrSet
modifies top
modifies top.Cache
{
top.CurCmd := ReqS;
top.CurPtr := i;
top.Chan1[i].Cmd := Empty;
forall j | 0<= j< N0 {
top.InvSet[j] := top.ShrSet[j];
}
forall j | 0<= j< N0 {
top.Cache[j].State:= I;
}
}
Knowing about a method's effect on the heap is crucial to verification, though writing modifies clauses can be tedious. In your case, you need to account for all of the modifications that method n_RecvReqS performs. As you've noted, this includes every top.Cache[j] objects, for all j's.
One way to include these in your modifies clause is to use a set comprehension:
modifies set j | 0 <= j < top.Cache.Length :: top.Cache[j]
This denotes the set of the objects top.Cache[j], where j ranges among the values satisfying 0 <= j < top.Cache.Length.
Read on for further options.
If you do this often and you consider all of these caches to be part of the representation of a TopC object, then you'll probably want to abstract over the many pieces of your state and put these into a set. If you search the Dafny test suite for declarations like
ghost var Repr: set<object>
you'll find some examples. Then, your entire modifies clause would just be
modifies Repr
If you're not ready to use such a Repr set yet, then there's another simple modifies clause you can write for the cache modifications in your program. If you list a sequence of objects in a modifies clause, Dafny will automatically convert it to the corresponding set of objects. You can convert all of the array elements of top.Cache into a sequence by the expression top.Cache[..]. Thus, to account for the updates in your forall statement, you can write
modifies top.Cache[..]
Unfortunately, Dafny doesn't automatically realize that each top.Cache[j] in the body of your forall statement is indeed an element of the set formed from the sequence top.Cache[..]. It is possible to assist the verifier to help it prove this, but doing so adds some clutter to the forall statement. Here's how I did it:
forall j | 0 <= j < N0 {
(assert top.Cache[j] in top.Cache[..]; top.Cache[j]).State:= I;
}
Rustan