## Wednesday, December 25, 2013

### Equational reasoning

You may have heard that Haskell is "great for equational reasoning", but perhaps you didn't know precisely what that meant. This post will walk through an intermediate example of equational reasoning to show how you can interpret Haskell code by hand by applying substitutions as if your code were a mathematical expression. This process of interpreting code by substituting equals-for-equals is known as equational reasoning.

#### Equality

In Haskell, when you see a single equals sign it means that the left-hand and right-hand side are substitutable for each other both ways. For example, if you see:

``x = 5``

That means that wherever you see an `x` in your program, you can substitute it with a `5`, and, vice versa, anywhere you see a `5` in your program you can substitute it with an `x`. Substitutions like these preserve the behavior of your program.

In fact, you can "run" your program just by repeatedly applying these substitutions until your program is just one giant `main`. To illustrate this, we will begin with the following program, which should print the number `1` three times:

``````import Control.Monad

main = replicateM_ 3 (print 1)``````

`replicateM_` is a function that repeats an action a specified number of times. Its type when specialized to `IO` is:

``replicateM_ :: Int -> IO () -> IO ()``

The first argument is an `Int` specifying how many times to repeat the action and the second argument is the action we wish to repeat. In the above example, we specify that we wish to repeat the `print 1` action three times.

But what if you don't believe me? What if you wanted to prove to yourself that it repeated the action three times? How would you prove that?

#### Use the source!

You can locate the source to Haskell functions using one of three tricks:

• Use Hoogle, which can also search for functions by type signature

• Use Hayoo!, which is like hoogle, but searches a larger package database and is more strict about matches

• Use Google and search for "hackage <function>". This also works well for searching for packages.

Using either of those three tricks we would locate `replicateM_` here and then we can click the Source link to the right of it to view its definition, which I reproduce here:

``replicateM_ n x = sequence_ (replicate n x)``

The equals sign means that any time we see something of the form `replicateM_ n x`, we can substitute it with `sequence_ (replicate n x)`, for any choice of `n` or `x`. For example, if we choose the following values for `n` and `x`:

``````n = 3

x = print 1``````

... then we obtain the following more specific equation:

``replicateM_ 3 (print 1) = sequence_ (replicate 3 (print 1))``

We will use this equation to replace our program's `replicateM_` command with an equal program built from `sequence` and `replicate`:

``main = sequence_ (replicate 3 (print 1))``

The equation tells us that this substitution is safe and preserves the original behavior of our program.

Now, in order to simplify this further we must consult the definition of both `replicate` and `sequence_`. When in doubt which one to pick, always pick the outermost function because Haskell is lazy and evaluates everything from outside to in.

In this case, our outermost function is `sequence_`, defined here:

``````-- | Combine a list of actions into a single action
sequence_ :: [IO ()] -> IO ()  -- I've simplified the type
sequence_ ms = foldr (>>) (return ()) ms``````

We will substitute this into our `main`, noting that `ms` is `replicate 3 (print 1)` for the purpose of this substitution:

``main = foldr (>>) (return ()) (replicate 3 (print 1))``

Now `foldr` is our outermost function, so we'll consult the definition of `foldr`:

``````-- | 'foldr k z' replaces all `(:)`s with `k`
--   and replaces `[]` with `z`
foldr :: (a -> b -> b) -> b -> [a] -> b
foldr k z  []    = z
foldr k z (x:xs) = k x (foldr k z xs)``````

Here we see two equations. Both equations work both ways, but we don't really know which equation to apply unless we know whether or not the third argument to `foldr` is an empty list or not. We must evaluate the call to `replicate` to see whether it will pass us an empty list or a non-empty list, so we consult the definition of `replicate`:

``````-- | Create a list containing `x` repeated `n` times
replicate :: Int -> a -> [a]
replicate n x = take n (repeat x)

-- Apply the substitution, using these values:
-- n = 3
-- x = print 1

