11

I want to provide proofs for parts of a Haskell program I'm writing as part of my thesis. So far however, I failed to find a good reference work.

Graham Hutton's introductory book Programming in Haskell (Google Books)—which I read while learning Haskell—touches on a few techniques for reasoning about programs such as

  • equational reasoning
  • using non-overlapping patterns
  • list induction

in chapter 13 but it's not very in-depth.

Are there any books or article you can recommend which provide a more detailed overview of formal proving techniques for Haskell, or other functional, code?

Raphael
  • 72,336
  • 29
  • 179
  • 389
FK82
  • 273
  • 2
  • 8

4 Answers4

6

You can start with

Topics include basic concepts of logic, computer-assisted theorem proving, the Coq proof assistant, functional programming, operational semantics, Hoare logic, and static type systems. The exposition is intended for a broad range of readers, from advanced undergraduates to PhD students and researchers. No specific background in logic or programming languages is assumed, though a degree of mathematical maturity will be helpful.

You can skip (or skim) the programming language theory parts and only learn how to deal with formal proofs starting from Preface up to IndPrinciples. The book is really well-written and illuminating.

Then you might want to proceed with

In this volume you will learn how to specify and verify (prove the correctness of) sorting algorithms, binary search trees, balanced binary search trees, and priority queues. Before using this book, you should have some understanding of these algorithms and data structures, available in any standard undergraduate algorithms textbook. You should understand all the material in Software Foundations Volume 1 (Logic Foundations)

A note of warning: VFA is still in beta-release!

Anton Trunov
  • 3,469
  • 1
  • 18
  • 26
  • (Your second link directs to the wrong place.) Also, there is Verified Functional Programming in Agda; which uses Agda, formally a programming language but uses unicode and so is closer to math notation. – Musa Al-hassy Sep 14 '16 at 14:57
  • Corrected, thanks. Yes, I've read VFPiA, but it is not to my taste. – Anton Trunov Sep 14 '16 at 17:11
  • Thank you for your answer! I think there is a misconception. I'm not looking for functional techniques for proving algorithms (such as a proof assistant), but for techniques for proving functional code (for example for proving a functional implementation of a given algorithm correct) @MusaAl-hassy answer is very close to my desired answer. In case I missed it and the books you cited cover this aspect as well, would you mind adding the relevant chapters? – FK82 Sep 17 '16 at 14:22
  • @FK82 Here is a Theorem app_assoc : ∀ l1 l2 l3 : natlist, (l1 ++ l2) ++ l3 = l1 ++ (l2 ++ l3) from the Lists chapter. Does this example look anything like the thing you're interested in? They start with functional programming in Coq, but then move on to reasoning about the properties of functional programs. The chapters from Preface up to IndPrinciples cover both of those, and I'd say programming and reasoning are intertwined there. – Anton Trunov Sep 17 '16 at 15:34
  • @AntonTrunov Well, i see now that the authors explain some proof techniques in Basics. The thing is, they draw on Coq for the proofs. What I'm looking for are formal techniques to reason about code much like how you would reason about mathematics. For example in the case of the list concatenation associativity theorem, I would like to argue on the basis of a kind of algebra for lists and list operations which can be ported to a functional language. – FK82 Sep 18 '16 at 11:51
  • For example, in case of the list append theorem, I would like to argue by induction: (1) basic case (l_1 ++ []) ++ l_3 == l_1 ++ l_3 == l_1 ++ ([] ++ l_3), (2) induction step, assume the theorem to be proven for a list l_2 with length n then for a list (l_2 : e) with length n + 1 it holds that (l_1 ++ (l_2 : e)) ++ l_3 == (l_1 ++ l_2) ++ (e : l_3) == l_1 ++ (l_2 ++ (e : l_3)) == l_1 ++ ((l_2 : e) ++ l_3) when applying the induction hypothesis in the second to last step. QED. – FK82 Sep 18 '16 at 12:05
  • @FK82 (1) I'm not sure I follow... Coq is exactly used for formal reasoning about code and about mathematics as well. E.g., it was used to formally prove the four color theorem. You can prove the associativity of list concatenation in Coq by using its tactics to build proofs, or you can build the proof terms explicitly. – Anton Trunov Sep 18 '16 at 12:36
  • @FK82 (2) Coq also has the Mathematical Proof Language which allows your proofs to look like the equational reasoning you provided as an example above. From wiki: "It allows the expression of mathematical assertions, mechanically checks proofs of these assertions, helps to find formal proofs, and extracts a certified program from the constructive proof of its formal specification." – Anton Trunov Sep 18 '16 at 12:38
  • @AntonTrunov So, yeah I'm probably not very clear about what I want. Let me explain. From what I understand, I can use Coq to proof an algorithm. This is fine and dandy, but not what I want in two ways: (1) I want to proof that for an algorithm—which is already proven to be correct—my implementation in Haskell is correct (and not vice versa); (2) I want to use a formal proof technique, i.e. something that I can ideally do with pen & paper only (as in the example above). I might be misunderstanding Coq, but I think it's not designed to do that. – FK82 Sep 18 '16 at 13:54
  • 1
    @FK82 (1) I totally agree with this comment. (2) You might want to look at the book "Thinking Functionally with Haskell" (2015) by R. Bird. The book has tons of examples of reasoning about Haskell. (3) Also, "Pearls of Functional Algorithm Design" (2010) by the same author may be of some help to you. – Anton Trunov Sep 18 '16 at 15:38
