--- layout: post title: "Talking About Sets" date: 2013-03-26 16:12 comments: true external-url: categories: basic measures sets author: Ranjit Jhala published: true demo: TalkingAboutSets.hs --- In the posts so far, we've seen how LiquidHaskell allows you to use SMT solvers to specify and verify *numeric* invariants -- denominators that are non-zero, integer indices that are within the range of an array, vectors that have the right number of dimensions and so on. However, SMT solvers are not limited to numbers, and in fact, support rather expressive logics. In the next couple of posts, let's see how LiquidHaskell uses SMT to talk about **sets of values**, for example, the contents of a list, and to specify and verify properties about those sets. \begin{code} module TalkingAboutSets where import Data.Set hiding (filter, split) import Prelude hiding (reverse, filter) \end{code} Talking about Sets (In Logic) ============================= First, we need a way to talk about sets in the refinement logic. We could roll our own special Haskell type, but why not just use the `Set a` type from `Data.Set`. The `import Data.Set` , also instructs LiquidHaskell to import in the various specifications defined for the `Data.Set` module that we have *predefined* in [Data/Set.spec][setspec] \begin{code} Let's look at the specifications. module spec Data.Set where embed Set as Set_Set \end{code} The `embed` directive tells LiquidHaskell to model the **Haskell** type constructor `Set` with the **SMT** type constructor `Set_Set`. \begin{code} First, we define the logical operators (i.e. `measure`s) measure Set_sng :: a -> (Set a) -- ^ singleton measure Set_cup :: (Set a) -> (Set a) -> (Set a) -- ^ union measure Set_cap :: (Set a) -> (Set a) -> (Set a) -- ^ intersection measure Set_dif :: (Set a) -> (Set a) -> (Set a) -- ^ difference \end{code} \begin{code} Next, we define predicates on `Set`s measure Set_emp :: (Set a) -> Prop -- ^ emptiness measure Set_mem :: a -> (Set a) -> Prop -- ^ membership measure Set_sub :: (Set a) -> (Set a) -> Prop -- ^ inclusion \end{code} Interpreted Operations ---------------------- The above operators are *interpreted* by the SMT solver. \begin{code} That is, just like the SMT solver "knows that" 2 + 2 == 4 \end{code} \begin{code} the SMT solver also "knows that" (Set_sng 1) == (Set_cap (Set_sng 1) (Set_cup (Set_sng 2) (Set_sng 1))) \end{code} This is because, the above formulas belong to a decidable Theory of Sets which can be reduced to McCarthy's more general [Theory of Arrays][mccarthy]. See [this recent paper][z3cal] if you want to learn more about how modern SMT solvers "know" the above equality holds... Talking about Sets (In Code) ============================ Of course, the above operators exist purely in the realm of the refinement logic, beyond the grasp of the programmer. To bring them down (or up, or left or right) within reach of Haskell code, we can simply *assume* that the various public functions in `Data.Set` do the *Right Thing* i.e. produce values that reflect the logical set operations: \begin{code} First, the functions that create `Set` values empty :: {v:(Set a) | (Set_emp v)} singleton :: x:a -> {v:(Set a) | v = (Set_sng x)} \end{code} \begin{code} Next, the functions that operate on elements and `Set` values insert :: Ord a => x:a -> xs:(Set a) -> {v:(Set a) | v = (Set_cup xs (Set_sng x))} delete :: Ord a => x:a -> xs:(Set a) -> {v:(Set a) | v = (Set_dif xs (Set_sng x))} \end{code} \begin{code} Then, the binary `Set` operators union :: Ord a => xs:(Set a) -> ys:(Set a) -> {v:(Set a) | v = (Set_cup xs ys)} intersection :: Ord a => xs:(Set a) -> ys:(Set a) -> {v:(Set a) | v = (Set_cap xs ys)} difference :: Ord a => xs:(Set a) -> ys:(Set a) -> {v:(Set a) | v = (Set_dif xs ys)} \end{code} \begin{code} And finally, the predicates on `Set` values: isSubsetOf :: Ord a => xs:(Set a) -> ys:(Set a) -> {v:Bool | (Prop v) <=> (Set_sub xs ys)} member :: Ord a => x:a -> xs:(Set a) -> {v:Bool | (Prop v) <=> (Set_mem x xs)} \end{code} **Note:** Of course we shouldn't and needn't really *assume*, but should and will *guarantee* that the functions from `Data.Set` implement the above types. But thats a story for another day... Proving Theorems With LiquidHaskell =================================== OK, let's take our refined operators from `Data.Set` out for a spin! One pleasant consequence of being able to precisely type the operators from `Data.Set` is that we have a pleasant interface for using the SMT solver to *prove theorems* about sets, while remaining firmly rooted in Haskell. First, let's write a simple function that asserts that its input is `True` \begin{code} {-@ boolAssert :: {v: Bool | (Prop v)} -> {v:Bool | (Prop v)} @-} boolAssert True = True boolAssert False = error "boolAssert: False? Never!" \end{code} Now, we can use `boolAssert` to write some simple properties. (Yes, these do indeed look like QuickCheck properties -- but here, instead of generating tests and executing the code, the type system is proving to us that the properties will *always* evaluate to `True`) Let's check that `intersection` is commutative ... \begin{code} prop_cap_comm x y = boolAssert $ (x `intersection` y) == (y `intersection` x) \end{code} that `union` is associative ... \begin{code} prop_cup_assoc x y z = boolAssert $ (x `union` (y `union` z)) == (x `union` y) `union` z \end{code} and that `union` distributes over `intersection`. \begin{code} prop_cap_dist x y z = boolAssert $ (x `intersection` (y `union` z)) == (x `intersection` y) `union` (x `intersection` z) \end{code} Of course, while we're at it, let's make sure LiquidHaskell doesn't prove anything that *isn't* true ... \begin{code} prop_cup_dif_bad x y = boolAssert $ x == (x `union` y) `difference` y \end{code} Hmm. You do know why the above doesn't hold, right? It would be nice to get a *counterexample* wouldn't it? Well, for the moment, there is QuickCheck! Thus, the refined types offer a nice interface for interacting with the SMT solver in order to prove theorems in LiquidHaskell. (BTW, The [SBV project][sbv] describes another approach for using SMT solvers from Haskell, without the indirection of refinement types.) While the above is a nice warm up exercise to understanding how LiquidHaskell reasons about sets, our overall goal is not to prove theorems about set operators, but instead to specify and verify properties of programs. The Set of Values in a List =========================== Let's see how we might reason about sets of values in regular Haskell programs. We'll begin with Lists, the jack-of-all-data-types. Now, instead of just talking about the **number of** elements in a list, we can write a measure that describes the **set of** elements in a list: \begin{code} A measure for the elements of a list, from [Data/Set.spec][setspec] measure listElts :: [a] -> (Set a) listElts ([]) = {v | (? Set_emp(v))} listElts (x:xs) = {v | v = (Set_cup (Set_sng x) (listElts xs)) } \end{code} That is, `(listElts xs)` describes the set of elements contained in a list `xs`. Next, to make the specifications concise, let's define a few predicate aliases: \begin{code} {-@ predicate EqElts X Y = ((listElts X) = (listElts Y)) @-} {-@ predicate SubElts X Y = (Set_sub (listElts X) (listElts Y)) @-} {-@ predicate UnionElts X Y Z = ((listElts X) = (Set_cup (listElts Y) (listElts Z))) @-} \end{code} A Trivial Identity ------------------ OK, now let's write some code to check that the `listElts` measure is sensible! \begin{code} {-@ listId :: xs:[a] -> {v:[a] | (EqElts v xs)} @-} listId [] = [] listId (x:xs) = x : listId xs \end{code} That is, LiquidHaskell checks that the set of elements of the output list is the same as those in the input. A Less Trivial Identity ----------------------- Next, let's write a function to `reverse` a list. Of course, we'd like to verify that `reverse` doesn't leave any elements behind; that is that the output has the same set of values as the input list. This is somewhat more interesting because of the *tail recursive* helper `go`. Do you understand the type that is inferred for it? (Put your mouse over `go` to see the inferred type.) \begin{code} {-@ reverse :: xs:[a] -> {v:[a] | (EqElts v xs)} @-} reverse = go [] where go acc [] = acc go acc (y:ys) = go (y:acc) ys \end{code} Appending Lists --------------- Next, here's good old `append`, but now with a specification that states that the output indeed includes the elements from both the input lists. \begin{code} {-@ append :: xs:[a] -> ys:[a] -> {v:[a]| (UnionElts v xs ys)} @-} append [] ys = ys append (x:xs) ys = x : append xs ys \end{code} Filtering Lists --------------- Let's round off the list trilogy, with `filter`. Here, we can verify that it returns a **subset of** the values of the input list. \begin{code} {-@ filter :: (a -> Bool) -> xs:[a] -> {v:[a]| (SubElts v xs)} @-} filter f [] = [] filter f (x:xs) | f x = x : filter f xs | otherwise = filter f xs \end{code} Merge Sort ========== Let's conclude this entry with one larger example: `mergeSort`. We'd like to verify that, well, the list that is returned contains the same set of elements as the input list. And so we will! But first, let's remind ourselves of how `mergeSort` works: 1. `split` the input list into two halves, 2. `sort` each half, recursively, 3. `merge` the sorted halves to obtain the sorted list. Split ----- We can `split` a list into two, roughly equal parts like so: \begin{code} split [] = ([], []) split (x:xs) = (x:zs, ys) where (ys, zs) = split xs \end{code} LiquidHaskell verifies that the relevant property of split is \begin{code} {-@ split :: xs:[a] -> ([a], [a])<{\ys zs -> (UnionElts xs ys zs)}> @-} \end{code} The funny syntax with angle brackets simply says that the output of `split` is a *pair* `(ys, zs)` whose union is the list of elements of the input `xs`. (Yes, this is indeed a dependent pair; we will revisit these later to understand whats going on with the odd syntax.) Merge ----- Next, we can `merge` two (sorted) lists like so: \begin{code} merge xs [] = xs merge [] ys = ys merge (x:xs) (y:ys) | x <= y = x : merge xs (y : ys) | otherwise = y : merge (x : xs) ys \end{code} As you might expect, the elements of the returned list are the union of the elements of the input, or as LiquidHaskell might say, \begin{code} {-@ merge :: (Ord a) => x:[a] -> y:[a] -> {v:[a]| (UnionElts v x y)} @-} \end{code} Sort ---- Finally, we put all the pieces together by \begin{code} {-@ mergeSort :: (Ord a) => xs:[a] -> {v:[a] | (EqElts v xs)} @-} mergeSort [] = [] mergeSort [x] = [x] mergeSort xs = merge (mergeSort ys) (mergeSort zs) where (ys, zs) = split xs \end{code} The type given to `mergeSort`guarantees that the set of elements in the output list is indeed the same as in the input list. Of course, it says nothing about whether the list is *actually sorted*. Well, Rome wasn't built in a day... [sbv]: https://github.com/LeventErkok/sbv [setspec]: https://github.com/ucsd-progsys/liquidhaskell/blob/master/include/Data/Set.spec [mccarthy]: http://www-formal.stanford.edu/jmc/towards.ps [z3cal]: http://research.microsoft.com/en-us/um/people/leonardo/fmcad09.pdf