# justified-containers
Keyed container types with type-checked proofs of key presence.

# Table of contents

  * [Description](#description)
    * [A simple example](#example)
  * [Motivation](#motivation)
  * [How it works](#how-it-works)
    * [Phantom evidence](#phantom-evidence)


# Description

Have you ever *known* that a key could be found in a certain map? Were you tempted to
reach for `fromJust` or `error` to handle the "impossible" case, when you knew that
`lookup` should give `Just v`? (and did shifting requirements ever make the impossible
become possible after all?)

`Data.Map.Justified` provides a zero-cost `newtype` wrapper around `Data.Map.Map`
that enables you to separate the *proof that a key is present* from the *operations using the key*.
Once you prove that a key is present, you can use it `Maybe`-free in any number of other
operations -- sometimes even operations on other maps!

None of the functions in this module can cause a run-time error, and very few
of the operations return a `Maybe` value.

See the `Data.Map.Justified.Tutorial` module for usage examples, or browse the API of the
most recent release [on Hackage](https://hackage.haskell.org/package/justified-containers/docs/Data-Map-Justified.html).

### Example

```haskell
    withMap test_table $ \table -> do
    
      case member 1 table of
    
        Nothing  -> putStrLn "Sorry, I couldn't prove that the key is present."
    
        Just key -> do
        
          -- We have proven that the key is present, and can now use it Maybe-free...
          putStrLn ("Found key: "     ++ show key)
          putStrLn ("Value for key: " ++ lookup key table)

          -- ...even in certain other maps!
          let table' = reinsert key "howdy" table
          putStrLn ("Value for key in updated map: " ++ lookup key table')
```

Output:

    Found key: Key 1
    Value for key: hello
    Value for key in updated map: howdy

## Motivation: `Data.Map` and `Maybe` values

Suppose you have a key-value mapping using `Data.Map`'s type `Map k v`. Anybody making
use of `Map k v` to look up or modify a value must take into account the possibility
that the given key is not present.

In `Data.Map`, there are two strategies for dealing with absent keys:

  1. Cause a runtime error (e.g. `Data.Map`'s `(!)` when the key is absent)

  2. Return a `Maybe` value (e.g. `Data.Map`'s `lookup`)

The first option introduces partial functions, so is not very palatable. But what is
wrong with the second option?

To understand the problem with returning a `Maybe` value, let's ask what the  `Maybe v` in

```haskell
    lookup :: k -> Map k v -> Maybe v
```

really does for us. By returning
a `Maybe v` value, `lookup key table` is saying "Your program must account
for the possibility that `key` cannot be found in `table`. I will ensure that you
account for this possibility by forcing you to handle the `Nothing` case."
In effect, `Data.Map` is requiring the user to prove they have handled the
possibility that a key is absent whenever they use the `lookup` function.

## Laziness (the bad kind)

Every programmer has probably had the experience of knowing, somehow, that a certain
key is going to be present in a map. In this case, the `Maybe v` feels like a burden:
I already *know* that this key is in the map, why should I have to handle the `Nothing` case?

In this situation, it is tempting to reach for the partial function `fromJust`,
or a pattern match like `Nothing -> error "The impossible happened!"`. But as parts of
the program are changed over time, you may find the impossible has become possible after
all (or perhaps youll see the dreaded and unhelpful `*** Exception: Maybe.fromJust: Nothing`)

It is tempting to reach for partial functions or "impossible" runtime errors here, because
the programmer has proven that the key is a member of the map in some other way. They
know that `lookup` should return a `Just v` --- but the *compiler* doesnt know this!

The idea behind `Data.Map.Justified` is to encode the programmers knowledge that a key
is present *within the type system*, where it can be checked at compile-time. Once a key
is known to be present, `Data.Map.Justified`'s `lookup` will never fail. Your justification
removes the `Just`!

# How it works

Evidence that a key can indeed be found in a map is carried by a phantom type parameter `ph`
shared by both the `Data.Map.Justified.Map` and `Data.Map.Justified.Key` types. If you are
able to get your hands on a value of type `Key ph k`, then you must have already proven that
the key is present in *any* value of type `Map ph k v`.

The `Key ph k` type is simply a `newtype` wrapper around `k`, but the phantom type `ph` allows
`Key ph k` to represent both *a key of type `k`* __and__ *a proof that the key is present in*
*all maps of type `Map ph k v`*.

There are several ways to prove that a key belongs to a map, but the simplest is to just use
`Data.Map.Justified`'s `member` function. In `Data.Map`, `member`
has the type

```haskell
    member :: Ord k => k -> Map k v -> Bool
```

and reports whether or not the key can be found in the map. In `Data.Map.Justified`,
`member` has the type

```haskell
    member :: Ord k => k -> Map ph k v -> Maybe (Key ph k)
```

Instead of a boolean, `Data.Map.Justified`'s `member` either says `the key is not present`
(`Nothing`), or gives back the same key, *augmented with evidence that they key*
*is present*. This key-plus-evidence can then be used to do any number of `Maybe`-free
operations on the map.

`Data.Map.Justified` uses the same rank-2 polymorphism trick used in the `Control.Monad.ST` monad to
ensure that the `ph` phantom type can not be extracted; in effect, the proof that a key is
present can't leak to contexts where the proof would no longer be valid.

## Phantom evidence

You can interpret the `ph` phantom type as a concrete *set of keys*; under this interpretation,
a value of type `Key ph k` is a key of type `k`, belonging to the subset described by `ph`.
Similarly, a `Map ph k v` is a map whose keys are exactly the subset of `k` described by `ph`.
From this perspective, the maps behave as if they were total, leading to their `Maybe`-free behavior.

## Why all the continuations?

Many of the functions in `justified-containers` make use of continuations, but why? As a case-study,
consider the basic function `withMap` that promotes a standard `Data.Map.Map` to a `Data.Map.Justified.Map':

```haskell
import Data.Map.Justified
import qualified Data.Map as M
withMap :: M.Map k v -> (forall ph. Map ph k v -> t) -> t
```

The last `(forall ph. Map ph k v -> t) -> t` part is the continuation.

The idea is that we know there is *some* set of keys `ph` belonging to this particular map, but
at compile-time we may not know exactly what it is. But it does exist, after all, so we should be
able to write

```haskell
withMap :: M.Map k v -> exists ph. Map ph k v
```

Similarly, the `inserting` function could look like

```haskell
inserting :: k -> v -> Map ph k v -> exists ph'. Map ph' k v
```

which can be read as "after inserting a key/value pair, we get a (possibly) different set of keys `ph'`".
But in this case, we actually know a bit more: first, the inserted key will be found in the new map. And
second, every key in `ph` can also be found in `ph'`. We
can encode that knowledge by giving an explicit inclusion of `ph` into `ph'`, encoded as a function of
type `Key ph k -> Key ph' k`. So we could re-write `inserting` with the type

```haskell
inserting :: k -> v -> Map ph k v -> exists ph'. (Key ph' k, Key ph k -> Key ph' k, Map ph' k v)
--                                                \_______/  \___________________/  \_________/
--                                   the new key______|                |                 |
--                                                      the inclusion__|                 |
--                                                                       the new map_____|
```

Likewise, when deleting a key from a map with keys `ph`, we get a new map with keys `ph'` along
with a guarantee that `ph'` is a subset of `ph`. Compared to `inserting`, the inclusion goes the
other way: there is an inclusion of `ph'` in `ph`, encoded as a function of type `Key ph' k -> Key ph l`.
Altogether, we could give `deleting` the type

```haskell
deleting :: k -> Map ph k v -> exists ph'. (Key ph' k -> Key ph k, Map ph' k v)
--                                          \___________________/  \_________/
--                                                    |                 |
--                            the reversed inclusion__|                 |
--                                                      the new map_____|
```

A similar pattern works for other map operations like `union`, `intersection`, `difference`, and
`filter`.

## But what about the continuations?

In the last section, we argued that `deleting` should have a type like

```haskell
deleting :: k -> Map ph k v -> exists ph'. (Key ph' k -> Key ph k, Map ph' k v)
--                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```

But if you check the documentation, you'll see the type

```haskell
deleting :: k -> Map ph k v -> (forall ph'. (Key ph' k -> Key ph k, Map ph' k v) -> t) -> t
--                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```

What happened to the underlined part of the type?

The problem is that Haskell doesn't support existential types directly: the `exists` part of
the type we wrote out is just wishful thinking. Instead, we have to go about things a little
indirectly: we'll *encode* existentially-quantified types, via *rank-2 universally-quantified types*.


The idea can be understood via the Curry-Howard correspondence:
In classical logic, we have an equivalence between the propositions `∃X.P(X)`
and `∀T. ((∀X.F(X) => T) => T)`.  It turns out that this equivalence remains valid
in constructive logic, so we can transport it via the Curry-Howard correspondence to get
an isomorphism between types:

```haskell
exists ph.  Map ph k v ~ (forall ph. Map ph k v -> t) -> t
```

In other words, instead of returning the existentially-quantified type directly
we say "tell me what you wanted to do with that existentially-quantified type,
and I'll do it for you".