Prove program equations with GHC ================================ This GHC plugin allows you to embed code equation into your code, and have them checked by GHC. Synopsis -------- See the `GHC.Proof` module for the documentation, but there really isn't much more to it than: ```haskell {-# OPTIONS_GHC -O -fplugin GHC.Proof.Plugin #-} module Simple where import GHC.Proof import Data.Maybe my_proof1 = (\f x -> isNothing (fmap f x)) === (\f x -> isNothing x) ``` If you compile this, you will reassurringly read: ``` $ ghc Simple.hs [1 of 1] Compiling Simple ( Simple.hs, Simple.o ) GHC.Proof: Proving my_proof1 … GHC.Proof proved 1 equalities ``` See the [`examples/`](examples/) directory for more examples of working proofs (with GHC HEAD). If you have proof that GHC cannot prove, for example ```haskell not_a_proof = (2+2::Int) === (5::Int) ``` then the compiler will tell you so, and abort the compilation: ``` $ ghc Simple.hs [1 of 1] Compiling Simple ( Simple.hs, Simple.o ) GHC.Proof: Proving not_a_proof … Proof failed Simplified LHS: GHC.Types.I# 4# Simplified RHS: GHC.Types.I# 5# Differences: • 4# /= 5# Simple.hs: error: GHC.Proof could not prove all equalities ``` How does it work? ----------------- GHC is a mighty optimizing compiler, and the centerpiece of optimizing, the *simplifier* is capable of quite a bit of symbolic execution. We can use this to prove program equalities, simply by taking two expressions, letting GHC simplify them as far as possible. If the resulting expressions are the same, then the original expressions are – as far as the compiler is concerned – identicial. The GHC simplifier works on the level of the intermediate language GHC Core, and failed proofs will be reported as such. The gory details are as follows: The simplifier is run 8 times, twice for each of the simplifier phases 4, 3, 2 and 1. In between, the *occurrence analiser* is run. Near the end, we also run *common-subexpression elimination*. The simplifier is run with more aggressive flags. In particular, it is instructed to inline functions aggressively and without worrying about code size. Why is this so great? --------------------- * You can annotate your code with proofs, in the same file, in the same language, without extra tools (besides the plugin). * The proofs stay with the code and are run with every compilation. * The proof goes through when *the compiler* thinks the expressions are the same. There is no worry about whether an external proof tools captures the semantics of GHC’s Haskell precisely. * It suports, in principle, all of Haskell’s syntax, including a huge number of extensions. * It is super easy (if it works). * Using rewrite rules allows proofs with regard to some theory (e.g. with regard to equations about `foldr` and other list combinators), independent of whether these are proven. Why is this not so great? -------------------- * It can only prove quite simple things right now. * Even for easy things, the proof might fail because GHC simply simplifies the expressions slightly different, and there is not always an easy way of fixing this. * The proofs depend on optimization flags. * There is no guarantee that the next GHC release will be able to prove the same things. * Failed proofs are reported in GHC Core instead of Haskell. * At least currently, it more or less requires GHC HEAD (it compiles with GHC-8.0, but it has less control over the simplifier and less proofs will go through.) What can it prove? ------------------ Not everything. By far. But some nice, practical results work, see for example the [proofs of the `Applicative` and `Monad` laws for `Control.Applicative.Succs`](examples/Successors.hs). Best results were observed with compositions of non-recursive functions that handle non-recursive data or handle lists usind standard list combinators. The GHC simplifier generally refuses to inline recursive functions, so there is not much we can do with these for now. My proof is not found. What can I do? ------------------------------------- The plugin searches for top-level bindings of the form ```haskell somename = proof expression1 expression2 ``` or ```haskell somename = expression1 === expression2 ``` GHC will drop them before the plugin sees them, though, if `somename` is not exported, so make sure it is exported. If you really do not want to export it, then you can keep it alive using the trick of ```haskell {-# RULES "keep somename alive" id somename = somename #-} ``` If it still does not work, check the output of `-dverbose-core2core` for why your binding does not have the expected form. Maybe you can fix it somehow. My proof does not go through. Can I fix that? --------------------------------------------- Maybe. Here are some tricks that sometimes help: * Check if your functions are properly unfolded in the proof. Maybe an `INLINEABLE` pragma helps. * Use `{-# LANGUAGE BangPatterns #-}` and mark some arguments as strict: ```haskell my_proof2 = (\d !x -> fromMaybe d x) === (\d !x -> maybe d id x) ``` GHC makes these functions strict by putting the body in a case. This has roughly the same effect as s *case split* in interactive theorem proving. * Allow GHC to assume one of your functions is strict: ```haskell str :: (a -> b) -> (a -> b) str f x = x `seq` f x monad_law_3 = (\ (x::Succs a) k h -> x >>= (\x -> k x >>= str h)) === (\ (x::Succs a) k h -> (x >>= k) >>= str h) ``` * Instead of using recursion, try to use combinators (e.g. `filter`, `map`, `++` etc.). * Add rewrite rules to tell GHC about some program equations that it should use while simplifying. This is in particular useful when working with list functions Here are some examples: ```haskell {-# RULES "mapFB/id" forall c . mapFB c (\x -> x) = c #-} {-# RULES "foldr/nil" forall k n . GHC.Base.foldr k n [] = n #-} {-# RULES "foldr/mapFB" forall c f g n1 n2 xs. GHC.Base.foldr (mapFB c f) n1 (GHC.Base.foldr (mapFB (:) g) n2 xs) = GHC.Base.foldr (mapFB c (f.g)) (GHC.Base.foldr (mapFB c f) n1 n2) xs #-} ``` But note that these apply to your whole module, and are exported from it, so you should not attempt to add such a rule to the same module where you prove the rule. And if you don’t want these rules to be applied in normal code, put your proofs into a separate `Proof` module that is never imported. Shall I use this in production? ------------------------------- You can try. It certainly does not hurt, and proofs that go through are fine. It might not prove enough to be really useful. What next? ---------- It remains to be seen how useful this approach really is, and what can be done to make it more useful. So we need to start proving some things. Here are some aspects that likely need to be improved: * The user should be put into control of some of the simplifier settings. Depending on the proof, one might want to go through more or less of the simplifier phases, or disable and enable certain rules. * Maybe a syntax that does not abuse term-level bindings can be introduced. Currently, though, this is not possible for a plugin. * If deemed useful, this functionaly maybe can become part of GHC, and the simplifier could get a few extra knobs to turn. * A custom function to compare expressions that relates more than just alpha-equivalence could expand the scope of this plugin. * The reporting of failed proofs can be improved. * Come up with a better story about recursive functions. How else can I prove things about Haskell? ------------------------------------------ * Wait for full dependent types in Haskell and express your equivalences as types. * Manually or mechanically (e.g. using [Haskabelle](https://isabelle.in.tum.de/haskabelle.html)) rewrite your code in a theorem prover such as [Isabelle](http://isabelle.in.tum.de/), [Agda](http://wiki.portal.chalmers.se/agda/pmwiki.php) or [Coq](https://coq.inria.fr/), and prove stuff there. * Write your code in these theorem provers in the first place and export them to Haskell. * You might be able to prove a few things using [Liquid Haskell](https://ucsd-progsys.github.io/liquidhaskell-blog/) or, actually quite similar to this, [HERMIT](http://ku-fpg.github.io/software/hermit/). Can I comment or help? ---------------------- Sure! We can use the GitHub issue tracker for discussions, and obviously contributions are welcome.