5

One of the de facto methods for proving results in functional programming is via Richard Bird's group.

In particular, you ask for an in-depth or at least more comprehensive approach to equational reasoning and list induction and this is provided in Lectures on Constructive Functional Programming.

More generally, the text "Algebra of Programming", by Bird and de Moor, also deals with the correctness of functional algorithms such as optimisation and dynamic programming problems.

If you come across other useful resources for this problem, please mention them and perhaps we can turn this post into a wiki.

Musa Al-hassy
  • 884
  • 1
  • 5
  • 9
  • Thank you! Sure, if I find more ressources, I will make sure to add them to my post. – FK82 Sep 12 '16 at 16:27
5

It turns out that an excellent source of proof techniques and examples for proving things about pure functional languages is proof assistants which usually include as part of their specification language a pure functional language on which it is possible to reason equationally.

One might want to consult a book like Certified Programing with Dependent Types for an in-depth introduction to this kind of reasoning in a specific proof assistant, namely Coq.

cody
  • 8,184
  • 29
  • 62
  • Thanks! I'm actually looking specifically for techniques in Haskell. My post was edited to include all functional code, but that's well above my intentions. – FK82 Sep 17 '16 at 14:25
  • 1
    I'm not aware of systems designed to verify Haskell specifically, but I would note that 1) The functional core of Coq (and Agda) is essentially indistinguishable from that of Haskell (except for the restriction to total functions) and 2) Programs verified in Coq and Agda can be extracted to Haskell (though I believe extraction to Haskell is better supported in Agda, where Coq is more Ocaml-centric) – cody Sep 18 '16 at 13:13
  • Good to know! This would however imply that I rewrite my program (or the relevant parts) in Coq or Agda. I don't think that's reasonable in my case. – FK82 Sep 19 '16 at 13:40
  • There are a couple of very experimental "front ends" that try to convert Haskell to Isabelle or directly prove equivalences using Isabelle, but I wouldn't hold too much stock in their maturity. I think re-writing the code would ultimately be less work. – cody Sep 19 '16 at 15:37
4

I suggest to use program logics. They deal much better with effects than typing systems.

There are numerous program logics for functional languages. This becomes interesting with effects. See e.g. Logical Reasoning for Higher-Order Functions with Local State.

Work by Arthur Charguéraud integrates the program logic approach with proof assistants, see e.g. this overview page.

Martin Berger
  • 8,308
  • 27
  • 45