This article was first published in issue 15 of The Monad.Reader.

Introduction

Another monad tutorial? Oh my god, why!? Fear not, this article is aimed at Haskellers who are already familiar with monads, though I have of course tried to keep the material as accessible as possible; the first two sections may serve as an initial introduction to monads and the monad laws for the brave.

In this tutorial, I would like to present monads from the viewpoint of operational semantics and how it makes designing and implementing new monads a piece of cake. Put differently, s -> (a,s) is not the only way to implement the state monad and this tutorial aims to present a much more systematic way. I think it is still regrettably underused, hence this text.

The main idea is to view monads as a sequence of instructions to be executed by a machine, so that the task of implementing monads is equivalent to writing an interpreter. The introductory example will be a stack automaton, followed by a remark on a monad for random numbers. Then, to showcase the simplicity of this approach, we will implement backtracking parser combinators, culminating in a straightforward breadth-first implementation equivalent to Claessen’s parallel parsing processes.

For those in the know, I’m basically going to present the principles of Chuan-kai Lin’s Unimo paper. The approach is neither new nor unfamiliar; for example, John Hughes already used it to derive the state monad. But until I read Lin’s paper, I did not understand how valuable it is when done systematically and in Haskell. Ryan Ingram’s MonadPrompt package is another recent formulation.

To encourage reuse, I have also released a package operational on hackage which collects the generic bits of these ideas in a small library. For convenient study, the source code from each section of this article is also available.

Stack Machine - List of Instructions?

Our introductory example will be a stack machine, i.e. an imperative mini-language featuring two instructions push and pop for pushing and popping values onto and from a stack.

In other words, I have imperative programs like the following in mind:

push 5; push 42; pop;

Instructions are separated by semicolons. As shown in the following picture, this program first puts the number 5 on the stack, then puts the number 42 on top of the stack and proceeds to remove it again.

How can we embed such programs into Haskell?

Representation

First we need some way of representing the program text, for instance as a list of instructions:

type Program instr    = [instr]
type StackProgram     = Program StackInstruction
data StackInstruction = Push Int | Pop

Our example is represented as

example = Push 5 : Push 42 : Pop : []

In a sense, the colon (:) for building lists takes the role of the semicolon for sequencing instructions.

Concatenation and thoughts on the interface

Note that this representation gives us a very convenient tool for assembling bigger programs from smaller subprograms: list concatenation (++). For instance,

exampleTwice = example ++ example
    = Push 5 : Push 42 : Pop : Push 5 : Push 42 : Pop : []

is a program that executes example twice. Together with the empty program

empty = []

concatenation obeys the following three well-known laws:

 empty ++ is      =  is                  -- left unit
    is ++ empty   =  is                  -- right unit
(is ++ js) ++ ks  =  is ++ (js ++ ks)    -- associativity

which seem almost too evident to be worth mentioning. For example, it is customary to leave out the parenthesis in the last line altogether.

Once accustomed to the notion of programs and (++) to combine them, the special case of single instructions and (:) for sequencing them is unnecessary. The user of our language does not care that we deem push and pop to be primitive operations but not, for example, the program

replace a = Pop : Push a : []

which replaces the topmost stack element with a; he is entirely content to be given two programs

push :: Int -> StackProgram
pop  :: StackProgram

and two general combinators for building new ones

empty :: StackProgram
(++)  :: StackProgram -> StackProgram -> StackProgram 

without any mention of the distinction between single instruction and compound program. Their difference is but an implementation detail.

Interpreter

Well, to be entirely content, the user also needs a way to run programs. In particular, we need to implement a function interpret that maps the program text to its intended meaning, here a function that transforms a stack of integers.

type Stack a = [a]

interpret :: StackProgram -> (Stack Int -> Stack Int)

The implementation follows the style of operational semantics: inspect the first instruction, change the stack accordingly, and recursively proceed with the remaining list of instructions is:

interpret (Push a : is) stack = interpret is (a : stack)
interpret (Pop    : is) stack = interpret is (tail stack)
interpret []            stack = stack

Oops

“All well and good, but why all the fuss with ‘monads’ then, when lists of instructions will do?” you may ask. Alas, the problem is of course that lists won’t do! We forgot something very important: our programs are completely unable to inspect values from the stack.

For instance, how to write a program that pops the two topmost values and pushes their sum onto the stack? Clearly, we want something like

a <- pop;
b <- pop;
push (a+b);

where each pop returns the element just removed and the arrow <- binds it to a variable. But binding variables is simply impossible to express with our current representation of programs as lists of instructions.

Stack Machine - Monad

Well, if ordinary lists of instructions are not enough to represent programs that involve binding variables like

a <- pop; b <- pop; push (a+b);

then let’s invent some fancy kind of list of instructions that will! The following presentation will be in close analogy to the structure of the previous section.

Representation

Return types

First, if we want to interpret pop as a function that returns something, we had better label it with the type of the value returned! Hence, instead of a plain type

Pop :: StackInstruction

we need an additional type argument

Pop :: StackInstruction Int

which indicates that the Pop instruction somehow returns a value of type Int.

For simplicity, we attribute a return type to push as well, even though it doesn’t really return anything. This can modeled just fine with the unit type ().

Push 42 :: StackInstruction ()
Push    :: Int -> StackInstruction ()

Putting both together, our type of instructions will become

data StackInstruction a where
    Pop  :: StackInstruction Int
    Push :: Int -> StackInstruction ()

If this syntax is alien to you: this is a Generalized Algebraic Data Type (GADT) which allows us to define a data type by declaring the types of its constructors directly. As of Haskell 2010, GADTs are not yet part of the language standard, but they are supported by GHC.

Like instructions, we also have to annotate programs with their return type, so that the definition for StackProgram becomes

data Program instr a where ...

type StackProgram a = Program StackInstruction a

As before, instr is the type of instructions, whereas a is the newly annotated return type.

Binding variables

How to represent the binding of variables? Lambda abstractions will do the trick; imagine the following:

Voila, the last step can be represented in Haskell, with a constructor named Then taking the role of the semicolon:

Pop `Then` \a -> rest 

The idea is that Then plugs the value returned by pop into the variable a. By the way, this is akin to how let expressions can be expressed as lambda abstractions in Haskell:

let a = foo in bar   <=>   (\a -> bar) foo

Anyway, our motivating example can now be represented as

example2 = Pop `Then` (\a -> Pop `Then`
                        (\b -> Push (a+b) `Then` Return))

where Return represents the empty program which we will discuss in a moment. Remember that parentheses around the lambda expressions are optional, so we can also write

example2 = Pop `Then` \a ->
           Pop `Then` \b ->
           Push (a+b) `Then`
           Return

It is instructive to think about the type of Then. It has to be

Then :: instr a -> (a -> Program instr b) -> Program instr b

Except for the return type a in instr a and the lambda abstraction, this is entirely analogous to the “cons” operation (:) for lists.

Empty program

The empty program, corresponding to the empty list [], is best represented by a constructor

