Haskell meets Evariste

Since its birth as a new scientific body of knowledge in the late 1950s, computer programming has become a fundamental skill needed in many other disciplines. However, programming is not easy, it is prone to errors and code re-use is key for productivity. This calls for high-quality documentation in software libraries, which is quite often not the case. Taking a few Haskell functions available from the Hackage repository as case-studies, and comparing their descriptions with similar functions in other languages, this paper shows how clarity and good conceptual design can be achieved by following a so-called easy-hard-split formal strategy that is quite general and productive, even if used informally. This strategy is easy to use in functional programming and can be applied to both program analysis and synthesis.

💡 Research Summary

The paper “Haskell meets Evariste” investigates the chronic problem of vague documentation in software libraries, focusing on functional programming languages and, in particular, on a handful of list‑manipulating functions from Haskell’s Hackage repository. The authors begin by observing that modern programming education suffers from a dual deficiency: students often lack strong mathematical reasoning skills and also struggle with reading comprehension. Consequently, textual specifications of library functions are frequently ambiguous, leading programmers to either misinterpret the behavior of imported functions or to rely on informal, error‑prone mental models.

To address this, the authors adopt Carroll Morgan’s “go formal informally” principle and formalize it as an “easy‑hard‑split” strategy. In the “easy” part, a function’s specification is broken down into simple, universally true relational properties that admit many possible implementations (a binary relation). In the “hard” part, an additional constraint selects the optimal solution from those possibilities, typically expressed with a superlative such as “longest” or “smallest”. This two‑stage pattern yields a specification that is both readable and amenable to formal reasoning.

The paper uses the Haskell function takeWhile as a running example. The Data.List documentation reads: “A prefix of a list xs that satisfies a predicate p, possibly empty, and the longest such prefix.” The authors translate this into a formal equivalence:

 ys ≼ xs ∧ all p ys ⇔ ys ≼ takeWhile p xs

where ≼ denotes the prefix (pre‑fix) relation, a partial order on lists (reflexive, transitive, antisymmetric). They show that this relation captures the “easy” constraints (ys is a prefix of xs and every element of ys satisfies p) while the “hard” constraint is the maximality (ys is the longest such prefix).

By treating the prefix relation as a partial order, the authors invoke an “indirect equality” principle: two lists are equal iff they have exactly the same set of prefixes. This principle, originally noted by Dijkstra, allows them to prove several useful properties of takeWhile. For instance, they derive the composition law

 takeWhile p ∘ takeWhile q = takeWhile (p ∧ q)

by chaining the formal specification and using associativity of conjunction. They also prove the base case `takeWhile