Using dependent types to write proofs in Haskell

2021-06-02T00:00:00+00:00

Target audience: This blog is meant for intermediate/advanced Haskell readers, specially those interested in logic. If you are new to Haskell, this blog will probably not be easy to follow.

Overview</h1>
We all know that we can use Haskell to write functional programs that compute stuff. But can we also use Haskell to write mathematical proofs? Yes!
In case you have never been exposed to dependent types, the concept of writing proofs with a programming language will surely sound alien to you. In this blog I hope to give you an informal introduction to dependent types in Haskell that will allow you to understand what does it mean to prove something in Haskell and how to do it. I strongly recommend that you follow along with ghci on your side.
Clarification. At the time of writing this, GHC does not have full dependent types, however, as we will see, it has some features that allow us to get pretty close to them. If you are looking for a language with full dependent types I suggest that you look into Agda</a> or Lean</a>. In this other blog</a> I present an Agda implementation of a type safe domain specific language to write Hilbert style proofs. Also, GHC should not be used as a serious proof assistant, because, as we will see in this blog, it is very easy to prove false statements in it.
***You can find all related code to what I will present in this* *gitlab repository</a>.***
Extensions</h1>
In order to get close to dependent types we need the help of some GHC extensions. If you want to follow along, make sure to have the following extensions enabled in ghci. I will comment on some of them when they become relevant to the code I'm showing. Note that each extension links to the corresponding GHC manual page.