Return :: a -> Program instr a

that is not “entirely empty” but rather denotes a trivial instruction that just returns the given value a (hence the name). This is very useful, since we can now choose return values freely. For instance,

example3 = Pop `Then` \a -> Pop `Then` \b -> Return (a*b)

is a program that pops two values from the stack but whose return value is their product.

The fancy list

Taking everything together, we obtain a fancy list of instructions, once again a GADT:

data Program instr a where
    Then   :: instr a -> (a -> Program instr b) -> Program instr b
    Return :: a -> Program instr a

And specialized to our stack machine language, we get

type StackProgram a = Program StackInstruction a

Interpreter

Before thinking thinking further about our new representation, let’s first write the interpreter to see the stack machine in action. This time, however, we are not interested in the final stack, only in the value returned.

interpret :: StackProgram a -> (Stack Int -> a)
interpret (Push a `Then` is) stack     = interpret (is ()) (a:stack)
interpret (Pop    `Then` is) (b:stack) = interpret (is b ) stack
interpret (Return c)         stack     = c

The implementation is like the previous one, except that now, we also have to pass the return values like () and b to the remaining instructions is.

Our example program executes as expected:

GHCi> interpret example3 [7,11]
77

Concatenation and interface

Just as with lists, we can build large programs by concatenating smaller subprograms. And as before, we don’t want the user to bother with the distinction between single instruction and compound program.

We begin with the latter: the function

singleton :: instr a -> Program instr a
singleton i = i `Then` Return

takes the role of \x -> [x] and helps us blur the line between program and instructions:

pop  :: StackProgram Int
push :: Int -> StackProgram ()

pop  = singleton Pop
push = singleton . Push

Now, we define the concatenation operator (often dubbed “bind”) that glues two programs together:

(>>=) :: Program i a -> (a -> Program i b) -> Program i b
(Return a)    >>= js  = js a
(i `Then` is) >>= js  = i `Then` (\a -> is a >>= js)

Apart from the new symbol (>>=) and the new type signature, the purpose and implementation is entirely analogous to (++). And as before, together with the empty program,

return = Return

it obeys three evident laws

return a >>= is     = is a                        -- left unit
is >>= return       = is                          -- right unit
(is >>= js) >>= ks  = is >>= (\a -> js a >>= ks)  -- associativity

also called the monad laws. Since we need to pass return values, the laws are slightly different from the concatenation laws for ordinary lists, but their essence is the same.

The reason that these equations are called the “monad laws” is that any data type supporting two such operations and obeying the three laws is called a monad. In Haskell, monads are assembled in the type class Monad, so we’d have to make an instance

instance Monad (Program instr) where
    (>>=)  = ...
    return = ...

This is similar to lists which are said to constitute a monoid.

We conclude the first part of this tutorial by remarking that the (>>=) operator is the basis for many other functions that build big programs from small ones; these can be found in the Control.Monad module and are described elsewhere.

What we’ve done so far

Those familiar with the state monad will recognize that the whole stack machine was just

State (Stack Int)

in disguise. But surprisingly, we haven’t used the pattern s -> (a,s) for threading state anywhere! Instead, we were able to implement the equivalent of

evalState :: State s -> (s -> a)

directly, even though the type s -> a by itself is too “weak” to serve as an implementation of the state monad.

This is a very general phenomenon and it is of course the main benefit of the operational viewpoint and the new Program instr a type. No matter what we choose as interpreter function or instruction set, the monad laws for (>>=) and return will always hold, for they are entirely independent of these choices. This makes it much easier to define and implement new monads and the remainder of this article aims to give a taste of its power.

Multiple Interpreters

A first advantage of the operational approach is that it allows us to equip one and the same monad with multiple interpreters. We’ll demonstrate this flexibility with an example monad Random that expresses randomness and probability distributions.

The ability to write multiple interpreters is also very useful for implementing games, specifically to account for both human and computer opponents as well as replaying a game from a script. This is what prompted Ryan Ingram to write his MonadPrompt package.

Random Numbers

At the heart of random computations is a type Random a which denotes random variables taking values in a. Traditionally, the type a would be a numeric type like Int, so that Random Int denotes “random numbers”. But for the Haskell programmer, it is only natural to generalize it to any type a. This generalization is also very useful, because it reveals hidden structure: it turns out that Random is actually a monad.

There are two ways to implement this monad: one way is to interpret random variables as a recipe for creating pseudo-random values from a seed, which is commonly written

type Random a = StdGen -> (a,StdGen)

The other is to view them as a probability distribution, as for example expressed in probabilistic functional programming as

type Probability = Double
type Random a    = [(a,Probability)]

Traditionally, we’d have to choose between one way or the other depending on the application. But with the operational approach, we can have our cake and eat it, too! The two ways of implementing random variables can be delegated to two different interpreter functions for one and the same monad Random.

For demonstration purposes, we represent Random as a language with just one instruction uniform that randomly selects an element from a list with uniform probability

type Random a = Program RandomInstruction a

data RandomInstruction a where
    Uniform :: [a] -> RandomInstruction a

uniform :: [a] -> Random a
uniform = singleton . Uniform

For example, a roll of a die is modeled as

die :: Random Int
die = uniform [1..6]

and the sum of two dice rolls is

sum2Dies = die >>= \a -> die >>= \b -> return (a+b)

Now, the two different interpretations are: sampling a random variable by generating pseudo-random values

