Haskell/Continuation passing style

Continuation Passing Style (CPS for short) is a style of programming in which functions do not return values; rather, they pass control onto a continuation, which specifies what happens next. In this chapter, we are going to consider how that plays out in Haskell and, in particular, how CPS can be expressed with a monad.

What are continuations?
To dispel puzzlement, we will have a second look at an example from way back in the book, when we introduced the  operator:

> map ($ 2) [(2*), (4*), (8*)] [4,8,16]

There is nothing out of ordinary about the expression above, except that it is a little quaint to write that instead of. The  section makes the code appear backwards, as if we are applying a value to the functions rather than the other way around. And now, the catch: such an innocent-looking reversal is at heart of continuation passing style!

From a CPS perspective,  is a suspended computation: a function with general type  which, given another function as argument, produces a final result. The argument is the continuation; it specifies how the computation will be brought to a conclusion. In the example, the functions in the list are supplied as continuations via, producing three distinct results. Note that suspended computations are largely interchangeable with plain values: converts any value into a suspended computation, and passing   as its continuation gives back the original value.

What are they good for?
There is more to continuations than just a parlour trick to impress Haskell newbies. They make it possible to explicitly manipulate, and dramatically alter, the control flow of a program. For instance, returning early from a procedure can be implemented with continuations. Exceptions and failure can also be handled with continuations - pass in a continuation for success, another continuation for fail, and invoke the appropriate continuation. Other possibilities include "suspending" a computation and returning to it at another time, and implementing simple forms of concurrency (notably, one Haskell implementation, Hugs, uses continuations to implement cooperative concurrency).

In Haskell, continuations can be used in a similar fashion, for implementing interesting control flow in monads. Note that there usually are alternative techniques for such use cases, especially in tandem with laziness. In some circumstances, CPS can be used to improve performance by eliminating certain construction-pattern matching sequences (i.e. a function returns a complex structure which the caller will at some point deconstruct), though a sufficiently smart compiler should be able to do the elimination.

Passing continuations
An elementary way to take advantage of continuations is to modify our functions so that they return suspended computations rather than ordinary values. We will illustrate how that is done with two simple examples.

Modified to return a suspended computation,  looks like this:

How the  example works:


 * 1) square x and throw the result into the (\x_squared -> ...) continuation
 * 2) square y and throw the result into the (\y_squared -> ...) continuation
 * 3) add x_squared and y_squared and throw the result into the top level/program continuation.

We can try it out in GHCi by passing  as the program continuation: 25
 * Main> pythagoras_cps 3 4 print

If we look at the type of  without the optional parentheses around  and compare it with the original type of , we note that the continuation was in effect added as an extra argument, thus justifying the "continuation passing style" moniker.

"bar"
 * Main> thrice tail "foobar"

A higher order function such as, when converted to CPS, takes as arguments functions in CPS form as well. Therefore,  will become , and the final type will be. The rest of the definition follows quite naturally from the types - we replace  by the CPS version, passing along the continuation at hand.

The monad
Having continuation-passing functions, the next step is providing a neat way of composing them, preferably one which does not require the long chains of nested lambdas we have seen just above. A good start would be a combinator for applying a CPS function to a suspended computation. A possible type for it would be:

(You may want to try implementing it before reading on. Hint: start by stating that the result is a function which takes a continuation; then, let the types guide you.)

And here is the implementation:

We supply the original suspended computation  with a continuation which makes a new suspended computation (produced by  ) and passes the final continuation   to it. Unsurprisingly, it mirrors closely the nested lambda pattern of the previous examples.

Doesn't the type of  look familiar? If we replace with  and  with  we get the   signature. Furthermore, our old friend plays a  -like role, in that it makes a suspended computation out of a value in a trivial way. Lo and behold, we have a monad! All we need now is a type to wrap suspended computations, with the usual wrapper and unwrapper functions.

The monad instance for  follows directly from our presentation, the only difference being the wrapping and unwrapping cruft:

The end result is that the monad instance makes the continuation passing (and thus the lambda chains) implicit. The monadic bind applies a CPS function to a suspended computation, and  is used to provide the final continuation. For a simple example, the Pythagoras example becomes:

While it is always pleasant to see a monad coming forth naturally, a hint of disappointment might linger at this point. One of the promises of CPS was precise control flow manipulation through continuations. And yet, after converting our functions to CPS we promptly hid the continuations behind a monad. To rectify that, we shall introduce, a function which gives us back explicit control of continuations - but only where we want it.

is a very peculiar function; one that is best introduced with examples. Let us start with a trivial one:

The argument passed to  is a function, whose result is a suspended computation (general type ) which we will refer to as "the   computation". In principle, the  computation is what the whole   expression evaluates to. The caveat, and what makes  so special, is due to , the argument to the argument. It is a function which acts as an eject button: calling it anywhere will lead to the value passed to it being made into a suspended computation, which then is inserted into control flow at the point of the  invocation. That happens unconditionally; in particular, whatever follows a  invocation in the   computation is summarily discarded. From another perspective,  captures the rest of the computation following the  ; calling it throws a value into the continuation at that particular point ("callCC" stands for "call with current continuation"). While in this simple example the effect is merely that of a plain,   opens up a number of possibilities, which we are now going to explore.

Deciding when to use
gives us extra power over what is thrown into a continuation, and when that is done. The following example begins to show how we can use this extra power.

is a slightly pathological function that computes the square of its input and adds three; if the result of this computation is greater than 20, then we return from the  computation (and, in this case, from the whole function) immediately, throwing the string   into the continuation that will be passed to. If not, then we subtract four from our previous computation,  it, and throw it into the continuation. Remarkably,  here is used just like the 'return' statement from an imperative language, that immediately exits the function. And yet, this being Haskell,  is just an ordinary first-class function, so you can pass it to other functions like , store it in a  , etc.