`GADTs</code></a>. Allow use of Generalised Algebraic Data Types (GADTs).</li>`
`ScopedTypeVariables</code></a>. Enable lexical scoping of type variables explicitly introduced with forall</code>.</li>`
`DataKinds</code></a>. Allow promotion of data types to kind level.</li>`
`PolyKinds</code></a>. Allow kind polymorphic types.</li>`
`TypeFamilies</code></a>. Allow use and definition of indexed type and data families.</li>`
`TypeOperators</code></a>. Allow the use and definition of types with operator names.</li>`
UndecidableInstances</code></a>. Permit definition of instances which may lead to type-checker non-termination.</li> </ul> Equality on types</h1> All proofs which I will present in this blog are proofs of equality. In fact, we will only show theorems which can be expressed in a formula of the form \[ ∀x₁…∀xₙ(t₁ ⇒ … ⇒ tₘ ⇒ r = s), \] where $xᵢ$ are type variables and $t₁,…,tₘ,r,s$ are types. So a first obvious step should be to define a type in Haskell which expresses type equality (according to the rules of GHC). We should agree that a the following header is a good place to start. data Equal a b where ... </code></pre> Now we should provide a constructor for this datatype. Of course, the constructor should be a witness that a</code> and b</code> are equal. So we can define the desired constructor like this: data Equal a b where Witness :: (a ~ b) => Equal a b </code></pre> Recall that the constraint a ~ b</code> means precisely what we want. Namely, that a</code> and b</code> are equal types according to GHC. However, we are going to use an alternative definition, which is slightly simpler and is already defined in base:Data.Type.Equality</code></a>: data a :~: b where Refl :: a :~: a </code></pre> Don't get confused by the infix notation of :~:</code>. It serves the same purpose as Equal</code>, but with infix notation (see TypeOperators</code></a>). The constructor is named Refl</code> for Reflexivity. We are ready to write our first proof. Let us show that the equality relation defined above is symmetric. Recall that in mathematics we say that a relation $R$ is symmetric iff $∀x∀y(xRy⇒yRx)$. Our next job is to find a type which faithfully represents the symmetry proposition. Let's use the following type. sym :: (x :~: y) -> (y :~: x) </code></pre> First we need to convince ourselves that the type (x :~: y) -> (y :~: x)</code> faithfully represents a proposition stating the property of symmetry. In fact if we use explicit quantification for x</code> and y</code> and we interpret the function type (-></code>) as an implication, it looks exactly like the mathematical statement: \[ ∀x∀y(xRy⇒yRx) \] forall x y. (x :~: y) -> (y :~: x) </code></pre> Now, if we can find a Haskell term which has the above type we will have a term such that given any x</code> and y</code> and a proof of x :~: y</code>, will return a proof of y :~: x</code>. If such term exists, it should be clear that the proposition is true and thus we should accept that term as a proof! In fact, this interpretation of a proof corresponds precisely to the BHK interpretation. If you want to read more on the BHK interpretation I suggest this Stanford Encyclopedia article</a>. On we go to find a suitable term (proof)! We see that (x :~: y) -> (y :~: x)</code> is a function type with one argument, so a good place to start would be this: sym :: (x :~: y) -> (y :~: x) sym p = _ </code></pre> If we load this into ghci it will tell us that it has found a hole: Found hole: _ :: y :~: x </code></pre> How can we fill this hole? Well, the only way to build something of type y :~: x</code> is by using the constructor Refl</code>, but doing that would give us either x :~: x</code> or y :~: y</code>, which is not what we want. So we are only left with the option to pattern match against p</code>. Here the type of the constructor Refl</code> will play a crucial role. Let's proceed by asking ghci about its type. ghci> :t Refl ghci> Refl :: forall k (a :: k). a :~: a </code></pre> What this says is: For any kind k</code> and for any type a</code> of kind k</code> we have a term of type a :~: a</code>. We can think of a kind as the type of a type. I will go back to types and kinds later in this section. Let's reload the code after replacing p</code> by Refl</code>. Note that I write p@Refl</code> so it is easier for me to refer to this specific Refl</code> in the text, but we could simply drop p@</code> to the same effect. sym :: (x :~: y) -> (y :~: x) sym p@Refl = _ </code></pre> Now we get that there is still a hole, but now it has type x :~: x</code> instead of y :~: x</code>. Found hole: _ :: x :~: x </code></pre> We see that because of pattern matching and the type of Refl</code>, GHC has unified the type variables x</code> and y</code>. Why? well, we know that before pattern matching we had p : x :~: y</code>. Then we have that p@Refl : x :~: y</code>, and therefore by the type of the constructor Refl</code> it must be that x ~ y</code>. Filling the hole and thus finishing the proof is trivial! We only need to return the Refl</code> constructor, which is a suitable term of the desired type x :~: x</code>. sym :: (x :~: y) -> (y :~: x) sym Refl = Refl </code></pre> Yay! we finished our first proof! However, there is one critical condition for a proof that we haven't yet commented: termination. In the case of sym</code>, it obviously terminates for any input, since we just return the constructor Refl</code>. However, as proofs get more complicated and we need to perform induction (as we will see in the natural numbers section</a>), it is easy to end up writing a well typed term that will not terminate on some inputs. If a term does not terminate on some inputs, then it obviously cannot be taken as a proof. Unfortunately, we are on our own because GHC does not perform any kind of termination checking for terms. As an example of a well typed but non-terminating term consider the following definition: anyProof :: forall a. a anyProof = anyProof </code></pre> Of course, we should always be very careful not to introduce a non-terminating (pseudo)proof, as the proof may be accepted by GHC and will lead us to believe that we have proven something which may be false. As a simple exercise, I propose that you try to prove that :~:</code> is a transitive relation. In Haskell terms, this means that you ought to find a suitable definition for this type signature. trans :: (x :~: y) -> (y :~: z) -> (x :~: z) </code></pre> Hint: The proof is really similar to the proof of sym</code>. After you have proven this, you will have proven that :~:</code> is symmetric, transitive and reflexive (this property is given directly by the constructor Refl</code>). Thus you can conclude that :~:</code> is an equivalence relation, which is the minimum requirement a definition of equality should satisfy. We end this section by summarizing the steps we should follow when writing a proof in Haskell. Write a type which represents the proposition that we want to prove.</li> Find a term that has that type. GHC makes sure that this step is correct by type checking the term.</li> Make sure (outside of GHC/in our meta reasoning) that the given term in the previous step terminates for any input. If it doesn't, we do not have a valid proof.</li> Feel good.</li> </ol> A note on types and kinds</h2> This section is a small parenthesis on types and kinds. It is a bit technical and tangential to the main topic so you may want to skip it on a first read. If we inspect closely the type of sym :: forall x y. (x :~: y) -> (y :~: x)</code>, one may ask the questions: what are x</code> and y</code>? They are not defined anywhere, yet we can use them? The answer lies in the fact that GHC types are not fully explicit most of the time. Consider the identity function type: id :: a -> a </code></pre> We could have raised a similar question by looking at this type. If we rewrite the previous type more explicitly, we would have: id :: forall a. a -> a </code></pre> We see that we universally quantify a type variable a</code>. But still this is not fully explicit. One could ask: What is the type of a</code>? Or in GHC terms, what is the kind of a</code>? Let's rewrite the type to make it even more explicit. id :: forall k (a :: k). a -> a </code></pre> Ok, we have solved the problem for a</code>. Now we know that a</code> has kind k</code>. But what is the kind of k</code>? We need to make it more explicit one last time. -- Type is imported from Data.Kind id :: forall (k :: Type) (a :: k). a -> a </code></pre> But how can it be that type of a kind k</code> is Type</code>? This is because in GHC we have the axiom Type :: Type</code>. This may raise some eyebrows since in the field of logic typing relations which include at least a reflexive element, such as Type :: Type</code>, are well known to lead to inconsistent logics, and thus are undesirable (if this topic is intriguing to you, I suggest that you read the article on the Russell's Paradox</a> in the Stanford Encyclopedia). However, GHC allows Type :: Type</code> because it has certain advantages. Moreover, inconsistencies are present even without it. This makes sense because GHC is not meant to be used as a proof assistant. In the paper System FC with Explicit Kind Equality</a>, Weirich, Hsu and Eisenberg argue that having the Type :: Type</code> axiom does not break GHC's type system. If you want to know how the paradox has been avoided in a programming language with dependent types, I suggest that you look into the Agda documentation for universe levels</a>. There is a lot more to types and kinds in GHC than what I have written (and probably a significant portion escapes my knowledge at this point in time). If you wish to know more, I suggest some references: The paper System FC with Explicit Kind Equality</a>.</li> GHC wiki article type type</a>.</li> Documentation for DataKinds</code></a>.</li> Documentation for PolyKinds</code></a>.</li> Proposal for unlifted data types</a>.</li> </ul> Proofs on natural numbers</h1> Finally something that is more tangible: natural numbers. As we know, a natural numbers are the elements of the infinite sequence $0,1,2,3,…$. We will begin by providing a Haskell inductive definition for them. data Nat where Zero :: Nat Suc :: Nat -> Nat </code></pre> We can define particular naturals as expected: one :: Nat one = Suc Zero two :: Nat two = Suc one ... </code></pre> Say that we want to prove that one + one = two</code>. It should be pretty straightforward right? Well, we have seen that we need to use types to express propositions. But one</code> and two</code> are terms, so we can not use them in a type. Moreover, how do we define addition on the type level? In order to solve this problem we will use some help from the DataKinds</code></a> extension. This extension promotes type constructors, such as Nat</code>, to kinds. Likewise, the extension promotes constructors, such as Zero</code> and Suc</code>, to type constructors. Note that when we want to refer to a promoted constructor we should prefix it with an apostrophe '</code>. Now we can define naturals on the type level thus: type One = 'Suc 'Zero type Two = 'Suc One </code></pre> The first part of the problem is solved. We now need to define addition on the promoted kind Nat</code>. We can do so with the help of the TypeFamilies</code></a> extension. With this extension we can define type families, which approximately are Haskell functions on types. First let's define addition on terms as we would normally do. This is only to have a point of reference. (+) :: Nat -> Nat -> Nat where Zero + b = b (Suc a) + b = Suc (a + b) </code></pre> And now see how we can translate the previous definition to type families. type family (a :: Nat) :+: (b :: Nat) :: Nat where 'Zero :+: b = b 'Suc a :+: b = 'Suc (a :+: b) </code></pre> One can observe that both definitions look quite alike. In fact, they would be exactly the same definition if we had full dependent types in GHC. Let's try an example. Notice that the we need a !</code> in :k!</code> in order to ask ghci to give us the normalized type. ghci> :k! ('Suc 'Zero) :+: ('Suc 'Zero) ghci> ('Suc 'Zero) :+: ('Suc 'Zero) :: Nat ghci> = 'Suc ('Suc 'Zero) </code></pre> Neat! We are finally ready to express in a type the property one + one = two</code> and prove it. onePlusOne :: (One :+: One) :~: Two onePlusOne = Refl </code></pre> It suffices to use reflection since both types One :+: One</code> and Two</code> normalize to 'Suc ('Suc 'Zero)</code>. Let's prove another property: n + zero = n</code>. nPlusZero :: (n :+: 'Zero) :~: n nPlusZero = Refl </code></pre> But now we get an error! Couldn't match type ‘n’ with ‘n :+: 'Zero’ </code></pre> The problem is that n :+: 'Zero</code> cannot be normalized further. This is because when we defined :+:</code> we pattern matched the left argument, but now we have 'Zero</code> on the right. Hence the expected way to proceed is to pattern match on n</code>. Unfortunately, we cannot pattern match on types directly so we need to figure something out. The strategy is to define a data type which will serve as a bridge between the terms universe and the types universe. data SNat (n :: Nat) where SZero :: SNat 'Zero SSuc :: SNat n -> SNat ('Suc n) </code></pre> The new data type SNat</code> which we just defined has the same structure as a Nat</code>, but it is indexed by a Nat</code> on the type level. Note that the n</code> in the first line is not a term of type Nat</code>. Instead, n</code> is a type variable of kind Nat</code>. With the help of GADTs</code></a>, we can use the promoted constructors 'Zero</code> and 'Suc</code> to create the desired link between terms and types. The following theorem makes such a link explicit. Theorem. For any type n</code> of kind Nat</code>, the type SNat n</code> has exactly one term. We prove it by induction on n</code>. Base case n</code> = 'Zero</code>. By definition SZero :: SNat 'Zero</code>. To see that SZero</code> is the only term of type SNat 'Zero</code>, assume that there is a term b :: SNat 'Zero</code>. We continue by cases on b</code>. If b</code> is SZero</code> we are done. Otherwise b</code> is of the form SSuc _</code>, but then b</code>'s type must be of the form SNat ('Suc _)</code>, which is a contradiction. </li> Inductive case n</code> = 'Suc m</code>. By induction hypothesis we have that there exists exactly one term i</code> such that i :: SNat m</code>. Then we have that SSuc i :: SNat ('Suc m)</code>. Now assume that there is a term j :: SNat ('Suc m)</code>. From the type we know that j</code> is of the form SSuc k</code> and k :: SNat m</code>. Then by the induction hypothesis we have that i</code> = k</code>. Therefore j</code> = SSuc i</code>. Qed. </li> </ul> Because of the previous property we call the type SNat</code> a singleton type. If you want a more extensive introduction to singleton types, I recommend this blog</a> by Justin Le. We can now use the singleton type SNat</code> to pattern match on types of kind Nat</code>. nPlusZero :: SNat n -> (n :+: 'Zero) :~: n nPlusZero SZero = _ nPlusZero (SSuc m) = _ </code></pre> After loading the previous code into ghci we get the following information: For the base case (first hole): Found hole: _ :: 'Zero :~: 'Zero </code></pre> This hole can be trivially proven with Refl</code>. </li> For the inductive case (second hole): Found hole: _ :: 'Suc (n1 :+: 'Zero) :~: 'Suc n1 </code></pre> We see that we need to prove an equality of the form 'Suc a :~: 'Suc b</code>, and this equality is implied by a :~: b</code>. Let's prove this fact as an auxiliary lemma. congSuc :: a :~: b -> 'Suc a :~: 'Suc b congSuc Refl = Refl </code></pre> We see that congSuc</code> is a very simple lemma that can be proved in the same way we proved sym</code>. In order to use the previous lemma we only need to apply it as a regular function. nPlusZero :: SNat n -> (n :+: 'Zero) :~: n nPlusZero SZero = Refl nPlusZero (SSuc m) = congSuc _ </code></pre> After applying congSuc</code> the hole becomes: Found hole: _ :: (n1 :+: 'Zero) :~: n1 </code></pre> It worked, the hole type became simpler! In fact, it looks much like the property that we wanted to prove initially. This is often telling us that we need to apply the induction hypothesis. Applying the induction hypothesis is as simple as doing a recursive call to the theorem that we are proving. nPlusZero :: SNat n -> (n :+: 'Zero) :~: n nPlusZero SZero = Refl nPlusZero (SSuc m) = congSuc (nPlusZero m) </code></pre> </li> </ul> We have finished our first proof by induction! Now imagine that we want to use the previous theorem in another proof. In particular, imagine that we need to fill a goal of type SNat a -> SNat b -> (a :+: b) :+: 'Zero</code>. It is clear that the strategy should be to instantiate the n</code> in the lemma nPlusZero</code> as a :+: b</code>, but then we should provide an argument of type SNat (a :+: b)</code>. We can achieve that by implementing addition for the type SNat</code> as follows. (.+.) :: SNat a -> SNat b -> SNat (a :+: b) SZero .+. b = b SSuc a .+. b = SSuc (a .+. b) </code></pre> Finally we can use the theorem nPlusZero</code> thus: someThm :: SNat a -> SNat b -> (a :+: b) :+: 'Zero someThm a b = nPlusZero (a .+. b) </code></pre> At this point I have given you enough tools so that you can start writing your own proofs. Exercises</h2> Below I provide a list of theorems that you may want to prove as practice. If you get stuck you can refer to my solutions in this repository</a>, specifically this file</a>. I wrote these solutions about 3 years ago when I was still a complete novice at writing proofs. So it is likely that you will find better proofs. In order to solve the exercises you will need the following definitions. type family (a :: Nat) :: (b :: Nat) :: Nat where 'Zero :: b = 'Zero 'Suc a :: b = b :+: (a :: b) type family (a :: Nat) :^: (b :: Nat) :: Nat where a :^: 'Zero = 'Suc 'Zero a :^: 'Suc b = a :: (a :^: b) </code></pre> Exercise list. plusSucR :: forall a b. SNat a -> SNat b -> (a :+: 'Suc b) :~: 'Suc (a :+: b) </code></pre> </li> plusAssoc :: forall a b c. SNat a -> SNat b -> SNat c -> (a :+: b) :+: c :~: a :+: (b :+: c) </code></pre> </li> plusCommut :: forall a b. SNat a -> SNat b -> (a :+: b) :~: (b :+: a) </code></pre> </li> prodZeroL :: SNat n -> 'Zero :: n :~: 'Zero </code></pre> </li> prodZeroR :: SNat sn -> (sn :: 'Zero) :~: 'Zero </code></pre> </li> prodOneL :: SNat sn -> (One :: sn) :~: sn </code></pre> </li> prodOneR :: SNat sn -> (sn :: One) :~: sn </code></pre> </li> prodSucL :: forall a b. SNat a -> SNat b -> ('Suc a :: b) :~: b :+: (a :: b) </code></pre> </li> prodSucR :: forall a b. SNat a -> SNat b -> (a :: 'Suc b) :~: a :+: (a :: b) </code></pre> </li> prodDistribR :: forall a b c. SNat a -> SNat b -> SNat c -> (a :+: b) :: c :~: (a :: c) :+: (b :: c) </code></pre> </li> prodDistribL :: forall a b c. SNat a -> SNat b -> SNat c -> a :: (b :+: c) :~: (a :: b) :+: (a :: c) </code></pre> </li> prodAssoc :: forall a b c. SNat a -> SNat b -> SNat c -> (a :: b) :: c :~: a :: (b :: c) </code></pre> </li> prodCommut :: forall a b. SNat a -> SNat b -> (a :: b) :~: (b :: a) </code></pre> </li> powerZero :: a :^: 'Zero :~: One </code></pre> </li> powerOne :: SNat a -> a :^: One :~: a </code></pre> </li> prodPower :: forall a b c. SNat a -> SNat b -> SNat c -> (a :^: b) :: (a :^: c) :~: a :^: (b :+: c) </code></pre> </li> powerProd :: forall a b c. SNat a -> SNat b -> SNat c -> (a :^: c) :: (b :^: c) :~: (a :: b) :^: c </code></pre> </li> </ol> Proofs on lists</h1> More exercises for lists. You will need some common functions on lists on the type level. type family Length (l :: []) :: Nat where Length '[] = 'Zero Length (_':r) = 'Suc (Length r) type family (a :: []) :++: (b :: []) :: [] where '[] :++: b = b (a ': as) :++: b = a : (as :++: b) type family Reverse (a :: []) :: [] where Reverse '[] = '[] Reverse (a ': as) = Reverse as :++: '[a] </code></pre> A singleton list type can be defined thus: data HList (l :: []) :: where HNil :: HList '[] HCons :: t -> HList l -> HList (t ': l) </code></pre> List of exercises. concatNilL :: '[] :++: a :~: a </code></pre> </li> concatNilR :: HList a -> a :++: '[] :~: a </code></pre> </li> lengthCons :: HList a -> Length (t ': a) :~: 'Suc (Length a) </code></pre> </li> lengthConcat :: HList a -> HList b -> Length a :+: Length b :~: Length (a :++: b) </code></pre> </li> concatAssoc :: forall a b c. HList a -> HList b -> HList c -> (a :++: b) :++: c :~: a :++: (b :++: c) </code></pre> </li> lengthConcatCommut :: forall a b. HList a -> HList b -> Length (a :++: b) :~: Length (b :++: a) </code></pre> </li> lengthReverse :: HList a -> Length (Reverse a) :~: Length a </code></pre> </li> concatReverse :: forall a b . HList a -> HList b -> Reverse a :++: Reverse b :~: Reverse (b :++: a) </code></pre> </li> consReverse :: forall a t. HList a -> t ': Reverse a :~: Reverse (a :++: '[t]) </code></pre> </li> reverseReverse :: forall a. HList a -> Reverse (Reverse a) :~: a </code></pre> </li> </ol> Singletons library</h1> If you plan on using singleton types on your projects, you should definitely look into the singletons</code></a> library. According to its documentation, singletons</code> contains the basic types and definitions needed to support dependently typed programming techniques in Haskell. Additionally, it is very convenient to combine it with singletons-th</code></a> library, which will automatically generate a lot of boilerplate code for you. For instance, in order to define the natural numbers we needed to define Nat</code> and SNat</code>. The latter can be automatically generated by singletons-th</code>. Moreover, when defining addition we needed to define :+:</code> on the type level for the kind Nat</code> and .+.</code> on the singleton term level for SNat</code>. Again, with the singletons-th</code> library, we could automatically generate both :+:</code> and .+.</code> from the simple definition of +</code> on the type Nat</code>. Giving a detailed introduction to the singletons</code> library is out of the scope of this blog. For that, I recommend the Readme</code> of the singletons</code> library</a> and (again) this blog</a> by Justin Le. Useful references</h1> If you want to know more or you want different takes on this topic, I would suggest that you look into these references. An introduction to typeclass metaprogramming</a> by Alexis King.</li> Tweag youtube channel</a> featuring Richard Eisenberg.</li> Basic Type Level Programming in Haskell</a> by Matt Parsons.</li> nLab: propositions as types</a> (not Haskell, more theoretical).</li> If you know of a nice reference which is missing here, let me know and I'll add it.</li> </ul> Final words</h1> I hope you found this interesting. If you find any mistake, please let me know.

An Agda eDSL for well-typed Hilbert style proofs

2019-05-19T00:00:00+00:00

I present an Agda eDSL for writing Hilbert style proofs for logic $𝑲$.

This blog consists of two main parts. The first part presents the language and some examples. The second offers some insight into the key parts of the implementation. The latter targets Agda beginner/intermediate users or any programmer interested in dependent types.

The code is available here</a>. It has been implemented using Agda 2.6.0 with the standard library</a> (at this specific commit</a>).

Some introductory concepts</h1>

What is an eDSL? The acronym eDSL stands for Embedded Domain Specific Language. It refers to a small language (a set of functions and data types) embedded in another language (in this case Agda) that has been designed to solve a problem in a very specific domain, in this case, Hilbert style proofs.

What is a Hilbert style proof? First we need to know what a Hilbert calculus is. A Hilbert calculus is a set of axioms plus a set of rules. The axioms are formulas that we accept as primitive theorems and the rules allow us to syntactically combine existing theorems to create new ones. Then, a Hilbert style proof is a sequence of formulas where each formula is either an axiom of the calculus or the result of applying a rule to previous formulas in the sequence. The last formula in the sequence is the theorem of the proof. It is best understood by seeing a concrete example, if you scroll down you will find one.

The eDSL and logic $K$</h1>
As a preface, let me remark that that the chosen logic, $𝑲$, is not of special importance here, it just lays the ground for some concrete examples. In fact, it would be interesting to implement a logic agnostic eDSL in the future.
Let’s begin by defining the syntax of modal formulas:
\[ \begin{align*} ModalFm ≔ Var\ |\ ModalFm → ModalFm\ |\ □ ModalFm \ |\ ⊥ \\ \end{align*} \]
Of course, we are missing important logical connectives like $¬,∧,∨$, but it is better to have a small core language and define the other connectives in terms of the primitive ones, for instance:
\[ \begin{align*} ¬ϕ & ≔ ϕ→⊥ \\ ϕ∧ψ & ≔ ¬(ϕ→¬ψ) \\ ϕ∨ψ & ≔ ¬ϕ→ψ \\ \end{align*} \]
The axioms of $𝑲$ are the following:
\[ \begin{align*} \text{(K1) } & ϕ → (ψ → ϕ) \\ \text{(K2) } & (ϕ → (ψ → ξ)) → ((ϕ → ψ) → (ϕ → ξ)) \\ \text{(K3) } & (¬ ϕ → ¬ ψ) → (ψ → ϕ) \\ \text{(Distribution) } & □ (ϕ → ψ) → (□ ϕ → □ ψ) \end{align*} \]
The above are axiom schemes (or templates), so $ϕ,ψ,ζ$ are formula metavariables which can be substituted for any modal formula.
And the rules are the following:

Modus Ponens: If $ϕ$ is a theorem and $ϕ→ψ$ is a theorem, then $ψ$ is a theorem.</li> </ul>
\[ \begin{array}{c} ϕ→ψ \\ ϕ \\ \hline ψ \end{array} \]

Necessitation: If $ϕ$ is a theorem then $□ϕ$ is a theorem.</li> </ul>
\[ \begin{array}{c} ϕ \\ \hline □ϕ \end{array} \]

Identity: If $ϕ∈Σ$ then $Σ⊢ϕ$. Note that $ϕ$ may not be a theorem. See clarification at the end of this section.</li> </ul>
Finally! we can construct our first Hilbert style proof. Let’s prove $□(ϕ→ϕ)$.
\[ \begin{array}{lr} \text{[ 0 ] } (ϕ → ((ϕ → ϕ) → ϕ)) → ((ϕ → (ϕ → ϕ)) → (ϕ → ϕ)) & \text{By K2} \\ \text{[ 1 ] } ϕ → ((ϕ → ϕ) → ϕ) & \text{By K1} \\ \text{[ 2 ] } ϕ → (ϕ → ϕ) & \text{By K1} \\ \text{[ 3 ] } (ϕ → (ϕ → ϕ)) → (ϕ → ϕ) & \text{By MP 0, 1} \\ \text{[ 4 ] } ϕ → ϕ & \text{By MP 3, 2} \\ \text{[ 5 ] } □ (ϕ → ϕ) & \text{By Nec 4}\\ \end{array} \]
And now… how does the same proof look in our eDSL as Agda code? Here it is:
□⟨ϕ↝ϕ⟩ : ∀ {Σ ϕ} → Σ ⊢ □ (ϕ ↝ ϕ) □⟨ϕ↝ϕ⟩ {Σ} {ϕ} = begin[ 0 ] (ϕ ↝ ((ϕ ↝ ϕ) ↝ ϕ)) ↝ ((ϕ ↝ (ϕ ↝ ϕ)) ↝ (ϕ ↝ ϕ)) By K2 [ 1 ] ϕ ↝ ((ϕ ↝ ϕ) ↝ ϕ) By K1 [ 2 ] ϕ ↝ (ϕ ↝ ϕ) By K1 [ 3 ] (ϕ ↝ (ϕ ↝ ϕ)) ↝ (ϕ ↝ ϕ) ByMP 0 , 1 [ 4 ] ϕ ↝ ϕ ByMP 3 , 2 [ 5 ] □ (ϕ ↝ ϕ) ByNec 4 ■ </code></pre> Wow, they look really similar indeed! So what? Well, we can write Hilbert styles proofs in a paper-like syntax with the key advantage that Agda’s type checker will make sure that the proof is constructed according to the rules, that is, that there are no mistakes in it. For instance, proofs where an axiom is instantiated incorrectly, or an application of modus ponens is incorrect will fail to type check and we will get an error from the compiler telling us where the misstep is. An additional free perk that we get is that we can easily export the proofs to rich html</a> or latex</a>. Let me underline that the code above is actual Agda code. This might be surprising for readers not accustomed to Agda’s mixfix operators</a>, which give great syntactical versatility. It is worth noting that the By</code> step does not only accept axioms, but any theorem previously proved. So, if we were to prove another theorem and we wanted to use $□ (ϕ → ϕ)$ as an intermediate step we could do so. Also, since we proved $□(ϕ→ϕ)$ for any $ϕ$, we are free to substitute it for any formula. Example: ... [ 1 ] □ (ϕ ↝ ϕ) By □⟨ϕ↝ϕ⟩ [ 2 ] □ ((ψ ∧ ϕ) ↝ (ψ ∧ ϕ)) By □⟨ϕ↝ϕ⟩ ... </code></pre> What about premises? Well, as you may have already noticed in the previous proof, we wrote $Σ ⊢ □ (ϕ → ϕ)$, where $Σ$ is our set of premises, and we are free to use any formula in $Σ$ as if it was a theorem within the proof. As an example, let’s prove $ϕ→ψ,ϕ,Σ⊢ψ$. ϕ↝ψ∷ϕ∷Σ⊢ψ : ∀ {ϕ ψ Σ} → ϕ ↝ ψ ∷ ϕ ∷ Σ ⊢ ψ ϕ↝ψ∷ϕ∷Σ⊢ψ {ϕ} {ψ} = begin[ 0 ] ϕ By premise 1 [ 1 ] ϕ ↝ ψ By premise 0 [ 2 ] ψ ByMP 0 , 1 ■ </code></pre> Clarification: Notice that a formula $ϕ$ is a theorem of the logic $K$ if and only if $∅⊢ϕ$. So in case we have $Σ⊢ϕ$ with $Σ$ nonempty it may be that $ϕ$ is not a theorem of $K$. It is worth noting that when we define ϕ↝ϕ : ∀ {Σ ϕ} : Σ ⊢ ϕ ↝ ϕ</code>, then the term ϕ↝ϕ</code> is really a proof that $ϕ → ϕ$ is a theorem of $K$ since $Σ$ is a parameter of the proof and in particular it can be empty. This concludes the overview of the language features. Implementation tour</h1> We start by defining the syntax of formulas. We define variables to be natural numbers but this is not really relevant. Var : Set Var = Nat infixr 20 _↝_ data Fm : Set where _! : Var → Fm _↝_ : Fm → Fm → Fm □ : Fm → Fm ⊥ : Fm </code></pre> Now, if we wanted, we could expand our language by defining more function symbols. For instance, we could define negation thus: ¬ : Fm → Fm ¬ ϕ = ϕ ↝ ⊥ </code></pre> We could do the same for $∧,∨,♢,⊤$ and any other operator. Let’s define a data type that represents a proof in Hilbert calculus. As expected, it will have a constructor for each axiom scheme and rule. infix 0 _⊢_ data _⊢_ (Σ : List Fm) : Fm → Set where K1 : ∀ {ϕ ψ : Fm} → Σ ⊢ ϕ ↝ (ψ ↝ ϕ) K2 : ∀ {ϕ ψ ξ : Fm} → Σ ⊢ (ϕ ↝ (ψ ↝ ξ)) ↝ ((ϕ ↝ ψ) ↝ (ϕ ↝ ξ)) K3 : ∀ {ϕ ψ : Fm} → Σ ⊢ (¬ ϕ ↝ ¬ ψ) ↝ (ψ ↝ ϕ) distribution : {ϕ ψ : Fm} → Σ ⊢ □ (ϕ ↝ ψ) ↝ (□ ϕ ↝ □ ψ) necessitation : ∀ {ϕ : Fm} → Σ ⊢ ϕ → Σ ⊢ □ ϕ mp : ∀ {ϕ ψ : Fm} → Σ ⊢ (ϕ ↝ ψ) → Σ ⊢ ϕ → Σ ⊢ ψ premise : ∀ {ϕ : Fm} → Member ϕ Σ → Σ ⊢ ϕ </code></pre> We can now write our first proof. The following proof corresponds to the proof that $ϕ→ϕ$ is a theorem of $K$ shown above. ϕ↝ϕ : ∀ {Σ ϕ} → Σ ⊢ (ϕ ↝ ϕ) ϕ↝ϕ {Σ} {ϕ} = mp (mp (K2 {Σ} {ϕ} {ϕ ↝ ϕ} {ϕ}) (K1 {Σ} {ϕ} {ϕ ↝ ϕ})) (K1 {Σ} {ϕ} {ϕ}) </code></pre> It is horrible to read and too verbose. We can make it a little more succinct by taking advantage of Agda’s implicit argument inference: ϕ↝ϕ : ∀ {Σ ϕ} → Σ ⊢ ϕ ↝ ϕ ϕ↝ϕ {Σ} {ϕ} = mp (mp K2 K1) (K1 {ψ = ϕ}) </code></pre> Much better but still hard for a human to visualize what are the intermediate steps. Computer programmers could think of this as machine code; something very useful for its simplicity but hard for humans to use. So, as we do in programming, we will design a human-friendly language and a compiler that translates nice looking proofs into (let’s call them) primitive Hilbert style proofs. Of course, everything will be guaranteed to work from the types, so no need to execute any code, just type check it (as is always the case when using Agda as a proof checker). A sketch of the eDSL</h2> We want a language as close to the paper-like syntax showed above as possible. We will refer to proofs in this language as nice proofs and proofs of the type _⊢_</code> as primitive proofs. We will refer to the process of translating nice proofs to primitive proofs as compilation. First we need to think about the type of a nice proof. Well, it needs to keep track of the set of premises, the formula that entails and the length of it, so the following type is what we want. data HilbertProof : List Fm → Fm → Nat → Set </code></pre> Then the compile function will be of the following type. compile : ∀ {n Σ ϕ} → HilbertProof Σ ϕ n → Σ ⊢ ϕ </code></pre> We can now think about which constructors we need for a nice proof. By</code>. To reference an axiom or another theorem.</li> MP</code>. To apply modus ponens to previous formulas in the proof.</li> Nec</code>. To apply necessitation to a previous formula in the proof.</li> </ol> We will refer to these constructors as instructions. Instructions are numbered with consecutive naturals starting at 0. This number is used to reference its corresponding formula in subsequent steps. There must be a special instruction that does not expect instructions before it. We call this instruction Begin</code> and it works the same as By</code> with the exception that it can only be used as the first instruction. Highlights</h2> We face the following challenges. Numbering. We need to make sure that the user labels the instructions properly.</li> Proper references. We need to make sure that the numbers referencing other instructions are in range of the size of the proof and that they reference the appropriate formulas.</li> Compilation. We need to translate nice proofs into primitive proofs.</li> </ol> Numbering</h3> The numbering certainly looks easier to tackle, so let’s start by this one. Instead of trying to solve our problem directly, I propose an alternative problem that captures the same challenge but with no unnecessary noise around it. Exercise: Boring list Define a list type such that the first number must be a zero and each subsequent number must be equal to the head plus one. Solution</summary> We do so with the help of singleton types. data SingleNat : Nat → Set where single : (n : Nat) → SingleNat n data BoringList : Nat → Set where [_] : SingleNat 0 → BoringList 0 _∷_ : ∀ {n} → SingleNat (suc n) → BoringList n → BoringList (suc n) example : BoringList 2 example = single 2 ∷ (single 1 ∷ [ single 0 ]) </code></pre> Well, yeah, this kind of works, but we still have to write single</code> before each natural number, can’t we do better? Yes, indeed! using literal overloading</a>. If we define a Number</code> instance for SingleNat</code> then we will be able to write singleton naturals with plain natural numbers. instance NumNatSing : ∀ {n} → Number (SingleNat n) NumNatSing {n} .Number.Constraint m = n ≡ m NumNatSing .Number.fromNat m ⦃ refl ⦄ = single m </code></pre> Then the example becomes: example : BoringList 2 example = 2 ∷ (1 ∷ [ 0 ]) </code></pre> Perfect! that’s what we needed. </details> </div> With the previous solution in hand, it is easy to imagine how we can incorporate the same idea into our language. Proper references</h3> Let’s focus on the case of modus ponens (necessitation works analogously). Assuming the modus ponens instruction entails $ψ$, it should receive one reference to $ϕ→ψ$ and another reference to $ϕ$. As we mentioned, these reference will be written as natural numbers by the user, but as we need to make sure that they are in range and reference the correct formulas, we need an extra proof object ensuring that. More precisely, assuming we defined the function lookup-maybe : ∀ {Σ ζ ϕ} → HilbertProof Σ ζ ϕ → Nat → Maybe Fm</code> with the expected implementation we would require both proof objects lookup-maybe HP i ≡ just (ϕ ↝ ψ)</code> and lookup-maybe HP j ≡ just ϕ</code>. But in the case that the references are correct, these proof objects will always be trivially solved by normalization and reflexivity, hence the code would look like this: [ 3 ] (ϕ ↝ (ϕ ↝ ϕ)) ↝ ϕ ↝ ϕ ByMP 0 ⟨ refl ⟩ , 1 ⟨ refl ⟩ </code></pre> And we really want to avoid to have the explicit proof object as it makes the syntax unpleasant. Could we use literal overloading for references to previous formulas as well? Yes! data HilbertRef {Σ ϕ n} (H : HilbertProof Σ ϕ n) (ψ : Fm) : Set where ref : (i : Nat) → lookup-may H i ≡ just ψ → HilbertRef H ψ instance NumRef : ∀ {ϕ Σ n} {H : HilbertProof Σ ϕ n} {ψ} → Number (HilbertRef H ψ) NumRef {ϕ} {Σ} {n} {H} {ψ} .Number.Constraint i = lookup-may H i ≡ just ψ NumRef {ϕ} {Σ} {n} {H} .Number.fromNat i ⦃ x ⦄ = ref i x </code></pre> Now we can write: [ 3 ] (ϕ ↝ (ϕ ↝ ϕ)) ↝ ϕ ↝ ϕ ByMP 0 , 1 </code></pre> And then each proof object is implicitly embedded in the natural literal 0, 1</code>. Compilation</h3> It is hard to highlight a specific part over the others for the compilation process. Compilation is mostly about fiddling with types and proof objects to get the desired translation. If you are interested in this part I suggest you look at the code</a> directly. Conclusion</h2> I hope that you enjoyed the reading. Any comments and suggestions are welcome. I am not an expert Agda programmer, so in case you look at the full code, take it with a pinch of salt :)

Final words</h1>
I hope you found this interesting. If you find any mistake, please let me know.</p>

The exercises</h2>

Conclusion</h2>
I hope that you enjoyed the reading. Any comments and suggestions are welcome.</p>
I am not an expert Agda programmer, so in case you look at the full code, take it with a pinch of salt :)</p>

Final comments</h1>
It could be nice to adapt the code to use arrays with constant access time instead of lists, but for small inputs it is irrelevant.</p>

Ascetic Slug

Using dependent types to write proofs in Haskell

Run-length encoding verified in Agda

An Agda eDSL for well-typed Hilbert style proofs

ASCII fractals in Haskell

Ascetic Slug

Using dependent types to write proofs in Haskell

Proofs on natural numbers</h1> Finally something that is more tangible: natural numbers. As we know, a natural numbers are the elements of the infinite sequence $0,1,2,3,…$. We will begin by providing a Haskell inductive definition for them.</p>

Final words</h1> I hope you found this interesting. If you find any mistake, please let me know.</p>

Run-length encoding verified in Agda

The exercises</h2>

An Agda eDSL for well-typed Hilbert style proofs

Conclusion</h2> I hope that you enjoyed the reading. Any comments and suggestions are welcome.</p> I am not an expert Agda programmer, so in case you look at the full code, take it with a pinch of salt :)</p>

ASCII fractals in Haskell

Final comments</h1> It could be nice to adapt the code to use arrays with constant access time instead of lists, but for small inputs it is irrelevant.</p>

Final words</h1>
I hope you found this interesting. If you find any mistake, please let me know.</p>

Conclusion</h2>
I hope that you enjoyed the reading. Any comments and suggestions are welcome.</p>
I am not an expert Agda programmer, so in case you look at the full code, take it with a pinch of salt :)</p>

Final comments</h1>
It could be nice to adapt the code to use arrays with constant access time instead of lists, but for small inputs it is irrelevant.</p>