sample :: Random a -> StdGen -> (a,StdGen)
sample (Return a)             gen = (a,gen)
sample (Uniform xs `Then` is) gen = sample (is $ xs !! k) gen'
    where (k,gen') = System.Random.randomR (0,length xs-1) gen

and calculating its probability distribution

distribution :: Random a -> [(a,Probability)]
distribution (Return a)             = [(a,1)]
distribution (Uniform xs `Then` is) =
    [(a,p/n) | x <- xs, (a,p) <- distribution (is x)]
    where n = fromIntegral (length xs)

Truth to be told, the distribution interpreter has a flaw, namely that it never tallies the probabilities of equal outcomes. That’s because this would require an additional Eq a constraint on the types of return and (>>=), which is unfortunately not possible with the current Monad type class. A workaround for this known limitation can be found in the norm function from the paper on probabilistic functional programming.

Monadic Parser Combinators

Now, it is time to demonstrate that the operational viewpoint also makes the implementation of otherwise advanced monads a piece of cake. Our example will be monadic parser combinators and for the remainder of this article, I will assume that you are somewhat familiar with them already. The goal will be to derive an implementation of Koen Claessen’s ideas from scratch.

Primitives

At their core, monadic parser combinators are a monad Parser with just three primitives:

symbol :: Parser Char
mzero  :: Parser a
mplus  :: Parser a -> Parser a -> Parser a

which represent

• a parser that reads the next symbol from the input stream
• a parser that never succeeds
• a combinator that runs two parsers in parallel

respectively. (The last two operations define the MonadPlus type class.) Furthermore, we need an interpreter, i.e. a function

interpret :: Parser a -> (String -> [a])

that runs the parser on the string and returns all successful parses.

The three primitives are enough to express virtually any parsing problem; here is an example of a parser number that recognizes integers:

satisfies p = symbol >>= \c -> if p c then return c else mzero 
many  p     = return [] `mplus` many1 p
many1 p     = liftM2 (:) p (many p) 
digit       = satisfies isDigit >>= \c -> return (ord c - ord '0')
number      = many1 digit >>= return . foldl (\x d -> 10*x + d) 0

A first implementation

The instruction set for our parser language will of course consist of these three primitive operations:

data ParserInstruction a where
    Symbol :: ParserInstruction Char
    MZero  :: ParserInstruction a
    MPlus  :: Parser a -> Parser a -> ParserInstruction a

type Parser a = Program ParserInstruction a

A straightforward implementation of interpret looks like this:

interpret :: Parser a -> String -> [a]
interpret (Return a)            s = if null s then [a] else []
interpret (Symbol    `Then` is) s = case s of
    c:cs -> interpret (is c) cs
    []   -> []
interpret (MZero     `Then` is) s = []
interpret (MPlus p q `Then` is) s =
    interpret (p >>= is) s ++ interpret (q >>= is) s

For each instruction, we specify the intended effects, often calling interpret recursively on the remaining program is. In prose, the four cases are

• Return at the end of a program will return a result if the input was parsed completely.
• Symbol reads a single character from the input stream if available and fails otherwise.
• MZero returns an empty result immediately.
• MPlus runs two parsers in parallel and collects their results.

A note on technique

The cases for MZero and MPlus are a bit roundabout; the equations

interpret mzero       = \s -> []
interpret (mplus p q) = \s -> interpret p s ++ interpret q s

express our intention more plainly. Of course, these two equations do not constitute valid Haskell code for we may not pattern match on mzero or mplus directly. The only thing we may pattern match on is a constructor, for example like this

interpret (Mplus p q `Then` is) = ...

But even though our final Haskell code will have this form, this does not mean that jotting down the left hand side and thinking hard about the ... is the best way to write Haskell code. No, we should rather use the full power of purely functional programming and use a more calculational approach, deriving the pattern matches from more evident equations like the ones above.

In this case, we can combine the two equations with the MonadPlus laws

    mzero >>= m = mzero
mplus p q >>= m = mplus (p >>= m) (q >>= m)

which specify how mzero and mplus interact with (>>=), to derive the desired pattern match

  interpret (Mplus p q `Then` is)
=   { definition of concatenation and mplus }
  interpret (mplus p q >>= is)
=   { MonadPlus law }
  interpret (mplus (p >>= is) (q >>= is))
=   { intended meaning }
  \s -> interpret (p >>= is) s ++ interpret (q >>= is) s

Now, in light of the first step of this derivation, I even suggest to forget about constructors entirely and instead regard

interpret (mplus p q >>= is) = ...

as “valid” Haskell code; after all, it is straightforwardly converted to a valid pattern match. In other words, it is once again beneficial to not distinguish between single instructions and compound programs, at least in notation.

Depth-first

Unfortunately, our first implementation has a potential space leak, namely in the case

interpret (MPlus p q `Then` is) s =
    interpret (p >>= is) s ++ interpret (q >>= is) s

The string s is shared by the recursive calls and has to be held in memory for a long time.

In particular, the implementation will try to parse s with the parser p >>= is first, and then backtrack to the beginning of s to parse it again with the second alternative q >>= is. That’s why this is called a depth-first or backtracking implementation. The string s has to be held in memory as long the second parser has not started yet.

Breadth-first

To ameliorate the space leak, we would like to create a breadth-first implementation, one which does not try alternative parsers in sequence, but rather keeps a collection of all possible alternatives and advances them at once.

How to make this precise? The key idea is the following equation:

  (symbol >>= is) `mplus` (symbol >>= js)
=  symbol >>= (\c -> is c `mplus` js c)

When the parsers on both sides of mplus are waiting for the next input symbol, we can group them together and make sure that the next symbol will be fetched only once from the input stream.

Clearly, this equation readily extends to more than two parsers, like for example

  (symbol >>= is) `mplus` (symbol >>= js) `mplus` (symbol >>= ks)
=  symbol >>= (\c -> is c `mplus` js c `mplus` ks c)

and so on.

We want to use this equation as a function definition, mapping the left hand side to the right hand side. Of course, we can’t do so directly because the left hand side is not one of the four patterns we can match upon. But thanks to the MonadPlus laws, what we can do is to rewrite any parser into this form, namely with a function

expand :: Parser a -> [Parser a]
expand (MPlus p q `Then` is) = expand (p >>= is) ++
                               expand (q >>= is)
expand (MZero     `Then` is) = []
expand x                     = [x]

The idea is that expand fulfills

foldr mplus mzero . expand = id

and thus turns a parser into a list of summands which we now can pattern match upon. In other words, this function expands parsers matching mzero >>= is and mplus p q >>= is until only summands of the form symbol >>= is and return a remain.

With the parser expressed as a big “sum”, we can now apply our key idea and group all summands of the form symbol >>= is; and we also have to take care of the other summands of the form return a. The following definition will do the right thing:

interpret :: Parser a -> String -> [a]
interpret p = interpret' (expand p)
    where
    interpret' :: [Parser a] -> String -> [a]
    interpret' ps []     = [a | Return a <- ps]
    interpret' ps (c:cs) = interpret'
        [p | (Symbol `Then` is) <- ps, p <- expand (is c)] cs

Namely, how to handle each of the summands depends on the input stream:

• If there are still input symbols to be consumed, then only the summands of the form symbol >>= is will proceed, the other parsers have ended prematurely.
• If the input stream is empty, then only the parsers of the form return x have parsed the input correctly, and their results are to be returned.

That’s it, this is our breadth-first interpreter, obtained by using laws and equations to rewrite instruction lists. It is equivalent to Koen Claessen’s implementation.

As an amusing last remark, I would like to mention that our calculations can be visualized as high school algebra if we ignore that (>>=) has to pass around variables, as shown in the following table:

For example, our key idea corresponds to the distributive law

x × a + x × b = x × (a + b)

and the monad and MonadPlus laws have well-known counterparts in algebra as well.

Conclusion

Further Examples

I hope I have managed to convincingly demonstrate the virtues of the operational viewpoint with my choice of examples.

There are many other advanced monads whose implementations also become clearer when approached this way, such as the list monad transformer (where the naive m [a] is known not to work), Oleg Kiselyov’s LogicT, Koen Claessen’s poor man’s concurrency monad, as well coroutines like Peter Thiemann’s ingenious WASH which includes a monad for tracking session state in a web server.

The operational package includes a few of these examples.

Connection with the Continuation Monad

Traditionally, the continuation monad transformer

data Cont m a = Cont { runCont :: forall b. (a -> m b) -> m b }

has been used to implement these advanced monads. This is no accident; both approaches are capable of implementing any monad. In fact, they are almost the same thing: the continuation monad is the refunctionalization of instructions as functions

\k -> interpret (Instruction `Then` k)

But alas, I think that this unfortunate melange of instruction, interpreter and continuation does not explain or clarify what is going on; it is the algebraic data type Program that offers a clear notion of what a monad is and what it means to implement one. Hence, in my opinion, the algebraic data type should be the preferred way of presenting new monads and also of implementing them, at least before program optimizations.

Actually, Program is not a plain algebraic data type, it is a generalized algebraic data type. It seems to me that this is also the reason why the continuation monad has found more use, despite being conceptually more difficult: GADTs simply weren’t available in Haskell. I believe that the Program type is a strong argument to include GADTs into a future Haskell standard.

Drawbacks

Compared to specialized implementations, like for example s -> (a,s) for the state monad, the operational approach is not entirely without drawbacks.

First, the given implementation of (>>=) has the same quadratic running time problem as (++) when used in a left-associative fashion. Fortunately, this can be ameliorated with a different (fancy) list data type; the operational library implements one.

Second, and this cannot be ameliorated, we lose laziness. The state monad represented as s -> (a,s) can cope with some infinite programs like

evalState (sequence . repeat . state $ \s -> (s,s+1)) 0

whereas the list of instructions approach has no hope of ever handling that, since only the very last Return instruction can return values.

I also think that this loss of laziness also makes value recursion a la MonadFix very difficult.

About the author

After some initial programming experience in Pascal, Heinrich Apfelmus picked up Haskell and purely functional programming just at the dawn of the new millenium. He has never looked back ever since, for he not only admires Haskell’s mathematical elegance, but also its practicality in personal life. For instance, he was always too lazy to tie knots, but that has changed and he now accepts shoe laces instead of velcro.

This article previously appeared in issue 14 of The Monad.Reader.

Introduction

In a post to reddit, user CharlieDancey presented a challenge to write a short and clever morse code decoder. Of course, what could be more clever than writing it in Haskell? ;-)