main = foldr (>>) (return ()) (take 3 (repeat (print 1)))``````

Boy, this rabbit hole keeps getting deeper and deeper! However, we must persevere. Let's now consult the definition of `take`:

``````-- | Take the first `n` elements from a list
take :: Int -> [a] -> [a]
take n _      | n <= 0 =  []
take _ []              =  []
take n (x:xs)          =  x : take (n-1) xs``````

Here we see three equations. The first one has a predicate, saying that the equality is only valid if `n` is less than or equal to 0. In our case `n` is 3, so we skip that equation. However, we cannot distinguish which of the latter two equations to use unless we know whether `repeat (print 1)` produces an empty list or not, so we must consult the definition of `repeat`:

``````-- | `repeat x` creates an infinite list of `x`s
repeat :: a -> [a]
repeat x = x:repeat x  -- Simplified from the real definition

-- Apply the substitution, using these values:
-- x = print 1

main = foldr (>>) (return ()) (take 3 (print 1:repeat (print 1)))``````

The buck stops here! Although `repeat` is infinitely recursive, we don't have to fully evaluate it. We can just evaluate it once and lazily defer the recursive call, since all we need to know for now is that the list has at least one value. This now provides us with enough information to select the third equation for `take` that requires a non-empty list as its argument:

``````take n (x:xs)          =  x : take (n-1) xs

-- Apply the substitution, using these values:
-- n  = 3
-- x  = print 1
-- xs = repeat (print 1)

main = foldr (>>) (return ()) (print 1:take 2 (repeat (print 1)))``````

Now we know for sure that `foldr`'s third argument is a non-empty list, so we can select the second equation for `foldr`:

``````foldr k z (x:xs) = k x (foldr k z xs)

-- Apply the substitution, using these values:
-- k  = (>>)
-- z  = return ()
-- x  = print 1
-- xs = take 2 (repeat (print 1))

main =
(>>) (print 1)
(foldr (>>) (return ()) (take 2 (repeat (print 1))))

-- Note: "(>>) x y" is the same thing as "x >> y"
main = print 1 >> foldr (>>)
(return ())
(take 2 (repeat (print 1)))

-- Note: "x >> y" is the same thing as "do { x; y }
main = do
print 1
foldr (>>) (return ()) (take 2 (repeat (print 1)))``````

Now our Haskell runtime knows enough information to realize that it needs to `print` a single 1. The language is smart and will execute the first `print` statement before further evaluating the call to `foldr`.

We can repeat this process two more times, cycling through evaluating `repeat`, `take`, and `foldr`, which emit two additional `print` commands:

``````-- Evaluate `repeat`
main = do
print 1
foldr (>>) (return ()) (take 2 (print 1:repeat (print 1)))

-- Evaluate `take`
main = do
print 1
foldr (>>) (return ()) (print 1:take 1 (repeat (print 1)))

-- Evaluate `foldr`
main = do
print 1
print 1
foldr (>>) (return ()) (take 1 (repeat (print 1)))

-- Evaluate `repeat`
main = do
print 1
print 1
foldr (>>) (return ()) (take 1 (print 1:repeat (print 1)))

-- Evaluate `take`
main = do
print 1
print 1
foldr (>>) (return ()) (print 1:take 0 (repeat (print 1)))

-- Evaluate `foldr`
main = do
print 1
print 1
print 1
foldr (>>) (return ()) (take 0 (repeat (print 1)))``````

Now something different will happen. Let's revisit our definition of `take`:

``````take n _      | n <= 0 =  []
take _ []              =  []
take n (x:xs)          =  x : take (n-1) xs``````

This time the first equation matches, because `n` is now equal to `0`. However, we also know the third equation will match because `repeat` will emit a new element. Whenever more than one equation matches Haskell takes the first one by default, so we use the first equation to substitute the call to `take` with an empty list:

``````main = do
print 1
print 1
print 1
foldr (>>) (return ()) []``````

