Data Propositions

Even Numbers

Data propositions essentially axiomatize the behavior of predicates in the data type definitions, without actually giving a Haskell definition.

They are very similar to Coq’s inductive predicates. Thus, let’s look at the using the textbook example of even numbers.

First, we define the data type of natural numbers.

Then, we axiomatize the proposition that a number is even.

The two constructors E0 and E2 axiomatize the evenness of numbers. E0 states that Z is even, and E2 states that if n is even, then S (S n) is also even.

The definition is using the Prop type, defined in the Language.Haskell.Liquid.ProofCombinators module, that converts expressions into proof objects. Further, it requires the unrefined Even Haskell definition as well as an EVEN data constructor.

There are two important points in this construction.

• First, there is no function that computes evens, thus there is no termination check, meaning, that using data propositions one can encode non-terminating computations.

• Second, the data proposition EVEN is a proof object, thus an Even value, gives us information how the proof was constructed.

Construction of Even Numbers

Let’s construct some even numbers using the EVEN data proposition.

Question: Fill in the above definitions to construct the even numbers 0, 2, and 4.

Since EVEN is a proof object one can inspect it, to, for example, show contradictions.

Question: Show that S Z is not even, by inspection.

Functions on Even Numbers

Let’s now show that each even number, other than 0, can be written as 2 + n, for some n.

As a final exercise, let’s show that the sum of two even numbers is also even.

To do so, we first define the plus function:

Question: Fill in the definition of the even_plus function.

Metatheory of Programming Languages

In the theory of programming languages, we often use theorem provers, like Liquid Haskell or Coq, to mechanize the proof of properties of programs.

Such proofs usually talk about program evaluation.

Due to the halting problem we cannot prove, in general that program evaluation terminates, thus such concepts are encoded as data propositions (or inductive predicates).

As a simplification, let’s consider the simply typed lambda calculus, with integers and functions.

Evaluation of Expressions

We use data proposition to axiomatize the step relation of the language. That is, Step e e' defines the relation e -> e'.

Evaluation of an expression is defined as the transitive closure of the step relation. That is Evals e e' defines the relation e ->* e', which, in general is not terminating.

Typing of Expressions

We use data propositions to axiomatize the typing relation of the language. That is, HasType g e t defines the relation \(\Gamma \vdash e : \tau\), where \(\Gamma\) is the typing environment, \(e\) is the expression and \(\tau\) is the type.

Soundness = Progress + Preservation

Having defined both the typing and evaluation relations, we can connect them to show that our type system is sound. To show soundness, following the tradition of programming languages, we prove the progress and preservation properties.

Progress states that a well-typed expression is either a value or can take a step:

Preservation states that if an expression takes a step, then the resulting expression is also well-typed:

Soundness combines progress and preservation to inductively show that a well-typed expression evaluates to some expression that is either a value or can take a step.

Summary

In this lecture, we saw data propositions, which are used to axiomatize the behavior of predicates in the data type definitions. Data propositions have two major uses. First, they are used to encode non-terminating functions, like the evaluation function of a programming language. Second, they construct proof objects, whose inspection can facilitate proof developments. These two features allow the mechanization of sophisticated proofs, like metatheory of programming languages, in theorem provers like Liquid Haskell.

Appendix: The rest of the Code