Free Monads: from the basics to the implementation of composable and effectful stream processing

In the previous post, we introduced IdrisPipes, a library for composable and effectful production, transformation and consumption of streams of data in Idris. We talked about the motivations behind this library, its API and its model, and some of the features it offers.

In this post, we will embark in a journey from the basics of Free Monads and interpreters, to more advanced examples, up to how to implement the core of IdrisPipes. Through this exercise, we will illustrate some aspects that makes the Free Monad interesting.

Disclaimer: This post does not require any previous knowledge of Free Monads. We will start simple, with a first simple example of Free Monad, and slowly introduce more advanced concepts, to finally dive into the internals of IdrisPipes

 

Free Monads – Prelude & Motivations

---

We will start with a quick recap on Monads, and a first introduction to what Free Monads are and what makes them special.

 

Monads as environment of executions

In Haskell and Idris, Monads are a idiomatic way to establish a specific environment of execution for our code, by allowing us to modify the rules of the languages inside the Monad:

• Changing the rules of composition (the Monad itself)
• Changing the available primitives (selecting available effects)
• Allowing for more than one interpretation of a computation(*)

Free Monads allow us to get one step further, and allow us to transform, optimize or combine our computations by manipulating the instructions they are made of.

(*) By using Monad typeclasses instead of concrete Monads. One implementation can interact with the production environment (a real database, etc.), while another can interact with test components (in-memory database, etc.), as described in our previous article about Hexagonal Architecture.

 

Free Monads & AST transformations

Free Monads are special kinds of Monads which produce an Abstract Syntax Tree upon evaluation, a data structure for a recipe to execute. Instead of performing side-effects, they only emit instructions. Nothing really happens until an interpreter reads these instructions to interact with the world (or further transform them until we reach a point where we interact with the world).

This offers us a great flexibility in terms of evaluating the Abstract Syntax Tree. The recipe is completely decoupled from the evaluation of the recipe: we can switch back-ends, writing several interpreters to produce different effects out of the same AST.

This also offer us a great flexibility in terms of consultation or modification of the Abstract Syntax Tree. We can modify our Abstract Syntax Tree, transform it, remove or add some instructions inside it, or even combine several trees together (which is key for building a pipe-like library as we will see).

 

Free Monad – The Basics

---

We will first focus on understanding how Free Monads work. To do so, we will implement a small password guessing function and refactor it to use a Free Monad instead of the IO Monad directly.

Note: The examples below are all in Idris, but are almost portable in Haskell as-is with some minor syntax differences. We use Idris here for convenience: it supports pretty printing lambdas, allowing us to see the AST produced more easily (see 10 things Idris improved over Haskell).

 

A password guessing game

We will consider the following function, named password. It asks a user for a password in the console, and fails after reaching the maximal number of attempt allowed:

We can run this function inside the REPL. Here is a trace of the console, in a scenario in which we successfully log in the system at the second attempt, with the password “Scotty”:

Now, this function is rather rigid and hardly testable. Our goal will be to transform it to use a Free Monad, in order to separate the recipe from the evaluation (and later on manipulate its AST).

 

Defining the Free Monad AST

The first step in defining a Free Monad is to define the structure of its Abstract Syntax Tree. To do so, we need to identify a set of instructions which allows us to write a function such as password.

As for all Monads, all pure computations are automatically supported inside a Free Monad. The AST only needs to encode the instructions which corresponds to the additional desired effects. If we look at our function above, there are only two of them:

• Printing a message in the console
• Reading a line from the console

Here is one such AST, named IOSpec, which supports these two instructions:

• ReadLine represents the instruction of reading a line. It contains a continuation which represents the set of instructions to execute after getting the string from the console.
• Writeline represents the instruction of writing a line. It contains the string to print and the set of instructions to execute after the printing is done.
• Pure is the marker for the end of the computation. It carries inside the result of the overall computation.

 

Examples of AST

Below are some examples of IOSpec Abstract Syntax Tree and their corresponding semantic. This should help you better understand how the instructions of our AST work together:

Now, obviously, writing an AST by hand is not such a great experience. To make it feasible to write reasonable sized function producing such an AST, we will need two more ingredients:

• Functions to factorize the creation of such instructions
• A Monad instance to sequence the instructions: a Free Monad

 

Emitting instructions

We will start with the first ingredient, i.e. functions to easily create fragments of our AST. We need two here, one for each of our basic instructions, printing a line and writing a line:

These two functions create ReadLine and PrintLine instructions whose respective continuations do the simplest thing that makes sense:

• readLine produces a computation that reads a line and returns it unchanged (the continuation wraps the acquired string inside Pure)
• prnLine produces a computation that prints a line and returns an empty tuple afterwards (the continuation returns the empty tuple wrapped in Pure)

 

Free Monad – Chaining instructions