This then triggers the first equation for `foldr`:

``````foldr k z [] = z

-- Therefore:
main = do
print 1
print 1
print 1
return ()``````

There it is! We've fully expanded out our use of `replicateM_` to prove that it `print`s the number 1 three times. For reasons I won't go into, we can also remove the final `return ()` and finish with:

``````main = do
print 1
print 1
print 1``````

#### Equational reasoning - Part 1

Notice how Haskell has a very straightforward way to interpret all code: substitution. If you can substitute equals-for-equals then you can interpret a Haskell program on pen and paper. Substitution is the engine of application state.

Equally cool: we never needed to understand the language runtime to know what our code did. The Haskell language has a very limited role: ensure that substitution is valid and otherwise get out of our way.

Unlike imperative languages, there are no extra language statements such as `for` or `break` that we need to understand in order to interpret our code. Our printing "loop" that repeated three times was just a bunch of ordinary Haskell code. This is a common theme in Haskell: "language features" are usually ordinary libraries.

Also, had we tried the same pen-and-paper approach to interpreting an imperative language we would have had to keep track of temporary values somewhere in the margins while evaluating our program. In Haskell, all the "state" of our program resides within the expression we are evaluating, and in our case the "state" was the integer argument to `take` that we threaded through our subsitutions. Haskell code requires less context to understand than imperative code because Haskell expressions are self-contained.

We didn't need to be told to keep track of state. We just kept mindlessly applying substitution and perhaps realized after the fact that what we were doing was equivalent to a state machine. Indeed, state is implemented within the language just like everything else.

#### Proof reduction

Proving the behavior of our code was really tedious, and we're really interested in proving more generally reusable properties rather than deducing the behavior of specific, disposable programs. However, we spent a lot of effort to prove our last equation, so we want to pick our battles wisely and only spend time proving equations that we can reuse heavily.

So I will propose that we should only really bother to prove the following four equations in order to cover most common uses of `replicateM_`:

``````-- replicateM_ "distributes" over addition
replicateM_  0      x = return ()
replicateM_ (m + n) x = replicateM_ m x >> replicateM_ n x

-- replicateM_ "distributes" over multiplication
replicateM_  1      = id
replicateM_ (m * n) = replicateM_ m . replicateM_ n``````

The last two equations are written in a "point-free style" to emphasize that `replicateM_` distributes in a different way over multiplication. If you expand those two equations out to a "point-ful style" you get:

``````replicateM_ (m * n) x = replicateM_ m (replicateM_ n x)
replicateM   1      x = x``````

If we could prove these equations, then we could much more easily deduce how `replicateM_` behaves for our example program, because we could transform our code more rapidly like this:

``````replicateM_ 3 (print 1)

-- 3 = 1 + 1 + 1
= replicateM_ (1 + 1 + 1) (print 1)

= do replicateM_ 1 (print 1)
replicateM_ 1 (print 1)
replicateM_ 1 (print 1)

-- replicateM_ 1 x = x
= do print 1
print 1
print 1``````

These four master equations are still very tedious to prove all in one go, but we can break this complex task into smaller bite-sized tasks. As a bonus, this divide-and-conquer approach will also produce several other useful and highly reusable equations along the way.

Let's begin by revisiting the definition of `replicateM_`:

``replicateM_ n x = sequence_ (replicate n x)``

Like many Haskell functions, `replicateM_` is built from two smaller composable pieces: `sequence_` and `replicate`. So perhaps we can also build our proofs from smaller and composable proofs about the individual behaviors of `sequence_` and `replicate`.

Indeed, `replicate` possesses a set of properties that are remarkably similar to `replicateM_`:

``````-- replicate distributes over addition
replicate  0      x = []
replicate (m + n) x = replicate m x ++ replicate n x

-- replicate distributes over multiplication
replicate  1      = return
replicate (m * n) = replicate m <=< replicate n``````

Again, the last two equations can be expanded to a "point-ful" form:

``````-- `return x` is `[x]` for lists
replicate 1 x = [x]

-- `(<=<)` is like a point-free `concatMap` for lists
replicate (m * n) x = concatMap (replicate m) (replicate n x)``````

These four `replicate` equations are easier to prove than the corresponding `replicateM_` equations. If we can somehow prove these simpler equations, then all we have to do is then prove that `sequence_` lifts all of the `replicate` proofs into the equivalent `replicateM_` proofs:

``````-- sequence_ lifts list concatenation to sequencing
sequence_  []        = return ()
sequence_ (xs ++ ys) = sequence_ xs >> sequence_ ys

-- (sequence_ .) lifts list functions to ordinary functions
sequence_ .  return   = id
sequence_ . (f <=< g) = (sequence_ . f) . (sequence_ . g)

-- Point-ful version of last two equations:
sequence_ [x] = x
sequence_ (concatMap f (g x)) = sequence_ (f (sequence_ (g x)))``````

It might not be obvious at first, but the above four equations for `sequence_` suffice to transform the `replicate` proofs into the analogous `replicateM_` proofs. For example, this is how we would prove the first `replicateM_` equation in terms of the first `replicate` equation and the first `sequence` equation:

``````replicateM_ 0 x

-- Definition of `replicateM_`
= sequence_ (replicate 0 x)

-- replicate 0 x = []
= sequence_ []

-- sequence_ [] = return ()
= return ()``````

That was simple. It is only slightly more tricky to prove the second equation:

``````replicateM_ (m + n) x

-- Definition of `replicateM_`
= sequence_ (replicate (m + n) x)

-- replicate (m + n) x = replicate m x ++ replicate n x
= sequence_ (replicate m x ++ replicate n x)

-- sequence (xs ++ ys) = sequence xs >> sequence ys
= sequence_ (replicate m x) >> sequence_ (replicate n x)

-- Definition of `replicateM_`, in reverse!
= replicateM_ m x >> replicateM_ n x``````

Notice how the last step of the proof involves using the original `replicateM_` equation, but instead substituting from right-to-left!

``````--  +-- We can substitute this way --+
--  |                                |
--  ^                                v

replicateM_ n x = sequence_ (replicate n x)

--  ^                                v
--  |                                |
--  +--------- Or this way! ---------+``````

This is a nice example of the utility of bidirectional substitution. We can replace the body of a function with the equivalent function call.

The third `replicateM_` equation is also simple to prove in terms of the third `replicate` and `sequence_` equations. I will use the point-ful forms of all these equations for simplicity:

``````replicateM_ 1 x

-- Definition of `replicateM_`
= sequence_ (replicate 1 x)

-- replicate 1 x = [x]
= sequence_ [x]

-- sequence_ [x] = x
= x``````

The fourth property is surprisingly short, too:

``````replicateM_ (m * n) x

-- Definition of `replicateM_`
= sequence_ (replicate (m * n) x)

-- replicate (m * n) x = concatMap (replicate m) (replicate n x)
= sequence_ (concatMap (replicate m) (replicate n x))

-- sequence_ (concatMap f (g x)) = sequence_ (f (sequence_ (g x)))
= sequence_ (replicate m (sequence_ (replicate n x)))

-- Definition of `replicateM_`, in reverse
= replicateM_ m (replicateM_ n x)``````

#### Equational reasoning - Part 2

We reduced our proofs of the `replicateM_` properties to smaller proofs for `replicate` and `sequence` properties. The overhead of this proof reduction is tiny and we can gain the benefit of reusing proofs for `replicate` and `sequence`.

As programmers we try to reuse code when we program and the way we promote code reuse is to divide programs into smaller composable pieces that are more reusable. Likewise, we try to reuse proofs when we equationally reason about code and the way we encourage proof reuse is to divide larger proofs into smaller proofs using proof reduction. In the above example we reduced the four equations for `replicateM_` into four equations for `replicate` and four equations for `sequence_`. These smaller equations are equally useful in their own right and they can be reused by other people as sub-proofs for their own proofs.

