Theorem proving for all: equational reasoning in liquid Haskell (functional pearl)

Vazou, Niki; Breitner, Joachim; Kunkel, Rose; Horn, David Van; Hutton, Graham

doi:10.1145/3299711.3242756

Cited by 6 publications

(5 citation statements)

References 26 publications

(33 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Finally, language-based approaches offer an alternative path to the verification of software. Liquid Haskell [34] extends standard Haskell types with Liquid Types [29], a form of refinement types [30], in order to prove properties about realistic Haskell programs [33]. In this approach, verification conditions are generated and discharged during type-checking.…”

Section: Related Workmentioning

confidence: 99%

Cameleer: A Deductive Verification Tool for OCaml

Pereira

Ravara

2021

Lecture Notes in Computer Science

View full text Add to dashboard Cite

We present , an automated deductive verification tool for OCaml. We leverage on the recently proposed GOSPEL (Generic OCaml SPEcification Language) to attach rigorous, yet readable, behavioral specification to OCaml code. The formally-specified program is fed to our toolchain, which translates it into an equivalent one in WhyML, the programming and specification language of the Why3 verification framework. We report on successful case studies conducted in .

show abstract

Section: Related Workmentioning

confidence: 99%

Cameleer: A Deductive Verification Tool for OCaml

Pereira

Ravara

2021

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…This is also a primary application of relational cost analysis. Consider the familiar monoid laws of the append operator: associativity These properties can be proved correct in Liquid Haskell via equational reasoning [Vazou et al 2018]. However, although the two sides of each property give the same results, each side does not necessarily require the same amount of resources.…”

Section: Extrinsic Cost Analysismentioning

confidence: 99%

“…To exemplify both the equational and inequational styles of proof, we reason about the results and resource usage of append separately. Readers are referred to [Vazou et al 2018] for a more detailed discussion on the following concepts.…”

Section: Proof Constructionmentioning

confidence: 99%

“…3.4.2 Totality and Termination. Partial definitions, which Haskell permits, are not valid inhabitants of theorems expressed in refinement types [Vazou et al 2018]. As such, the resource usage of partial definitions should not be analysed using the library.…”

Section: Library Assumptionsmentioning

confidence: 99%

“…ś Datatypes includes properties concerning lists, trees, and function optimisations whose Liquid Haskell correctness proofs initially appeared in [Vazou et al 2018]. We used the proof combinators of figure 2 to extend the correctness proofs with explicit resource tracking.…”

Section: Summary Of Examplesmentioning

confidence: 99%

See 2 more Smart Citations

Liquidate your assets: reasoning about resource usage in liquid Haskell

Handley

Vazou

Hutton

2019

Proc. ACM Program. Lang.

Self Cite

View full text Add to dashboard Cite

Liquid Haskell is an extension to the type system of Haskell that supports formal reasoning about program correctness by encoding logical properties as refinement types. In this article, we show how Liquid Haskell can also be used to reason about program efficiency in the same setting. We use the system's existing verification machinery to ensure that the results of our cost analysis are valid, together with custom invariants for particular program contexts to ensure that the results of our analysis are precise. To illustrate our approach, we analyse the efficiency of a wide range of popular data structures and algorithms, and in doing so, explore various notions of resource usage. Our experience is that reasoning about efficiency in Liquid Haskell is often just as simple as reasoning about correctness, and that the two can naturally be combined.In this article, we take inspiration from [Radiček et al. 2018] and implement a monadic datatype to measure the abstract resource usage of pure Haskell programs. We then use Liquid Haskell's [Vazou 2016] refinement type system to statically prove bounds on resource usage. Our framework supports the standard approach to cost analysis, which is known as unary cost analysis and aims to establish upper and lower bounds on the execution cost of a single program, together with the more recent relational approach [Çiçek 2018], which aims to calculate the difference between the execution costs of two related programs or between one program on two different inputs.Reasoning about execution cost using the Liquid Haskell system has two main advantages over most other formal cost analysis frameworks [Radiček et al. 2018]. First of all, the system allows correctness properties to be naturally integrated into cost analysis, which helps to ensure that cost analyses are valid. And secondly, the wide range of sophisticated invariants that can be expressed and automatically verified by the system can be exploited to analyse resource usage in particular program contexts, which often leads to more precise and/or simpler analyses.By way of example, Liquid Haskell can automatically verify that Haskell's standard sort function returns an ordered list (of type OList a) with the same length as its input, even when the result is embedded in the Tick datatype that we use to measure resource usage: sort :: Ord a => xs:[a] → Tick { zs:OList a | length zs == length xs } Applying our cost analysis to this function then allows us to prove that the maximum number of comparisons required to sort any list xs is O(n log n), where n = lenдth xs: sortCost :: Ord a => xs:[a] → { tcost (sort xs) <= 4 * length xs * log 2 (length xs) + length xs } Moreover, we can also combine correctness and resource properties to show that the maximum number of comparisons becomes linear when the input list is already sorted: sortCostSorted :: Ord a => xs:OList a → { tcost (sort xs) <= length xs }The aim of this article is to develop, prove correct, and evaluate a system that supports the above form of reasoning. To this end, t...

show abstract

Logic, Algebra, and Geometry at the Foundation of Computer Science

Hoare

Mendes

Ferreira

2019

Formal Methods Teaching

View full text Add to dashboard Cite

This paper shows by examples how the Theory of Programming can be taught to first-year CS undergraduates. The only prerequisite is their High School acquaintance with algebra, geometry, and propositional calculus. The main purpose of teaching the subject is to support practical programming assignments and projects throughout the degree course. The aims would be to increase the student's enjoyment of programming, reduce the workload, and increase the prospect of success.

show abstract

Theorem proving for all: equational reasoning in liquid Haskell (functional pearl)

Cited by 6 publications

References 26 publications

Cameleer: A Deductive Verification Tool for OCaml

Cameleer: A Deductive Verification Tool for OCaml

Liquidate your assets: reasoning about resource usage in liquid Haskell

Logic, Algebra, and Geometry at the Foundation of Computer Science

Contact Info

Product

Resources

About