Latest revision as of 15:52, 22 February 2012

Contents

Zeno is an automated proof system for Haskell program properties; developed at Imperial College London by William Sonnex, Sophia Drossopoulou and Susan Eisenbach. It aims to solve the general problem of equality between two Haskell terms, for any input value.

Many program verification tools available today are of the model checking variety; able to traverse a very large but finite search space very quickly. These are well suited to problems with a large description, but no recursive datatypes. Zeno on the other hand is designed to inductively prove properties over an infinite search space, but only those with a small and simple specification.

One can try Zeno online at TryZeno, or cabal install zeno to use it from home. You can find the latest paper on Zeno here, though please note that Zeno no longer uses the described proof output syntax but instead outputs proofs as Isabelle theories.

functions from being imported, this is important as we have no source code available for them; Zeno can only work with functions for which it can see the definition. The only built-in Haskell types we have are lists and tuples, which are automatically available, and

Bool

, which Zeno.hs will import for you.
Now that we have some code we can define a property about this code. Equality is expressed using the

(:=:)

constructor defined in Zeno.hs. We then pass this to the

prove

function to turn an equality into a property (

Prop

).

The following code will express that the length of two appended lists is the sum of their individual lengths:

prop_length xs ys
= prove (length(xs ++ ys) :=: length xs +length ys)

Add this to the above code and save it to Test.hs. We can now check

prop_length

by running zeno Test.hs. As a bug/feature this will also check

Zeno.proveBool

, a helper function in Zeno.hs, as this looks like a property. To restrict this to just

prop_length

we can run zeno -m prop Test.hs, which will only check properties whose name contains the text prop.
Say we want to express arbitrary propositions, we can do an equality check with

No non-terminating definitions. This also means you cannot use default type-class methods, as GHC transforms these internally to a co-recursive value. Isabelle will check for termination but Zeno will not, unfortunately this means that Zeno could be thrown into an infinite loop with such a definition.

While the above restrictions are founded in Isabelle's input language there are a few which are just laziness on part of Zeno's developers, and on our to-do list:

No partial definitions; only use total pattern matches.

No mututally recursive datatypes.

No tuple types beyond quadruples.

No name clashes, even across modules. Zeno will automatically strip module names in its output for clarity, and we have not yet implemented a flag to control this.

If you are wondering why a certain bit of code cannot be converted to Isabelle try running Zeno with the --print-core flag, this will output Zeno's internal representation for your code.

When we said that Zeno proves properties of Haskell programs this wasn't entirely true, it only proves those for which every value is finite and well-defined. For example, Zeno can prove

reverse(reverse xs)= xs

, which is not true for infinite lists, as

xs

could still be pattern matched upon, whereas evaluating

reverse(reverse xs)

starts an infinite loop (

undefined

).
Another example (courtesy of Tillmann Rendel) is

takeWhile p xs ++dropWhile p xs = xs

, which Zeno will prove but in fact is not true when

p =constundefined

and

xs /=[]

, as the left hand side of the equality would be

undefined

.

You might ask why this is a Haskell theorem prover, rather than an ML one, if it cannot deal with infinite values, which would be a very valid question. As it stands Zeno is more a base-line for us to start more advanced research into lazy functional program verification, which will include attempting to tackle this issue.