Simple dependent type example in Haskell for Dummies. How are they useful in practice in Haskell? Why should I care about dependent types ?

Question

I hear a lot about dependent types nowadays and I heard that DataKinds is somehow related to dependent typing (but I am not sure about this... just heard it on a Haskell Meetup).

Could someone illustrate with a super simple Haskell example what dependent typing is and what is it good for ?

On wikipedia it is written that dependent types can help prevent bugs. Could you give a simple example about how dependent types in Haskell can prevent bugs?

Something that I could start using in five minutes right now to prevent bugs in my Haskell code?

Dependent types are basically functions from values to types, how can this be used in practice? Why is that good ?

Answer 1

Late to the party, this answer is basically a shameless plug.

Sam Lindley and I wrote a paper about Hasochism, the pleasure and pain of dependently typed programming in Haskell. It gives plenty of examples of what's possible now in Haskell and draws points of comparison (favourable as well as not) with the Agda/Idris generation of dependently typed languages.

Although it is an academic paper, it is about actual programs, and you can grab the code from Sam's repo. We have lots of little examples (e.g. orderedness of mergesort output) but we end up with a text editor example, where we use indexing by width and height to manage screen geometry: we make sure that components are regular rectangles (vectors of vectors, not ragged lists of lists) and that they fit together exactly.

The key power of dependent types is to maintain consistency between separate data components (e.g., the head vector in a matrix and every vector in its tail must all have the same length). That's never more important than when writing conditional code. The situation (which will one day come to be seen as having been ridiculously naïve) is that the following are all type-preserving rewrites

• if b then t else e => if b then e else t
• if b then t else e => t
• if b then t else e => e

Although we are presumably testing b because it gives us some useful insight into what would be appropriate (or even safe) to do next, none of that insight is mediated via the type system: the idea that b's truth justifies t and its falsity justifies e is missing, despite being critical.

Plain old Hindley-Milner does give us one means to ensure some consistency. Whenever we have a polymorphic function

f :: forall a. r[a] -> s[a] -> t[a]

we must instantiate a consistently: however the first argument fixes a, the second argument must play along, and we learn something useful about the result while we are at it. Allowing data at the type level is useful because some forms of consistency (e.g. lengths of things) are more readily expressed in terms of data (numbers).

But the real breakthrough is GADT pattern matching, where the type of a pattern can refine the type of the argument it matches. You have a vector of length n; you look to see whether it's nil or cons; now you know whether n is zero or not. This is a form of testing where the type of the code in each case is more specific than the type of the whole, because in each case something which has been learned is reflected at the type level. It is learning by testing which makes a language dependently typed, at least to some extent.

Here's a silly game to play, whatever typed language you use. Replace every type variable and every primitive type in your type expressions with 1 and evaluate types numerically (sum the sums, multiply the products, s -> t means t-to-the-s) and see what you get: if you get 0, you're a logician; if you get 1, you're a software engineer; if you get a power of 2, you're an electronic engineer; if you get infinity, you're a programmer. What's going on in this game is a crude attempt to measure the information we're managing and the choices our code must make. Our usual type systems are good at managing the "software engineering" aspects of coding: unpacking and plugging together components. But as soon as a choice has been made, there is no way for types to observe it, and as soon as there are choices to make, there is no way for types to guide us: non-dependent type systems approximate all values in a given type as the same. That's a pretty serious limitation on their use in bug prevention.

Answer 2

The common example is to encode the length of a list in it's type, so you can do things like (pseudo code).

cons :: a -> List a n -> List a (n+1)

Where n is an integer. This let you specify that adding an object to list increment its length by one.

You can then prevent head (which give you the first element of a list) to be ran on empty list

 head :: n > 0 => List a n -> a

Or do things like

to3uple :: List a 3 -> (a,a,a)

The problem with this type of approach is you then can't call head on a arbitrary list without having proven first that the list is not null.

Sometime the proof can be done by the compiler, ex:

 head (a `cons` l)

Otherwise, you have to do things like

 if null list
    then ...
    else (head list)

Here it's safe to call head, because you are in the else branch and therefore guaranteed that the length is not null.

However, Haskell doesn't do dependent type at the moment, all the examples have given won't work as nicely, but you should be able to declare this type of list using DataKind because you can promote a int to type which allow to instanciate List a b with List Int 1. (b is a phantom type taking a literal).

If you are interested in this type of safety, you can have a look a liquid Haskell.

Here is a example of such code

{-# LANGUAGE DataKinds, KindSignatures, TypeFamilies, TypeOperators #-}

import GHC.TypeLits


data List a (n:: Nat) = List [a] deriving Show

cons :: a -> List a n -> List a (n + 1)
cons x (List xs) = List (x:xs)

singleton :: a -> List a 1
singleton x = List [x]

data NonEmpty
data EmptyList

type family ListLength a where
  ListLength (List a 0) =  EmptyList
  ListLength (List a n) = NonEmpty

head' :: (ListLength (List a n) ~ NonEmpty) => List a n -> a
head' (List xs) = head xs

tail' :: (ListLength (List a n) ~ NonEmpty) => List a n -> List a (n-1)
tail' (List xs) = List (tail xs)

list = singleton "a"

head' list -- return "a"

Trying to do head' (tail' list) doesn't compile and give

Couldn't match type ‘EmptyList’ with ‘NonEmpty’
Expected type: NonEmpty
  Actual type: ListLength (List [Char] 0)
In the expression: head' (tail' list)
In an equation for ‘it’: it = head' (tail' list)

Answer 3

Adding to @mb14's example, here's some simpler working code.

First, we need DataKinds, GADTs, and KindSignatures to really make it clear:

{-# LANGUAGE DataKinds      #-}
{-# LANGUAGE GADTS          #-}
{-# LANGUAGE KindSignatures #-}

Now let's define a Nat type, and a Vector type based on it:

data Nat :: * where
    Z :: Nat
    S :: Nat -> Nat

data Vector :: Nat -> * -> * where
    Nil   :: Vector Z a
    (:-:) :: a -> Vector n a -> Vector (S n) a

And voila, lists using dependent types that can be called safe in certain circumstances.

Here are the head and tail functions:

head' :: Vector (S n) a -> a
head' (a :-: _) = a
-- The other constructor, Nil, doesn't apply here because of the type signature!

tail' :: Vector (S n) a -> Vector n a
tail (_ :-: xs) = xs
-- Ditto here.

This is a more concrete and understandable example than above, but does the same sort of thing.

Note that in Haskell, Types can influence values, but values cannot influence types in the same dependent ways. There are languages such as Idris that are similar to Haskell but also support value-to-type dependent typing, which I would recommend looking into.

Answer 4

The machines package lets users define machines that can request values. Many machines request only one type of value, but it's also possible to define machines that sometimes ask for one type and sometimes ask for another type. The requests are values of a GADT type, which allows the value of the request to determine the type of the response.

Step k o r = ...
           | forall t . Await (t -> r) (k t) r

The machine provides a request of type k t for some unspecified type t, and a function to deal with the result. By pattern matching on the request, the machine runner learns what type it must supply the machine. The machine's response handler doesn't need to check that it got the right sort of response.