In the following, I’ll present a series of solutions that gradually include dichotomic search (the straightforward generalization of binary search), stack-based languages or reverse polish notation, and finally deforestation (also called fusion), an optimization technique specific to purely functional languages like Haskell.

For your convenience, source code for the individual sections is available.

A simple first solution

Morse code was designed to be produced and read, or rather heard by humans, who have to memorize the following table:

To write a program that decodes sequences of dots and dashes like

-- --- .-. ... .    -.-. --- -.. .

into letters, we will have to store this table in some form. For instance, we could store each letter and corresponding morse code in a big association list

type MorseCode = String

dict :: [(MorseCode, Char)]
dict =
    [(".-"   , 'A'),
     ("-..." , 'B'),
     ("-.-." , 'C'),
     ...

which we name dict because it’s a dictionary translating between the latin alphabet and morse code. To decode a letter, we simply browse through this list to determine whether it contains a given code of dots and dashes

decodeLetter :: MorseCode -> Char
decodeLetter code = maybe ' ' id $ lookup code dict

Decoding a whole sequence of letters is done with

decode = map decodeLetter . words

so that we have for example

> decode "-- --- .-. ...    . -.-. --- -.. ."
"MORSECODE"

Of course, association lists are a rather slow data structure. A binary search tree, trie, or hash table would be a better choice. But fortunately, it is very easy to change data structures in Haskell. All you have to do is to a qualified import of a different module, such as Data.Map, and change the definition of dict to

dict :: Data.Map.Map MorseCode Char
dict = Data.Map.fromList $
    [(".-"   , 'A'),
     ("-..." , 'B'),
     ("-.-." , 'C'),
     ...

and use Data.Map.lookup instead of Data.List.lookup.

Dichotomic search

Faithfully replicating the morse code table is clear and preferable, but makes for quite large source code. So, let’s make an exception today and think of something as clever as we can.

The idea is the following: whenever an encoded letter starts with a dash '-', we know that it can’t be for example an A or E, because those start with a dot '.'. And if the next symbol is a dot, then it can’t be a G or M because their second symbol is a dash. With each symbol we read, more and more alternatives disappear until we are left with a single alternative. We can depict this with a binary tree:

At each node, the left subtree contains all the letters that can be obtained by adding a dot to the current letter, while the right subtree contains those letters that can be obtained with a dash. This is illustrated by means of a dotted line connected to the left subtree and a dashed line connected to the right subtree.

Now, to decode a letter, we simply start at the root of the tree and follow the dotted or dashed lines depending on the symbols read. For instance, to decode the sequence "-...", we have to go right once and then left thrice, ending up at the letter B. This procedure is also called dichotomic search because at each point in our search for the right letter, we ask a yes/no question “Dot or dash?” (a dichotomy) that partitions the remaining search space into to disjoint parts.

Let’s implement this in Haskell. First, we assume that our dictionary is given as a tree

data Tree a = Leaf
            | Branch { tag   :: a
                     , left  :: Tree a
                     , right :: Tree a }

dict :: Tree Char
dict = Branch ' ' (Branch 'E' ... ) (Branch 'T' ...)

Of course, writing out the dict tree in full is going to be repetitive and boring, but let’s just imagine we have already done that. Then, decoding a letter by walking down the tree is simply a left fold over the code word

decodeLetter = tag . foldl (flip step) dict
    where
    step '.' = left
    step '-' = right

In this case, the accumulated value of the fold is the current subtree, although the term “accumulate” is a bit misleading in that we don’t make the dictionary bigger; we make it smaller by passing to a subtree.

The curious reader may notice that we have actually implemented a trie.

Reverse Polish Notation

Now, let’s reduce the source code needed for the dictionary tree. In Haskell, we’d have to write something like

dict = Branch ' ' (Branch 'E' ... ) (Branch 'T' ...)

Compared to the association list, we got rid of the dots '.' and dashes '-', they have been made implicit in the structure of our tree. But we still need a lot of parenthesis and applications of the Branch function.

A clever way to get rid of parenthesis is reverse polish notation, commonly used in stack-based languages. The idea is that a program in such a language is a sequence of instructions that pop and push values from a stack. For example,

1 2 +

is a program to calculate 1 plus 2. Reading from left to right, the first instruction is 1 which pushes the integer 1 onto the stack. The second instruction is 2, pushing 2 onto the stack. And finally, the instruction + pops the two topmost integers from the stack and pushes their sum onto the stack. This procedure is visualized as follows:

To see how that eliminates the need for parenthesis, take a look the program

1 2 + 3 4 + +

which calculates the sum (1+2)+(3+4).

To build our dictionary tree, we are going to devise a very similar language. Instead of integers, the stack will store whole trees. In analogy to the numerals, there will be an instruction for pushing a Leaf onto the stack; and in analogy to +, there is going to be an instruction for applying the Branch constructor to the two topmost subtrees.

Here’s the program for building the tree, stored as a string:

program :: String
program = "__5__4H___3VS__F___2 UI__L__+_ R__P___1JWAE"
       ++ "__6__=B__/_XD__C__YKN__7_Z__QG__8_ __9__0 OMT "

Each character represents one instruction. The underscore '_' pushes a Leaf onto the stack while all the other character push a Branch tagged with the character in question onto the stack. The interpreter for this tiny programming language can be written using a simple left fold:

dict = interpret program
where
    interpret         = head . foldl exec []
    exec xs       '_' = Leaf         : xs    -- push Leaf
    exec (x:y:xs)  c  = Branch c y x : xs    -- combine subtrees

The stack xs is represented as a list of trees.

Deforestation

We have found a concise way to represent the morse code dictionary in source code, but cleverness does not end here. For instance, how about eliminating the tree entirely?

Chopping trees

Call graph

More precisely, it seems wasteful to construct the dictionary tree by creating leaves and connecting branches only to deconstruct them again when decoding letters. Wouldn’t it be more efficient to interpret the morse code tree as a call graph rather than as a data structure Tree Char?

In other words, imagine say a function e corresponding to the node labeled ‘E’ in the tree, and working as follows:

e :: MorseCode -> Char
e ('.':ds) = i ds
e ('-':ds) = a ds
e []       = 'E'

If the next symbol is a dot or dash, we proceed with the functions i or a corresponding to 'I' and 'A' respectively. And in case we have already reached the end of the code, we know that we have decoded an 'E'. The functions i and a work just like e, except that they proceed with other letters; and the morse code tree becomes their call graph.

A combinator…

Now, writing all these functions by hand would be most error-prone and tedious, they all look the same. But abstracting repetitive patterns is exactly where functional programming shines; we are to devise a combinator that automates the boring parts of the code for us.

What does this combinator look like? Well, the non-boring parts are the letter it represents and the two follow-up functions, so these will be parameters:

combinator :: Char                   -- letter
           -> (MorseCode -> Char)    -- function for dot
           -> (MorseCode -> Char)    -- function for dash
           -> (MorseCode -> Char)    -- result function

That’s all we need; we can implement

combinator c x y = \code -> case code of
    '.':ds -> x ds
    '-':ds -> y ds
    []     -> c

which allows us to write

e = combinator 'E' i a
i = combinator 'I' s u
... etc ...

…revealed!

But wait, what have we done? The type signature of combinator looks exactly like that of

Branch :: Char         -- letter
       -> Tree Char    -- tree for dot
       -> Tree Char    -- tree for dash
       -> Tree Char    -- result tree

but with the type Tree Char replaced by (MorseCode -> Char)! In fact, let’s rename the combinator to lowercase branch

branch c x y = \code -> case code of
    '.':ds -> x ds
    '-':ds -> y ds
    []     -> c

and observe that the tree of functions now reads

e = branch 'E' i a
i = branch 'I' s u
... etc ...

or

e = branch 'E' (branch 'I' ... ) (branch 'A' ...)

if we inline the function definitions. But this is of course just the tree from the section on dichotomic search with each Branch replaced by branch!

In other words, branch is like a drop-in replacement for the constructor Branch. To implement the morse code tree directly as functions instead of as an algebraic data type, we simply replace every occurrence of Branch with branch in our previous code. Thus, we have a new implementation

dict :: MorseCode -> Char
dict = interpret program
    where
    interpret         = head . foldl exec []
    exec xs       '_' = leaf         : xs    -- push leaf
    exec (x:y:xs)  c  = branch c y x : xs    -- combine subtrees

decodeLetter = dict

where

leaf = undefined

is a trivial replacement for the Leaf constructor.

A chainsaw called ‘catamorphism’

Derivation

To further understand how and why the replacement of Branch by branch works, it is instructive to derive it systematically from just the program text.

In particular, consider the implementation of decodeLetter from the earlier section on dichotomic search:

decodeLetter :: MorseCode -> Char
decodeLetter = tag . foldl (flip step) dict
    where
    step '.' = left
    step '-' = right

In this formulation, the focus is on the recursion over the input string performed by foldl, neglecting the recursive descent into the dictionary tree. Let’s systematically rewrite this code to highlight the latter.

First, we interpret it as converting the dictionary tree into a function that decodes letters

decodeLetter = decodeWith dict

decodeWith :: Tree Char -> (MorseCode -> Char)
decodeWith dict = tag . foldl (flip step) dict
    where
    step '.' = left
    step '-' = right

Then, we turn the foldl into explicit recursion

decodeWith dict []     = tag dict
decodeWith dict (d:ds) = decodeWith (step d dict) ds
    where
    step '.' = left
    step '-' = right

and dissolve the step function into the pattern matching

decodeWith dict []       = tag dict
decodeWith dict ('.':ds) = decodeWith (left  dict) ds
decodeWith dict ('-':ds) = decodeWith (right dict) ds

We group the pattern matching on the input code into a case expression

decodeWith dict = \code -> case code of
    []       -> tag dict
    ('.':ds) -> decodeWith (left  dict) ds
    ('-':ds) -> decodeWith (right dict) ds

and finally, we replace the field selectors by pattern matching on the tree, also noting the case of Leaf:

decodeWith Leaf           = undefined
decodeWith (Branch c x y) = \code -> case code of
    []       -> c
    ('.':ds) -> (decodeWith x) ds
    ('-':ds) -> (decodeWith y) ds

The recursion on the tree is apparent now, decodeWith simply traverses both subtrees and combines the results. We can make this even more evident by appealing to the combinator we defined in the previous section:

decodeWith Leaf           = leaf
decodeWith (Branch c x y) = branch c (decodeWith x) (decodeWith y)

In other words, decodeWith takes a tree and simply substitutes each Leaf constructor with leaf and each Branch constructor with branch.

Of course, first using Branch and then replacing it with branch is a waste; we should rather use branch from the start and thus cut away the intermediate tree. That’s exactly what we’ve done in the previous section!

General pattern

Replacing constructors is a very general pattern, not restricted to binary trees. For instance, you probably know following function:

foldr f z []     = z
foldr f z (x:xs) = x `f` foldr f z xs

It’s the good old fold! And at its heart, it just replaces the constructors of the list data type: z is the substitute for the empty list [], and f is put in lieu of the (:) constructor.

In its honor, any function that substitutes constructors in such fashion is known as a generalized fold. A more exotic but commonly used alternative name is “catamorphism”. In other words, decodeWith is a catamorphism.

In this generality, the idea of deforestation is that instead of first constructing a data structure and then chopping it up with a catamorphism, it is more efficient to saw the pieces properly at the time of creation. For example, creating a list and then adding all elements

sum [1..100] = foldr (+) 0 (enumFromTo 1 100)

is less efficient than adding the elements as they are created

sumFromTo a b                            -- changes to enumFromTo
    | a > b     = 0                      -- 0 replaces []
    | otherwise = a + sumFromTo (a+1) b  -- + replaces (:)

Merging two functions in this fashion is also called fusion.

Performing deforestation manually, as we did, sacrifices reusability: the morse code tree only exists as a call graph and cannot be printed out anymore, and sumFromTo is not nearly as useful as are sum and enumFromTo were.

Hence, the goal is to teach the compiler to automatically fuse catamorphisms with their structure creating counterparts, the so called anamorphisms. That’s what efforts like a short-cut to deforestation and the recent stream fusion are set out to do, yielding dramatic gains in efficiency while preserving the compositional style.

Where to go from here

I hope you had fun doodling around with morse code; I certainly did. If you long for more, here a few suggestions:

Cutting words

While we’re at it, the intermediate lists created by words in

decode = map decodeLetter . words

can be deforested as well and fused into the letter decoding. Try it yourself, or see the example source code.

Polish notation and parsing

Polish notation, the converse of reverse polish notation, puts function symbols before their arguments and is thus closer to the Haskell syntax. When the arities of the functions are known in advance, like 2 for Branch and 0 for Leaf, this notation doesn’t require parenthesis either. Write a program in polish notation and a corresponding tiny interpreter to create the morse code tree.

Comparing to C

Since deforestation is supposed to make things faster, how about comparing our deforested morse code tree to say an implementation in C? But instead of doing benchmarks, let me give two general remarks on the machine representation.

First, one might think that the call graph we’ve built is compiled to function calls, with e calling i or a and each function having different machine code, just as we originally intended. But this is actually not the case. When defined with branch, the functions are represented as closures, sharing the same machine code but carrying different records that store their free variables c, x and y. This is not very different from storing c, x and y in a Branch constructor. Template Haskell or some kind of partial evaluation would be needed to hard-code the free variables into the executable. For more on the Haskell execution model, take a look at the GHC commentary.

Second, all our implementations decipher a letter by follow a chain of pointers: descending a tree means following pointers to deeper nodes, and making procedure calls means repeatedly jumping to different code parts. This of course raises questions of cache locality, branch prediction or memory requirements for storing all these pointers.

In C, however, there is another technique available: instead of following a chain of pointers to get to the destination, the address of the final stop is calculated directly with pointer arithmetic. The following example illustrates this:

#include <stdio.h>
#include <string.h>
char buf[99], tree[] = " ETIANMSURWDKGOHVF L PJBXCYZQ  ";
int main() {
    while (scanf("%s", buf)) {
        int n, t=0;
        for(n=0; buf[n]!=0; n++)
            t = 2*t + 1 + (buf[n]&1); /* compute destination */
        putchar(tree[t]);             /* fetch letter */
    }
}

Here, the tree is represented as an array and paths to nodes are encoded as (zero-less) binary numbers. The program calculates the path t to the proper letter and then fetches it with an O(1) memory lookup. Compare also the morse code translator by reddit user kayamon.

Since the number of memory accesses is kept to a minimum, this technique is the most efficient; but it is impossible to reproduce with algebraic data types alone. Fortunately, arrays libraries are readily available in Haskell as well.

The main drawback of this approach, and of arrays in general, is the lack of clarity; indices are notorious for being non-descript and messy. The raw index arithmetic in the example C code above sure seems like magic!

Such magic is best hidden behind a descriptive abstract data type. How about rewriting the example in Haskell such that decodeLetter looks exactly like the one in the section on dichotomic search? In other words, the abstract data type is to support the functions left, right and tag. One possible solution can be found in the source code accompanying this article.

Unfortunately, it appears that Haskell GUI libraries are mostly dormant these days. Both Gtk2Hs and wxHaskell are tricky to install and haven’t seen any recent work on their API. I prefer not to bet on a horse that lies in the grass, regardless of whether it is just sleeping or whether it will never wake up again.

But there is one GUI framework that people are throwing serious efforts at: the web browser! Projects like haste, uhc and ghcjs try to compile Haskell to JavaScript, alternative approaches to Haskell in the web browser are investigated with fay and Ji, and Haskell-like language like elm and roy are showing up.

It looks like these efforts are not ready for prime-time just yet, but I feel compelled to do my part and add fuel to their momentum. Thus, I have whipped up a small demonstration that uses reactive-banana with Ji to create a small GUI example. You can find the project on github in the folder reactive-banana-ji. Here a screenshot:

Typing in one input field will immediately update the other input field, i.e. data can flow in both directions. The source code is very simple, it just declares the value of each input field to be a transformation of the value of the other field. FRP takes care of the recursion and the automatic updates.

The example code still contains more administrative details than I’m happy with, like the compile function and the specialized behaviorValue functions. But that is because neither the DOM bindings, nor my reactive-banana glue have seen any serious API design efforts. The time is ripe for changing that!

It sure looks like 2013 is going to be the year of Haskell in the web browser!

Howdy, cowboy, it’s advertisment time! If you like what I’m doing with reactive-banana, you can support me with a small donation: . (I stopped pestering people with my ¢2 worth status information at the end of every month, though, but that is perhaps for the best.)

In particular, I’m going to explain the new Moment type. Moreover, we’ll elucidate the connection to other approaches to dynamic event switching in Haskell, like the one taken by the sodium library.

What is dynamic event switching?

The concept of “dynamic event switching” also goes by the name of “higher-order events”. The idea is that you can make an event that contains behaviors

example :: Event (Behavior A)

and use it to define a new behavior which acts like the behavior which has occurred last in the event. This is done with the switchB combinator, whose type and semantics ought to be

switchB :: Behavior a -> Event (Behavior a) -> Behavior a
switchB b es = \time ->
    last $ b : [b2 | (time2,b2) <- es, time2 < time]

In other words, you “switch” to a new behavior whenever an event occurrence happens.

Unfortunately, for various fundamental reasons, the types above will have to be more sophisticated than indicated in the dummy examples above. The purpose of this post is to introduce and explain these more sophisticated types.

What is it useful for?

Whenever you have some dynamic collection of events or behaviors, you likely want dynamic event switching.

For instance, imagine that you are programming GUI and want to allocate new widgets dynamically. This is what you need dynamic event switching for. The BarTab.hs example gives a demonstration. Essentially, you have a dynamic collection of text entry widgets which is used to input prices. The total price is calculated from these via the switchB combinator.

eentries :: Event [Behavior Price]
eentries = accumE [] $
        (add <$> eClickAdd) `union` (remove <$> eClickRemove)
    where
    add  x xs = x:xs
    remove xs = drop 1 xs

etotal :: Event (Behavior Price)
etotal = (fmap sum . sequenceA) <$> eentries

btotal :: Behavior Price
btotal = switchB (pure 0) etotal

Note, however, that there are many cases that look like they require dynamic event switching, but which actually don’t. One instance is the Asteroids.hs example, which features a space ship and a collection of moving asteroids. You can model the asteroids as list of time-varying objects [Behavior Asteroid], but it is equally possible to model them as a time-varying list of objects, Behavior [Asteroid]. The latter approach is entirely first-order, but can be less compositional than the former approach.

How does it work?

Now, on to the explanation of how dynamic event switching is done in reactive-banana.

Start times

The first key concept to understand is the notion of start time.

In reactive-banana, each event and behavior has a specific start time, which is indicated by the type parameter t

Event t a       -- event    starting at time t
Behavior t a    -- behavior starting at time t

Now you know what this pesky type parameter t is used for. Of course, you will never plug a concrete time, like 5 o'clock, into the types. Rather, the type parameter is just a dummy that enforces some typing discipline, but I strongly recommend to think of it as an actual clock time.

The Moment monad

The second key concept to understand is a new abstract type, namely the Moment type (constructor). Is is on par with the Event and Behavior abstractions, so we now have a “reactive trinity” of types instead of the old “reactive duopoly”.

Conceptually, the Moment type is very simple, to the point of being almost trivial. Namely, an expression

x :: Moment T A      -- value of type  A  at time  T

simply denotes a value of type A at the specific time T. In other words, it just tags an ordinary value with a specific time; the intention being that the tagged value is only “valid” at this particular moment in time. You also want to perform calculation with tagged values, that’s why Moment t is a monad.

Being able to tag values with clock times is nice and well, but the real magic only starts to happen when you quantify over the time parameter. Namely, an expression

y :: forall t. Moment t A

denotes a value of type A for each time t. Most importantly, this value can be different for different times t. In other words, this quantified version is extremely similar to a Behavior!

(For those who wonder about parametric polymorphism: best think of this as a dependent product, the parameter t is definitely not parametric, at least in spirit.)

The easiest use case for this quantified type is the observeE combinator

observeE :: Event t (forall s. Moment s a) -> Event t a

Whenever the argument event occurs, it just unwraps the tag by setting s to the time of occurrence.

Variable start times and switching

With the Moment monad, it now becomes possible to express the notion of an Event or a Behavior with a variable start time. Namely, consider the type

e :: forall t. Moment t (Event t A)

Thanks to the Moment monad and the quantitifcation, this expression denotes an Event with start time t for each time t. Likewise, the expression

b :: forall t. Moment t (Behavior t A)

denotes a Behavior with variable start time.

The point of all this is that in reactive-banana, we may only switch between Events and Behaviors that have variable start times. In particular, the switching combinators have the types

switchE :: Event t (forall s. Moment s (Event s a)) -> Event t a

switchB :: Behavior t a
    -> Event t (forall s. Moment s (Behavior s a))
    -> Behavior t a

For instance, switchB works like this: whenever the argument event occurs, its payload is a Behavior that starts at the time of occurrence s. This Behavior will be switched into the result until the next event occurs. In other words, the switchB combinator works exactly as described in the introduction, except that the types are slightly more elaborate.

Now you know how to use events and behaviors with variable start times, but I still have to tell you how to construct them. They are created by trimming existing events and behaviors. The relevant combinators are

trimE :: Event t a
    -> Moment t (forall s. Moment s (Event s a))

trimB :: Behavior t a
    -> Moment t (forall s. Moment s (Behavior s a))

Essentially, the trimE function just discards all event occurrences that happen before or on the new start time s. Similarly, the trimB combinator discards the history of the behavior that happens before the new start time s.

All these types are chosen such that you always have to trim an event or behavior before you can switch it in. This is necessary to ensure efficiency, i.e. the absence of time leaks, via the type system.

“forall” in the API

One last thing: if you look at the API documenation, you will notice that the types are slightly different from what I just wrote. But fret not, this is just a harmless technical restriction having to do with impredicative polymorphism. (This doesn’t sound harmless at all, right? But be assured, it is as harmless as a baby banana.)

The thing is just that GHC currently can’t deal very well with forall inside type arguments, so I have made a new type, AnyMoment, to appease the gaelic Haskell gods. Read it like this:

AnyMoment Event a     =  forall s. Moment s (Event s a)
AnyMoment Behavior a  =  forall s. Moment s (Behavior s a)
AnyMoment Identity a  =  forall s. Moment s a

The now and anyMoment functions provide the corresponding mappings (isomorphisms).

Related work

I think it is very instructive to put reactive-banana’s approach to dynamic event switching into context and to clarify its connection to other approaches.

I learned about the importance of trimming from a blog post by Conal Elliott, where he writes that

Failing to trim results in behavior that is incorrect and grossly inefficient. […] (the dreaded “space-time” leak)

The key point of the approach presented here is to enforce trimming via the type system, thereby avoding time leaks statically.

The idea of using a type parameter to denote start times and to control trimming goes back to a paper by Wolfgang Jeltsch. It follows Conal’s method in that trimming is tied to the occurrences of an existing event.

trim :: Behavior b -> Event a -> Event (a, Behavior b)

The key novelty in our approach is the Moment monad, which allows us to obtain trimmed behaviors and events as first-class objects, which is a lot more flexible. Of course, the results of trimB and trimE are wrapped in a Moment t monad, so you do have to specify when trimming should start, but it is no longer necessary to specify when trimming should happen.

Another first-class approach to trimming was introduced by Gergely Patai. It has also been implemented by Stephen Blackheath in his sodium library. They don’t use a type parameter to specify start times, so trimming has to be done “whenever it changes meaning”, which is whenever we accumulate state. For instance, the accumE combinator has the type

accumE :: a -> Event (a -> a) -> Reactive (Event a)

where Reactive is a monad similar to the forall t. Moment t monad. In other words, events with variable start time are first-class and represented by the type Reactive (Event a). Compared to this method, the advantage of our approach is that the accumulation combinators can retain their simple types as we have separate control over trimming via the trimE and trimB combinators. Of course, only time will tell whether this is actually an advantage in practice.

Apart from utility of the Moment type as a device for enforcing typing rules, I think that its interpretation in terms of clock times is so compelling that it probably has theoretical significance as well. Wolfgang Jeltsch has described a Curry-Howards isomorphism from FRP to temporal linear logic, and I think that the Moment monad may enter this picture as well. It corresponds to the ability to embed the category of Haskell values into the category of temporal values. This is important if you want to use FRP within Haskell, otherwise you end up with a separate domain specific language. In other words, it allows us to mix temporal logic with standard lambda calculus.

Alight, that’s everything I wanted to say about APIs for dynamic event switching today. As always, I appreciate your comments.

This version is a big step forward as it features dynamic event switching, which means that you can now make an event which contains other events and do useful things with it. The event will have a type like Event (Event A) and you can, for instance, dynamically switch between the inner events by using the new switchE combinator.

The BarTab.hs example demonstrates the new possibilities. It shows how to create new widgets and behaviors in reaction to event occurrences. When you click the “Add” button, a new edit widget will be added and it’s Behavior will contribute to the total sum.

While dynamic event switching is great news, I also have to point out that version 0.7.0.0 of reactive-banana is a highly experimental release (for my standard of “highly experimental”). Dynamic event switching is not easy to get right, and while I have managed to avoid the dreaded time leaks, there are still major issues with garbage collection. They can be solved, but for now, I wanted to get my preliminary code out there, so that you can experiment with the library and send me your valuable feedback.

API elegance

Aside from efficiency, the other issue with dynamic event switching is that the API is rather complex. This is necessary if we want to void time leaks, but the whole thing does become a little less elegant than the original vision for FRP would have it.

(I will explain the new API in a subsequent post.)

Fortunately, there are several distinct ways to incorporate dynamic event switching into the API.

My “banana-nemesis”, the sodium library, uses an approach first described by Gergely Patai, which forces all accumulating combinators like stepper or accumE into a monad. This is conceptually simple, but I think the notational burden is quite high.

I have taken another approach, which keeps the first-order interface intact, but introduces some additional complexity when you want to use dynamic event switching. My approach was inspired by Wolfgang Jeltsch’s use of rank-2-polymorphism, but goes beyond it and can now express significantly more programs.

I don’t know which of these two API approaches is more convenient to use. Since dynamic event switching is needed rather seldomly, I found it more important to present beginners with a simple first-order API, and to make the higher-order stuff entirely optional. Besides, I thought it would be a good idea to explore a different part of the design space than the sodium library already does. Give it a try and tell us how it works for you!

Changelog

Aside from the new module Reactive.Banana.Switch, the main change compared to the previous 0.6 release is that the NetworkDescription monad is now called Moment and it has a new constraint on the type parameter. You have to exchange the old type

NetworkDescription t a

for the new type

Frameworks t => Moment t a

everwhere.

Moreover, the current version can no longer be compiled with the JavaScript backend of the Utrecht Haskell Compiler. There is no fundamental obstacle to that, as I don’t use any significant GHC-specific extensions; I just haven’t put the time into making this compatible yet. But do note that future versions of reactive-banana will need GHC extensions like weak pointers, so that the problems with garbage collection can be resolved.

Advertisment

Howdy, cowboy, it’s advertisment time! If you like the reactive-banana project, you can support me with a small donation: . Furthermore, at the end of every month, all ardent supporters will receive ¢2 worth of status information and fruity puns! (This magnificent offer can be respectfully declined in your Flattr preferences.)

last Friday, I gave a tutorial session on functional reactive programming (FRP) with reactive-banana at the HaL 7 - Haskell in Halle/Saale meeting.

The tutorial was split into two parts: first a 30 minutes talk where I introduced the basic concepts and then one hour of live demonstration, where I sat down in front of a computer and implemented some examples in a dialogue with the audience. People told me that they liked it very much, which makes me very happy.

For those who could not attend because they don’t speak German, I have now translated the slides from the introductory talk into English and added some annotations. I think they may be a good introduction to the Behavior and Event types.

Henning Thielemann also managed to organize audio and video recordings during the meeting, but it’s not clear whether the quality is alright. Post-processing will probably take a while. A big “thank you” to Henning and the program committee for organizing the meeting in the first place!

EDIT: The video recording of my tutorial is now available on the meeting website. It’s in German, though.

I just wanted to remind you that I’m going to give a tutorial session on functional reactive programming with reactive-banana at the HaL 7 - Haskell in Halle/Saale meeting.

• When? 13 July 2012. 11:30 am
• Where? Martin-Luther-Universität Halle-Wittenberg, Institut für Informatik, Halle/Saale (Germany)
• URL? http://iba-cg.de/hal7.html

In this tutorial session, I’m going to give a short introduction to FRP and then we’ll work through some examples. I encourage everyone to request particular examples from the examples collection or to suggest new ones during the tutorial.

If you want to participate, remember to register for the tutorial as we only have enough space to accomodate 25 people per tutorial. There are other tutorials as well, so check out the program to see if there’s anything else you like. In particular, Andres Löh is giving an introduction to GPU programming with the repa and accelerate libraries.

To get most out of my reactive-banana tutorial, make sure that you install wxHaskell beforehand, as this tends to be a bit difficult.

The session will be in German. Unfortunately, it probably won’t be recorded on video, but I can translate and post my introductory slides afterwards.

However, there is a problem: to keep track of various internals, each package uses a monad. But the two monads are incompatible! It is almost impossible to use one of them as a monad transformer on top of the other. How can we combine them anyway?

Andrew Farmer suggested instead to put the interpreter session into a different thread, the worker thread, and to use MVars for communication between the web server and the worker thread. And indeed, that is how similar projects like active-hs solve this problem as well.

However, I didn’t want to create a new communication protocal just for this situation, so I thought of a generic way to do this, which I want to call “the forklift pattern” and which I will now describe.

Your feedback is appreciated! It’s probably a good idea to release this on hackage, but I would like to iron out a few kinks beforehand. The preliminary source code can be found as a gist. Leave your comments below!

The forklift pattern

So, the situation is this: we have a monad m that, for example, represents an interpreter for Haskell expressions. We want to make its computations available in the IO monad and we can do so by running the monad m in a separate worker thread that communicates via MVars. For instance, in the case of the Haskell interpreter, we want to send Haskell expressions to the worker thread for evaluation.

The simple but key insight is this: what is the most general possible communication protocal for talking to the worker thread? Why, we can simply ask the worker thread to perform an arbitrary action of type m a! In other words, we simply put a complete monadic action into the MVar and have the worker thread execute it for us.

I will call this pattern the “forklift” pattern because we are forking a worker thread to lift arbitrary monadic actions. Nifty.

Here we go. The worker thread is represented by the data type

data ForkLift m = ForkLift { requests :: Chan (m ()) }

which just keeps track of a channel were you can send your monadic actions to. To create a new ForkLift, we fork a worker thread that will forever read values from the channel and execute them

newForkLift :: MonadIO m
            => (m () -> IO ()) -> IO (ForkLift m)
newForkLift unlift = do
    channel <- newChan
    let loop = forever . join . liftIO $ readChan channel
    forkIO $ unlift loop
    return $ ForkLift channel

When we want to execute a monadic action, we can use the forklift to “carry it over to the IO monad”. Getting the result value back is a bit tricky due to type safety, but we can simply use another MVar and encode the sending back in the action itself.

carry :: MonadIO m => ForkLift m -> m a -> IO a
carry forklift act = do
    ref <- newEmptyMVar
    writeChan (requests forklift) $ do
        liftIO . putMVar ref =<< act
    takeMVar ref

And here a quick test with the state monad transformer

test :: IO ()
test = do
    state <- newForkLift (flip evalStateT (0::Int))
    carry state $ modify (+10)
    carry state $ modify (+10)
    print =<< carry state get

-- > test
-- 20

Of course, the evalStateT function was always able to map the state monad to the IO monad, but the point here is that the state is preserved between different invocations of the carry function.

Before I can put this on hackage, there are a few rough edges that need to be smoothed out.

1. What happens when the worker thread dies because of an exception? At the moment, all calls to carry will deadlock. They should probably throw an exception instead, WorkerGone?
2. What about garbage collection? When the ForkLift goes out of scope, then the worker thread should also be killed. See my StackOverflow question.