Data.Constraint

The kind of lifted constraints

Values of type Dict p capture a dictionary for a constraint of type p.

e.g.

Dict :: Dict (Eq Int)

captures a dictionary that proves we have an:

instance Eq Int

Pattern matching on the Dict constructor will bring this instance into scope.

Witnesses that a value of type e contains evidence of the constraint c.

Mainly intended to allow (\\) to be overloaded, since it's a useful operator.

From a Dict, takes a value in an environment where the instance witnessed by the Dict is in scope, and evaluates it.

Essentially a deconstruction of a Dict into its continuation-style form.

Can also be used to deconstruct an entailment, a :- b, using a context a.

withDict :: Dict c -> (c => r) -> r
withDict :: a => (a :- c) -> (c => r) -> r

Operator version of withDict, with the arguments flipped

This is the type of entailment.

a :- b is read as a "entails" b.

With this we can actually build a category for Constraint resolution.

e.g.

Because Eq a is a superclass of Ord a, we can show that Ord a entails Eq a.

Because instance Ord a => Ord [a] exists, we can show that Ord a entails Ord [a] as well.

This relationship is captured in the :- entailment type here.

Since p :- p and entailment composes, :- forms the arrows of a Category of constraints. However, Category only became sufficiently general to support this instance in GHC 7.8, so prior to 7.8 this instance is unavailable.

But due to the coherence of instance resolution in Haskell, this Category has some very interesting properties. Notably, in the absence of IncoherentInstances, this category is "thin", which is to say that between any two objects (constraints) there is at most one distinguishable arrow.

This means that for instance, even though there are two ways to derive Ord a :- Eq [a], the answers from these two paths _must_ by construction be equal. This is a property that Haskell offers that is pretty much unique in the space of languages with things they call "type classes".

What are the two ways?

Well, we can go from Ord a :- Eq a via the superclass relationship, and then from Eq a :- Eq [a] via the instance, or we can go from Ord a :- Ord [a] via the instance then from Ord [a] :- Eq [a] through the superclass relationship and this diagram by definition must "commute".

Diagrammatically,

                   Ord a
               ins /     \ cls
                  v       v
            Ord [a]     Eq a
               cls \     / ins
                    v   v
                   Eq [a]

This safety net ensures that pretty much anything you can write with this library is sensible and can't break any assumptions on the behalf of library authors.

Type entailment, as written with a single character.

The internal hom for the category of constraints.

This version can be passed around inside Dict, whereas (a => b) is impredicative

foo :: Dict (Ord a => Eq a)
foo = Dict

fails to typecheck due to the lack of impredicative polymorphism, but

foo :: Dict (Ord a |- Eq a)
foo = Dict

typechecks just fine.

due to the hack for the kind of (,) in the current version of GHC we can't actually make instances for (,) :: Constraint -> Constraint -> Constraint, but we can define an equivalent type, that converts back and forth to (,), and lets you hang instances.

Weakening a constraint product

The category of constraints is Cartesian. We can forget information.

Weakening a constraint product

The category of constraints is Cartesian. We can forget information.

Contracting a constraint / diagonal morphism

The category of constraints is Cartesian. We can reuse information.

Constraint product

trans weaken1 (f &&& g) = f
trans weaken2 (f &&& g) = g

due to the hack for the kind of (,) in the current version of GHC we can't actually make instances for (,) :: Constraint -> Constraint -> Constraint, but (,) is a bifunctor on the category of constraints. This lets us map over both sides.

Transitivity of entailment

If we view (:-) as a Constraint-indexed category, then this is (.)

Reflexivity of entailment

If we view (:-) as a Constraint-indexed category, then this is id

Convert a quantified constraint into an entailment.

Any inhabits every kind, including Constraint but is uninhabited, making it impossible to define an instance.

Every constraint implies truth

These are the terminal arrows of the category, and () is the terminal object.

Given any constraint there is a unique entailment of the () constraint from that constraint.

This demonstrates the law of classical logic "ex falso quodlibet"

Apply an entailment to a dictionary.

From a category theoretic perspective Dict is a functor that maps from the category of constraints (with arrows in :-) to the category Hask of Haskell data types.

This functor is fully faithful, which is to say that given any function you can write Dict a -> Dict b there also exists an entailment a :- b in the category of constraints that you can build.

Reify the relationship between a class and its superclass constraints as a class

Given a definition such as

class Foo a => Bar a

you can capture the relationship between 'Bar a' and its superclass 'Foo a' with

instance Class (Foo a) (Bar a) where cls = Sub Dict

Now the user can use 'cls :: Bar a :- Foo a'

Reify the relationship between an instance head and its body as a class

Given a definition such as

instance Foo a => Foo [a]

you can capture the relationship between the instance head and its body with

instance Foo a :=> Foo [a] where ins = Sub Dict