However, proof reuse also faces the same challenges as code reuse. When we break up code into smaller pieces sometimes we take things too far and create components we like to think are reusable but really aren't. Similarly, when we reduce proofs sometimes we pick sub-proofs that are worthless and only add more overhead to the entire proof process. How can we sift out the gold from the garbage?

I find that the most reusable proofs are category laws or functor laws of some sort. In fact, every single proof from the previous section was a functor law in disguise. To learn more about functor laws and how they arise everywhere you can read another post of mine about the functor design pattern.

#### Proof techniques

This section will walk through the complete proofs for the `replicate` equations to provide several worked examples and to also illustrate several useful proof tricks.

I deliberately write these proofs to be reasonably detailed and to skip as few steps as possible. In practice, though, proofs become much easier the more you equationally reason about code because you get better at taking larger steps.

Let's revisit the equations we wish to prove for `replicate`, in point-ful form:

``````replicate  0      x = []
replicate (m + n) x = replicate m x ++ replicate n x

replicate  1      x = [x]
replicate (m * n) x = concatMap (replicate m) (replicate n x)``````

... where `concatMap` is defined as:

``````concatMap :: (a -> [b]) -> [a] -> [b]
concatMap f = foldr ((++) . f) []``````

Now we must use the same equational reasoning skills we developed in the first section to prove all four of these equations.

The first equation is simple:

``````replicate 0 x

-- Definition of `replicate`
= take 0 (repeat x)

-- Definition of `take`
= []

-- Proof complete``````

The second equation is trickier:

``````replicate (m + n) x

-- Definition of `take`
= take (m + n) (repeat x)``````

We can't proceed further unless we know whether or not `m + n` is greater than `0`. For simplicity we'll assume that `m` and `n` are non-negative.

We then do something analogous to "case analysis" on `m`, pretending it is like a Peano number. That means that `m` is either `0` or positive (i.e. greater than 0). We'll first prove our equation for the case where `m` equals `0`:

``````-- Assume: m = 0
= take (0 + n) (repeat x)

-- 0 + n = n
= take n (repeat x)

-- Definition of `(++)`, in reverse
= [] ++ take n (repeat x)

-- Definition of `take`, in reverse
= take 0 (repeat x) ++ take n (repeat x)

-- m = 0
= take m (repeat x) ++ take n (repeat x)

-- Definition of `replicate`, in reverse
= replicate m x ++ replicate n x

-- Proof complete for m = 0``````

Then there is the second case, where `m` is positive, meaning that we can represent `m` as `1` plus some other non-negative number `m'`:

``````-- Assume: m = 1 + m'
= take (1 + m' + n) (repeat x)

-- Definition of `repeat`
= take (1 + m' + n) (x:repeat x)

-- Definition of `take`
= x:take (m' + n) (repeat x)

-- Definition of `replicate` in reverse
= x:replicate (m' + n) x``````

Now we can use induction to reuse the original premise since `m'` is strictly smaller than `m`. Since we are assuming that `m` is non-negative this logical recursion is well-founded and guaranteed to eventually bottom out at the base case where `m` equals `0`:

``````-- Induction: reuse the premise
= x:(replicate m' x ++ replicate n x)

-- Definition of `(++)`, in reverse
= (x:replicate m' x) ++ replicate n x

-- Definition of `replicate`
= (x:take m' (repeat x)) ++ replicate n x

-- Definition of `take`, in reverse
= take (1 + m') (repeat x) ++ replicate n x

-- Definition of `replicate`, in reverse
= replicate (1 + m') x ++ replicate n x

-- m = 1 + m', in reverse
= replicate m x ++ replicate n x

-- Proof complete for m = 1 + m'``````

This completes the proof for both cases so the proof is "total", meaning that we covered all possibilities. Actually, that's a lie because really rigorous Haskell proofs must account for the possibility of non-termination (a.k.a. "bottom"). However, I usually consider proofs that don't account for non-termination to be good enough for most practical purposes.

The third `replicate` law is very straightforward to prove:

``````replicate 1 x

-- Definition of `replicate`
= take 1 (repeat x)

-- Definition of `repeat`
= take 1 (x:repeat x)

-- Definition of `take`
= x:take 0 (repeat x)

-- Definition of `take`
= x:[]

-- [x] is syntactic sugar for `x:[]`
= [x]``````

The fourth equation for `replicate` also requires us to split our proof into two branches. Either `n` is zero or greater than zero. First we consider the case where `n` is zero:

``````replicate (m * n) x

-- Assume: n = 0
= replicate 0 x

-- replicate 0 x = []
= []

-- Definition of `foldr`, in reverse
= foldr ((++) . replicate m) [] []

-- Definition of `concatMap`, in reverse
= concatMap (replicate m) []

-- replicate 0 x = [], in reverse
= concatMap (replicate m) (replicate 0 x)

-- n = 0, in reverse
= concatMap (replicate m) (replicate n x)

-- Proof complete for n = 0``````

Then we consider the case where `n` is greater than zero:

``````replicate (m * n) x

-- Assume: n = 1 + n'
= replicate (m * (1 + n')) x

-- m * (1 + n') = m + m * n'
= replicate (m + m * n') x

= replicate m x ++ replicate (m * n') x

-- Induction: reuse the premise
= replicate m x ++ concatMap (replicate m) (replicate n' x)

-- Definition of `concatMap`
= replicate m x ++ foldr ((++) . replicate m) [] (replicate n' x)

-- Definition of `foldr`, in reverse
= foldr ((++) . replicate m)) [] (x:replicate n' x)

-- Definition of `concatMap`, in reverse
= concatMap (replicate m) (x:replicate n' x)

-- Definition of `replicate`
= concatMap (replicate m) (x:take n' (repeat x))

-- Definition of `take`, in reverse
= concatMap (replicate m) (take (1 + n') (x:repeat x))

-- n = 1 + n', in reverse
= concatMap (replicate m) (take n (x:repeat x))

-- Definition of `repeat`, in reverse
= concatMap (replicate m) (take n (repeat x))

-- Definition of `replicate`, in reverse
= concatMap (replicate m) (replicate n x)

-- Proof complete for n = 1 + n'``````

Hopefully these proofs give an idea for the amount of effort involved to prove properties of moderate complexity. I omitted the final part of proving the `sequence_` equations in the interest of space, but they make for a great exercise.

#### Equational Reasoning - Part 3

• building a formal model of a program's algorithm,
• reasoning about the behavior of the formal model using its axioms, and
• proving that the program matches the model.

In a purely functional language like Haskell you formally reason about your code within the language itself. There is no need for a separate formal model because the code is already written as a bunch of formal equations. This is what people mean when they say that Haskell has strong ties to mathematics, because you can reason about Haskell code the same way you reason about mathematical equations.

This is why Haskell syntax for function definitions deviates from mainstream languages. All function definitions are just equalities, which is why Haskell is great for equational reasoning.

This post illustrated how equational reasoning in Haskell can scale to larger complexity through the use of proof reduction. A future post of mine will walk through a second tool for reducing proof complexity: type classes inspired by mathematics that come with associated type class laws.

## Thursday, December 19, 2013

### Lift error handling with lens-like syntax

One of the main deficiencies of `transformers` is that the `MonadTrans` class does not let you lift functions like `catchError`. The `mtl` library provides one solution to this problem, which is to type-class `catchError` and `throwError` using the `MonadError` type class.

That's not to say that `transformers` has no solution for lifting `catchError` and `throwError`; it's just really verbose. Each module provides a `liftCatch` function that you use to lift a `catchError` function from the base monad to the transformed monad.

For example, `Control.Monad.Trans.State` provides the following `liftCatch` function:

``````Control.Monad.Trans.State.liftCatch
:: (m (a, s) -> (e -> m (a, s)) -> m (a, s))
-> StateT s m a -> (e -> StateT s m a) -> StateT s m a``````

``myStack :: (Monad m, Error e) => StateT s (ErrorT e m)``

... then you would apply `liftCatch` directly to `catchError` to get a catch function that worked at the `StateT` layer:

``````Control.Monad.Trans.State.liftCatch catchError
=> StateT s (ErrorT e m) a
-> (e -> StateT s (ErrorT e m) a)
-> StateT s (ErrorT e m) a``````

But what if you had a `WriterT` layer in between like this:

``myStack :: (Monad m) => StateT s (WriterT w (ErrorT e m))``

You'd have to use `liftCatch` from the `Control.Monad.Trans.Writer` module to further lift the `catchError` to work with this stack:

``````import Control.Monad.Trans.State as S

S.liftCatch (W.liftCatch catchError)
=> StateT s (WriterT w (ErrorT e m)) a
-> (e -> StateT s (WriterT w (ErrorT e m)) a)
-> StateT s (WriterT w (ErrorT e m)) a``````

The advantage of this solution is that type inference works extraordinarily well and it is Haskell98. The disadvantage of this solution is that it is very verbose.

So I will propose a less verbose solution that has a syntax resembling the `lens` library, although there will be no true lenses involved (I think). Define the following `catching` function:

``````catching
=> ((ErrorT e m a -> (e -> ErrorT e m a) -> ErrorT e m a) -> r)
-> r
catching k = k catchError``````

The `k` in the above function will be a series of composed `liftCatch` functions that we will apply to `catchError`. However, in the spirit of the `lens` library we will rename these `liftCatch` functions to be less verbose and more hip and sexy:

``````import qualified Control.Monad.Trans.Maybe  as M
import qualified Pipes.Lift                 as P

state  = S.liftCatch

writer = W.liftCatch

maybe  = M.liftCatch

pipe   = P.liftCatchError``````

Now let's say that we have a monad transformer stack of type:

``````myStack
=> StateT s (MaybeT (ErrorT e m)) r``````

If I want to catch something at the outer `StateT` level, I would just write:

``````myStack = catching (state.maybe) action \$ \e -> do
-- The handler if `action` fails
...``````

If I add more layers to my monad transformer stack, all I have to do is point deeper to the stack by composing more references:

``````myStack
:: (Monad m, Error e, Monoid w)
=> Pipe a b (StateT s (WriterT w (MaybeT m))) r
myStack = catching (pipe.state.writer.maybe) action \$ \e -> ...``````

Also, these references are first-class Haskell values, so you can bundle them and manipulate them with your favorite functional tools:

``````myStack = do
let total = pipe.state.writer.maybe
catching total action1 \$ \e -> ...
catching total action2 \$ \e -> ...``````

This approach has a few advantages over the traditional `MonadError` approach:

• You get improved type inference
• You get type errors earlier in development. With `MonadError` the compiler will not detect an error until you try to run your monad transformer stack.
• You get better type errors. `MonadError` errors will arise at a distance where you call `runErrorT` even though the logical error is probably at the site of the `catchError` function.
• Functional references are first class and type classes are not

However, we don't want to lift just `catchError`. There are many other functions that `transformers` can lift such as `local`, `listen`, and `callCC`. An interesting question would be whether this is some elegant abstraction that packages all these lifting operations into a simple type in the same way that lenses package getters, setters, traversals, maps, and zooms into a single abstraction. If there were, then we could reuse the same references for catching, listening, and other operations that are otherwise difficult to lift:

``````listening (state.error) m

passing (maybe.writer) m

catching (writer.maybe) m \$ \e -> ...``````

I have no idea if such an elegant abstraction exists, though, which is why I'm writing this post to solicit ideas.