Naturally, you can embed calls to  within do-blocks:

When you call  with a value, the entire   call takes that value. In effect, that makes  a lot like an 'goto' statement in other languages: when we call   in our example, it pops the execution out to where you first called , the   line. No more of the argument to  (the inner do-block) is executed. Hence the following example contains a useless line:

will return, and not  , because we pop out of   before getting to the   line.

Behind the scenes
We have deliberately broken a trend here: normally when we introduce a function we give its type straight away, but in this case we chose not to. The reason is simple: the type is pretty complex, and it does not immediately give insight into what the function does, or how it works. After the initial presentation of, however, we are in a better position to tackle it. Take a deep breath...

We can make sense of that based on what we already know about. The overall result type and the result type of the argument have to be the same (i.e. ), as in the absence of an invocation of  the corresponding result values are one and the same. Now, what about the type of ? As mentioned above, 's argument is made into a suspended computation inserted at the point of the   invocation; therefore, if the latter has type   's argument must have type. As for 's result type, interestingly enough it doesn't matter as long as it is wrapped in the same  monad; in other words, the   stands for an arbitrary type. That happens because the suspended computation made out of the  argument will receive whatever continuation follows the , and so the continuation taken by  's result is irrelevant.

To conclude this section, here is the implementation of. Can you identify  in it?

Though the code is far from obvious, an amazing fact is that the implementations of,   and   for   can be produced automatically from their type signatures - Lennart Augustsson's Djinn  is a program that will do this for you. See Phil Gossett's Google tech talk: for background on the theory behind Djinn; and Dan Piponi's article:  which uses Djinn in deriving continuation passing style.

Example: a complicated control structure
We will now look at some more realistic examples of control flow manipulation. The first one, presented below, was originally taken from "The Continuation monad" section of the All about monads tutorial, used with permission.

is a function that takes an integer. The implementation uses  and   to set up a control structure using   and   that does different things based on the range that   falls in, as stated by the comment at the top. Let us dissect it:


 * 1) Firstly, the   at the top just means that we run the   block that follows with a final continuation of   (or, in other words, we extract the value from the suspended computation unchanged). That is necessary as the result type of   doesn't mention.
 * 2) We bind   to the result of the following   do-block:
 * 3) If   is less than 10, we exit straight away, just showing.
 * 4) If not, we proceed. We construct a list, , of digits of.
 * 5)   (an  ) gets bound to the result of the following inner   do-block.
 * 6) If , i.e., if   has less than 3 digits, we pop out of this inner do-block with the number of digits as the result.
 * 7) If   has less than 5 digits, we pop out of the inner do-block returning the original.
 * 8) If   has less than 7 digits, we pop out of both the inner and outer do-blocks, with the result of the digits of   in reverse order (a  ).
 * 9) Otherwise, we end the inner do-block, returning the sum of the digits of.
 * 10) We end this do-block, returning the String , where X is  , the digits of  , and Y is the result from the inner do-block,.
 * 11) Finally, we return out of the entire function, with our result being the string "Answer: Z", where Z is the string we got from the   do-block.

Example: exceptions
One use of continuations is to model exceptions. To do this, we hold on to two continuations: one that takes us out to the handler in case of an exception, and one that takes us to the post-handler code in case of a success. Here's a simple function that takes two numbers and does integer division on them, failing when the denominator is zero.

How does it work? We use two nested calls to. The first labels a continuation that will be used when there's no problem. The second labels a continuation that will be used when we wish to throw an exception. If the denominator isn't 0,  is thrown into the   continuation, so the execution pops right back out to the top level of. If, however, we were passed a zero denominator, we throw an error message into the  continuation, which pops us out to the inner do-block, and that string gets assigned to   and given to.

A more general approach to handling exceptions can be seen with the following function. Pass a computation as the first parameter (more precisely, a function which takes an error-throwing function and results in the computation) and an error handler as the second parameter. This example takes advantage of the generic  class which covers both   and the corresponding   transformer by default, as well as any other continuation monad which instantiates it.

And here is our  in action:

In this example, error throwing means escaping from an enclosing. The  in   jumps out of  's inner.

Example: coroutines
In this section we make a CoroutineT monad that provides a monad with, which enqueues a new suspended coroutine, and  , that suspends the current thread.

Some example usage: Outputting: 3 4 3 2 4 3 2 4 4

Example: Implementing pattern matching
An interesting usage of CPS functions is to implement our own pattern matching. We will illustrate how this can be done by some examples.

Now we have learnt CPS, we can refactor the code like this.

"It's True" "It's False"
 * Main> check true
 * Main> check false

What happens here is that, instead of plain values, we represent  and   by functions that would choose either the first or second argument they are passed. Since  and   behave differently, we can achieve the same effect as pattern matching. Furthermore,,   and  ,   can be converted back and forth by   and.

We should see how this is related to CPS in this more complicated example.

0 4 9 0 4 9
 * Main> fun Zero
 * Main> fun $ One 3
 * Main> fun $ Two 3 4
 * Main> funCPS zero
 * Main> funCPS $ one 3
 * Main> funCPS $ two 3 4

Similar to former example, we represent values by functions. These function-values pick the corresponding (i.e. match) continuations they are passed to and pass to the latter the values stored in the former. An interesting thing is that this process involves in no comparison. As we know, pattern matching can work on types that are not instances of : the function-values "know" what their patterns are and would automatically pick the right continuations. If this is done from outside, say, by an  function, it would have to inspect and compare the patterns and the values to see if they match -- and thus would need   instances.