The second ingredient is to make it easy to combine two AST into a single one, sequencing the instructions of one AST after the other. For instance, in order to print the line returned by readline, we need a PrintLine instruction to be injected in the continuation of the ReadLine instruction:

We can implement a Monad instance for IOSpec that will do this sequencing of instruction for us. This will let us profit from the convenient do-notation of Haskell and Idris. The implementation is quite simple (*):

• It looks for the last instruction of the left operand (a Pure instruction)
• And chains to it a new set of instruction that depends on the value Pure contains

We can play in the REPL to get a better feel of how it works:

(*) This implementation is incomplete and requires a Functor and Applicative to be defined, as well as some trickeries with assert_total (for Idris). These are provided here as reference. There are also some issues in terms of efficiency, which will not be addressed here.

 

Refactoring to our Free Monad

Equipped with our factories for instructions, and a Free Monad to combine them, we can refactor our password function to emit an IOSpec AST instead of performing IO actions directly.

This refactoring does not require much changes:

• We replace IO by IOSpec
• We replace putStrLn by prnline
• We replace getLine by readLine

And this is it. Here is the resulting function after transformation:

Now, and upon evaluating this function in the REPL, we get an enormous AST out of it, which correspond to the recipe of our password checking logic (linked here as reference). The last remaining part is to write some interpreters for this AST.

 

Interpreter

We refactored a function performing IO directly, into a function that emits an AST containing the assembly instructions that matches our level of abstraction. For this sequence of instructions to be useful, we need an interpreter to translate it into a lower level language (*).

To complete our example, we will write an interpreter that transforms a computation expressed in the IOSpec Free Monad into a IO computation to execute it. Our interpreter will simply:

• Transform each ReadLine into a getLine call
• Transform each WriteLine into a putStrLn call
• Replace continuations with a IO Monad bind operator (i.e. sequence them)

(*) We can define other kind of interpreters as well, some to test our function and feed it with fake inputs, some to transform it into another data structure. Interpreters do not even have to evaluate the instructions per say, they can also simply transform the data structure.

 

Free Monad – Transforming computations

---

Until know, nothing we did was specific to Free Monads. As mentioned before, it is perfectly possible to have several interpretations of the same computation with regular Monads (for instance, using typeclasses).

We will now look at some additional nice things that we can do with Free Monads, leading us one step closer to understanding how to build a pipe library in Haskell or Idris.

 

A demonstration robot

Let us say that we want to do a nice live demonstration of our program, in which we have a bot that types characters in the console instead of us, feeding our password function with inputs (and giving us back control after the bot is out of instructions to execute).

We can represent the commands our bot is allowed to do as follows:

• Typing represents our bot typing a line in our console application
• Thinking represents our bot thinking out loud, halting and waiting for a notification to continue

Here is an example of instructions for our bot, in which it tries “Spock” as a first password, then thinks, then tries “Scotty”, before giving up on guessing the password:

We will now see how we can combine this sequence of instruction with our password function, yielding another sequence of instructions.

 

Integrating our bot commands

Free Monads allow us to work on a computation by playing with its AST. So we can alter a computation expressed in the IOSpec monad (such as our password function) by inserting into it new IOSpec instructions corresponding our bot commands.

Here is one way to integrate our bot commands into an IOSpec computation:

• We will match a Typing bot command with a ReadLine instruction and transform it into
• A PrintLine instruction to print the text entered by the bot
• A fixed text value to feed into the continuation of ReadLine
• We will transform a Thinking bot command into a:
• A PrintLine instruction to print the thoughts of the bot
• A ReadLine instruction used to wait for notification (and discarding the value read)

The following pipe operator implements this transformation (understanding the whole code is not essential – you can focus on understanding the principle):

• pull traverses an IOSpec computation until it meets a ReadLine instruction, at which point it yields control to the push to insert some bot commands
• push integrates bot commands until it meets a Typing bot command, at which point it gives the bot’s string to the IOSpec computation and resumes it

The overall implementation produces a new IOSpec computation, based on the initial IOSpec computation, and transformed to replace ReadLine instructions by the values provided by the bot.

 

Examples of integrating bot commands

Since combining our bot commands with an IOSpec computation results in a new IOSpec computation, we can use our previous interpreter to evaluate the resulting AST (*).

Here is the console output that correspond to running this runBot function:

It is interesting to note that the bot waits for us to press enter (the empty line after “Trying again”. It would also have given us back control for the last password attempt would “Scotty” been invalid.

It is also interesting to look at the resulting AST after the transformation. You will note that it does not contain any traces left of ReadLine instructions: it has been transformed into a AST consisting only of print line instructions.

(*) The closure property (staying in the same type) is a powerful way of abstraction, as we already talked about in our previous articles about Monoids.

 

Other ideas of transformations

Playing with our bot is just one example of transforming an AST generated by a Free Monad to enrich, transform or combine computations. There are plenty of other transformations we can do (with limits in terms of practicality) such as:

1. Combining two computations, like injecting some instructions of one computation in another
2. Compiling the AST of a high-level computation into a lower-level AST
3. Aspect Oriented Programming, like adding logs around specific instructions automatically (*)

As we will see in the next section, implementing a pipe library such as IdrisPipes will involves making use of Free Monads and the transformation (1) listed above.

(*) Note though, that some of these transformation might just be much easier to do by playing with Monad type-classes instead. But Free Monads can be abstracted behind Monad type-classes as well, and is in fact recommended in many articles such as this one from @jdegoes.

 

Using Free Monads – Example of Idris pipes

---

We covered the basics of Free Monads, and showed how we could play with an AST to transform and enrich a computation. We are now ready to explore a more involved example: the implementation of a stream processing library such as IdrisPipes.

 

The link with streaming packages

In our previous example, we combined an IOSpec computation with the commands of a bot, replacing some of the occurrence of the ReadLine with other instructions (such as printing a line). But there are plenty of other transformation we could have done as well.

For instance, we could also combine two IOSpec computations x and y together to build a new x .| y computation, by plugging the PrintLine instructions of x to the ReadLine instructions y.

• A ReadLine instruction in y would ask (or await) for a string coming from x
• A PrintLine instruction in x would send (or yield) a string to y‘s ReadLine instruction

Now, if we rename ReadLine by Await, PrintLine by Yield and IOSpec by Pipe, we get the basic idea behind the implementation of a streaming library:

This PipeLight AST only allows for strings to be streamed, it does not support additional side-effects, terminations and so on, but gives the idea behind the implementation of Haskell Conduit, Haskell pipes or IdrisPipes.

 

IdrisPipes instructions set

The actual instruction set of IdrisPipes and its corresponding AST is obviously a bit more complex than the one described above. We need to integrate effects, the ability to await or yield different types of values, handle early termination, and more:

The instruction set is slightly enriched:

• Await expects an Either value to support early termination of the upstream pipe
• Action allows us to perform effects of type m inside the pipe

The type parameters of PipeM are also a bit more involved:

• a is the type of the values flowing in from the upstream (left pipe)
• b is the type of the values flowing out to downstream (right pipe)
• m is the Monad the pipe runs in
• r2 is the type of the returned value of the pipe
• r1 is the type of the upstream pipe return value (left pipe)

Overall, the syntax may look a bit different (due to the use of Inf and the use of Generalized Algebraic Data Types), but the basic idea is the same.

 

Emitting, sequencing, combining

As we saw through the example of IOSpec, we need to add a few ingredients to make the construction of an AST practical. We need factory functions for the common instructions, and a Monad instance for sequencing instructions. In IdrisPipes:

• yield, await and lift (from the Monad transformation type-class) are the factory functions
• The Monad instance of PipeM is available in Pipes.Core

Finally, the .| pipe operator allows us to combine two pipes into one, by plugging together the Yield of the left pipe to the Await of the right pipe:

• pull traverses the downstream PipeM computation until it meets an Await instruction, at which point it gives the control to the upstream pipe (via push) to insert its own instructions
• push inserts the upstream instruction until it meets a Yield instruction, at which point it connects it to the downstream pipe’s Await instruction and gives back control downstream

You can note that the type signature of the .| operator makes sure that we cannot plug together pipes that would not connect together in terms of values exchanged.

 

Running a pipe – Interpreter

At this point, the last missing piece is the interpreter, the function that runs a pipeline, and execute the streaming recipe it represents. As described in our previous article on IdrisPipe, we can only running a complete pipeline, i.e. a self sufficient pipe which does not await or yield anything.

IdrisPipes defines a type alias to represent such pipes. An Effect is an alias over PipeM, where Void is used in place of the type of the values flowing in and out of the pipeline (*):

Because we cannot construct a value of type Void, the interpreter of a complete pipeline only has to deal with two instructions:

• An Action to execute some side effect, followed by a continuation
• The Pure instruction for the termination of the computation
• While the other instructions lead to an absurd statement

(*) The Source and Sink are similarly defined, with Void in place of the type for the values flowing in for the Source, and the values flowing out for the Sink.

 

Conclusion and what’s next

---

Here we are. At this point, you should now enough about Free Monads to understand the concept and even build your own. You should have a basic idea of what Free Monads are about, what an interpreter is, and why it might be interesting for you to look further at Free Monads.

You should also know enough about the implementation of IdrisPipes to read its implementation in full, understand it, and maybe even contribute to it if you are interested.

In the following articles, we will look at some more advanced examples of using IdrisPipes, to go beyond the simple ones that I listed in the Readme.

---

Follow @quduval