Nauths

Practical uses of monads in Haskell

Antoine Leblanc — 2026-05-28

On the “haskellquestions” subreddit, a user recently asked for some help with monads in Haskell. In their post, they wrote (slightly paraphrased):

I feel stuck. I understand the basic concept of monads, but when it comes to the practical use of different types of monads, I am lost.

My answer to them was one long comment. But, in hindsight, I think that I could have structured my answer a bit differently, I could have chosen better examples, I could have made that comment more helpful. This post is an attempt at doing just so.

In it, we will explore how we can use some standard monads to structure our code, what benefits they bring, and how to use them. In some ways, it covers a lot of what a hypothetical “Haskell 103” would have been, back when I was teaching Haskell at Google.

This post contains optional exercises, that you can expand if you want to test your understanding of each section!

Contents

Preamble
- Do
- Desugaring
Motivating example
- Types
- Goal
Capabilities
- Function type
- Naive implementation
Monads
- Reader
- Writer
- State
- Limitation
Composition
Conclusion

Preamble

This post’s intended audience is people who are in the same boat as that original Reddit user: people who understand monads in Haskell in theory, but struggle to use them in practice. Consequently, this post will not re-explain basic Haskell syntax, and will assume familiarity with it. More importantly, we will not be covering what monads are. This post is not yet another monad tutorial.

In other words, this should make sense to you:

class Applicative m => Monad m where
  (>>=) :: m a -> (a -> m b) -> m b

Ok, so Monad is the trait of types that provide the chaining operator >>= often referred to as andThen in other languages. Great. Now what can we do with that?

Do

Even if this post doesn’t re-explain monads, it’s worth going over do notation. do notation is one of the direct practical benefits of monads; it’s an essential part of the syntax of the language, that desugars to calls to >>=. To demonstrate its convenience, let’s use a slightly contrived example that my former students will remember. Let’s imagine that we want to chain operations in Maybe; that is, operations that can fail to return a result, like a lookup for instance. If we imagine that we have access to those three functions:

lookupTransaction :: TransactionID -> Maybe Transaction
lookupCustomer    :: Transaction -> Maybe UserID
lookupUser        :: UserID -> Maybe User

we could build one new big function that, given a TransactionID, gives us the Maybe User of the corresponding customer if it exists.

Without using monads at all, such a function could be written like this:

lookupTransactionCustomer :: TransactionID -> Maybe User
lookupTransactionCustomer tid =
  case lookupTransaction tid of
    Nothing -> Nothing
    Just transaction ->
      case lookupCustomer transaction of
        Nothing -> Nothing
        Just uid ->
          lookupUser uid

It’s not very complicated, but it’s clunky: at every step, we must check whether we got Just a value, and “return early” if we didn’t and got Nothing. It’s like Go’s if err != nil { return err; }, but with staircases. Surely we can do better.

Obviously we remember that Maybe is a monad! The nitty-gritty details of how to chain operations have already been implemented for us, we don’t have to do all those case _ of manually. Rewriting this function to make use of >>= gives us the following:

lookupTransactionCustomer :: TransactionID -> Maybe User
lookupTransactionCustomer tid =
  lookupTransaction tid >>= \transaction ->
    lookupCustomer transaction >>= \uid ->
      lookupUser uid

This is better, and not just because it’s more terse: each step performs a lookup, and we chain into the next step as long as the previous one gave us a value. But… it’s still a staircase. We can do better, by using the aforementioned “do notation”.

Desugaring

The keyword do opens a block, in which whitespace is significant: newlines separate “statements”. This allows us to write sequential code, step by step, and have it translated back into the correct chain of monadic operations.

-- this do block
foo = do
  a <- bar
  baz
  b <- qux
  pure (a, b)

-- desugars to
foo =
  bar >>= \a ->
    baz >>= \_ ->
      qux >>= \b ->
        pure (a, b)

Armed with this, we can now finally rewrite our example function in its most readable form (if not its most concise):

lookupTransactionCustomer :: TransactionID -> Maybe User
lookupTransactionCustomer tid = do
  transaction <- lookupTransaction tid
  uid <- lookupCustomer transaction
  lookupUser uid

The core thing to remember is that this notation desugars to >>=, meaning that it works for any monad. We can write do blocks for expressions in Maybe, for lists, for IO… and so on.

Exercise 1

Here’s a classic “hello world” example:

main :: IO ()
main = do
  putStrLn "Please input your name:"
  userName <- getLine
  putStrLn $ "Hello " ++ userName ++ "!"

Rewrite it without do, only using >>=.

Solution

main :: IO ()
main =
  putStrLn "Please input your name:" >>= \_ ->
    getLine >>= \userName ->
      putStrLn $ "Hello " ++ userName ++ "!"

If you don’t need the argument to >>=, you can use >> instead:

main :: IO ()
main =
  putStrLn "Please input your name:" >>
    getLine >>= \userName ->
      putStrLn $ "Hello " ++ userName ++ "!"

Exercise 2

Here’s a list comprehension expression:

foo :: [Int] -> [Int]
foo l = [x + 5 | x <- l, even x]

Rewrite it with >>=, and then with do.
Hint: you should use guard :: Bool -> [()].

Solution

All following implementations are valid.

foo l = l >>= \x -> guard (even x) >>= \_ -> pure (x + 5)
foo l = l >>= \x -> guard (even x) >> pure (x + 5)
foo l = l >>= \x -> guard (even x) >> [x + 5]

foo l = do
  x <- l
  guard $ even x
  pure $ x + 5

Motivating example

In our quest to showcase the benefits of monads, let’s set ourselves a goal: let’s build a trivial command-line calculator, with variables. Something we can use like this:

> x = 4
> 6 + x * 3 - 2
16

To complicate things and make them more interesting, let’s imagine that this calculator can be run with a “debug” option, that prints a detail of every step of the calculation:

> x = 4
> 6 + x * 3 - 2
: x = 4
: 4 * 3 = 12
: 6 + 12 = 18
: 18 - 2 = 16
16

The structure of such a program isn’t very complicated: we need a main loop that:

displays a prompt
reads a line
parses the line into a statement
executes the statement

For the sake of not making this post more overwhelming than it already is, we will only cover the last item. That is: assuming that we already have code that parses a line, and our role is to write the execution stage, how do we do that?

Types

Since we assume that the rest of the program is already given, we don’t have to think about what the type representation of our statements needs to be. Here’s what we will be working with:

data AppConfig = AppConfig
  { debugMode :: Bool
  }

type VarName = Text

type Variables = HashMap VarName Int

data Statement
  = SetVariable VarName Expression
  | ComputeExpression Expression

data Expression
  = Literal        Int
  | Variable       VarName
  | Addition       Expression Expression
  | Subtraction    Expression Expression
  | Multiplication Expression Expression
  | Division       Expression Expression
  | Modulo         Expression Expression

We don’t need to represent parentheses, nor to worry about precedence: this is all handled for us during parsing. For instance:

-- the expression
3 + x * 5 / (4 - y)

-- gets parsed as
(Addition
  (Literal 3)
  (Division
    (Multiplication
      (Variable "x")
      (Literal 5)
    )
    (Subtraction
      (Literal 4)
      (Variable "y")
    )
  )
)

Goal

Our job today is to write the execute and evaluate functions, that respectively take a Statement and an Expression as an argument. But the question is… what shape must they take?

execute :: Statement -> ???
execute = error "TODO"

evaluate :: Expression -> ???
evaluate = error "TODO"

We will start by identifying all of the “capabilities” that those functions require: what arguments they need, what must be present in their return type, and so on. Afterwards we will introduce several monads that each, individually, provide one such capability we have identified; and finally we will see how we can bring them all together to find a clean solution.

Capabilities

Function type

To figure out the “capabilities” we need, let’s start by having a look at evaluate. We know what kind of result we want: we want a value, so the result has to be an Int:

evaluate :: Expression -> Int

But, obviously, even if we parsed it correctly, an expression can be incorrect: division by zero, reference to an unknown variable… Not all evaluations will succeed, so we need to be able to handle errors, both in evaluate and in execute: if evaluating an expression can fail, so can executing a statement. We will therefore use our trusty Either to represent our result, with a simple Text error message:

evaluate :: Expression -> Either Text Int

Furthermore, we will need to know whether we are in debug mode or not, so that we know whether to display individual steps of the computation, so evaluate needs to also have access to the AppConfig:

evaluate :: AppConfig -> Expression -> Either Text Int

We probably don’t want evaluate itself to print with IO, so it means we need to return our debug log lines as part of our output type.

evaluate
  :: AppConfig
  -> Expression
  -> Either Text (Int, Seq Text)

And of course we need to have access to our variables. The final form of evaluate therefore becomes:

evaluate
  :: AppConfig
  -> Variables
  -> Expression
  -> Either Text (Int, Seq Text)

For execute, the reasoning is the same, except for the fact that it also needs to return the new map of variables, since it might have been modified by an assignment, leaving us finally with:

execute
  :: AppConfig
  -> Variables
  -> Statement
  -> Either Text (Int, Seq Text, Variables)

Naive implementation

Now that we have an idea of the type of our functions, we can try implementing them “manually”, like we did in our first example earlier. Even with a partial implementation, we can see very quickly that the sum of all of those “capabilities” makes the code complex and quite clunky:

evaluate
  :: AppConfig
  -> Variables
  -> Expression
  -> Either Text (Int, Seq Text)
evaluate appConfig variables expression = case expression of
  Multiplication lhs rhs ->
    case evaluate appConfig variables lhs of
      Left errorMsg -> Left errorMsg
      Right (lhsValue, lhsLog) ->
        case evaluate appConfig variables rhs of
          Left errorMsg -> Left errorMsg
          Right (rhsValue, rhsLog) ->
            let
              result  = lhsValue * rhsValue
              logLine = printf ": %d * %d = %d" lhsValue rhsValue result
            in
              Right
                ( result
                , if debugMode appConfig
                  then lhsLog <> rhsLog |> Text.pack logLine
                  else Seq.empty
                )
  Division lhs rhs ->
    case evaluate appConfig variables lhs of
      Left errorMsg -> Left errorMsg
      Right (lhsValue, lhsLog) ->
        case evaluate appConfig variables rhs of
          Left errorMsg -> Left errorMsg
          Right (rhsValue, rhsLog) ->
            if rhsValue == 0 then
              Left "division by zero"
            else
              let
                result  = lhsValue `div` rhsValue
                logLine = printf ": %d / %d = %d" lhsValue rhsValue result
              in
                Right
                  ( result
                  , if debugMode appConfig
                    then lhsLog <> rhsLog |> Text.pack logLine
                    else Seq.empty
                  )
  _ -> error "TODO"

If you gave up trying to read this halfway through, I can’t blame you. Deep staircases of doom, and a lot of repetition… This isn’t very elegant. Obviously, we can do better, by using monads.

Monads

A first step is to realize that evaluate returns an Either Text value, and so do the intermediate steps, the recursive calls to evaluate itself. So, we can trivially get rid of some of the staircases by using the monadic properties of Either, with a do block!

evaluate
  :: AppConfig
  -> Variables
  -> Expression
  -> Either Text (Int, Seq Text)
evaluate appConfig variables expression = case expression of
  Multiplication lhs rhs -> do
    (lhsValue, lhsLog) <- evaluate appConfig variables lhs
    (rhsValue, rhsLog) <- evaluate appConfig variables rhs
    let
      result  = lhsValue * rhsValue
      logLine = printf ": %d * %d = %d" lhsValue rhsValue result
    Right
      ( result
      , if debugMode appConfig
        then lhsLog <> rhsLog |> Text.pack logLine
        else Seq.empty
      )
  Division lhs rhs -> do
    (lhsValue, lhsLog) <- evaluate appConfig variables lhs
    (rhsValue, rhsLog) <- evaluate appConfig variables rhs
    if rhsValue == 0 then
      Left "division by zero"
    else do
      let
        result  = lhsValue `div` rhsValue
        logLine = printf ": %d / %d = %d" lhsValue rhsValue result
      Right
        ( result
        , if debugMode appConfig
          then lhsLog <> rhsLog |> Text.pack logLine
          else Seq.empty
        )
  _ -> error "TODO"

I don’t think I’m going to have a hard time convincing you that this is better. The code behaves the same, but we no longer do all the tedious manual job of checking each step for errors.

There is a metaphor that you will sometimes see in monad tutorials, that claims that monads are a “programmable semicolon”. I am personally not a huge fan of this comparison, but I think this example illustrates this line of thinking quite well: if you imagine a semicolon separating each statement in those do blocks (which is, by the way, valid syntax, you can do that!), then yeah: how we move from one statement to the next, the invisible glue that binds them, that’s dictated by the monad we have chosen.

Another line of thinking, that we’ll explore in more details if / when I write a part 2 to this post, is to think more in terms of “capability”: what does the monad we have chosen provide us with? In this case, with Either Text, it’s the capability to short-circuit with an error if a computation fails.

Let’s now look at what other repetitive tasks we perform in this version of the code, to see what else we could simplify. There are three aspects worth investigating:

we pass the AppConfig to every function call, in execute, in evaluate, recursively: it would be nice if we could make it an “implicit” part of the code, available where we need it, that we don’t need to explicitly thread along;
whenever we make a recursive call to evaluate, we have to collect the debug logs it outputs and combine then manually;
execute takes the variables as input, returns the new variables as output, and those variables are then threaded through evaluate, it would likewise be nice to be able to abstract that away without manual bookkeeping.

As mentioned earlier, there’s a monad that can help us with each of those problems. Introducing three ubiquitous monads: Reader, Writer, and State.

Reader

The Reader monad is an essential component of most Haskell applications, despite its simplicity. You can think of Reader r a, that is a value a in the Reader r monad, as being equivalent to r -> a: a function that produces an a given a r. You can imagine the r as being some kind of “environment”, accessible to all functions in that Reader r monad; it is often used to store things such as an application config, that we want easily accessible from everywhere without having to manually pass it around.

In practice, Reader provides us with one simple function:

ask :: Reader r r

Which is, basically: while in the context of Reader r, retrieve that value r. For a contrived and unrealistic example:

-- at the top level

compileModule :: Source -> Reader Options Object
compileModule source = do
  rawAST       <- parse source
  validatedAST <- analyze rawAST
  rawIR        <- lower validatedAST
  optimizedIR  <- optimize rawIR
  generateCode optimizedIR

-- deep within the analysis part of the code

analyzeVariableDeclaration
  :: Context
  -> VariableDeclaration
  -> Reader Options (ValidatedVariableDeclaration, [Diagnostic])
analyzeVariableDeclaration context declaration = do
  let shadowsAnExistingVariable =
        varName declaration `isMemberOf` context
  -- we retrieve the options
  options <- ask
  let diagnostics =
        if shouldWarnVariableShadow options &&
           shadowsAnExistingVariable
        then [WarnVariableShadow context declaration]
        else []
  undefined -- TODO

All the way down into some analysis function, we can call ask and retrieve the options, despite the fact that they are never passed explicitly: the type system informs us that every function has the “capability” to ask for the options.

In our calculator example, we could think about using Reader to store the AppConfig, if we weren’t already using the Either monad.

Exercise 3

Here’s a simplified implementation of Reader:

newtype Reader r a = Reader { runReader :: r -> a }

Implement Functor, Applicative, Monad, and ask:

instance Functor (Reader r) where
  fmap :: (a -> b) -> Reader r a -> Reader r b
  fmap = undefined -- TODO

instance Applicative (Reader r) where
  pure :: a -> Reader r a
  pure = undefined -- TODO

  (<*>) :: Reader r (a -> b) -> Reader r a -> Reader r b
  (<*>) = undefined -- TODO

instance Monad (Reader r) where
  (>>=) :: Reader r a -> (a -> Reader r b) -> Reader r b
  (>>=) = undefined -- TODO

ask :: Reader r r
ask = undefined -- TODO

Solution

instance Functor (Reader r) where
  fmap :: (a -> b) -> Reader r a -> Reader r b
  fmap f (Reader a) = Reader $ f . a

instance Applicative (Reader r) where
  pure :: a -> Reader r a
  pure a = Reader (const a)

  (<*>) :: Reader r (a -> b) -> Reader r a -> Reader r b
  Reader f <*> Reader a = Reader $ \r -> (f r) (a r)

instance Monad (Reader r) where
  (>>=) :: Reader r a -> (a -> Reader r b) -> Reader r b
  Reader a >>= f = Reader $ \r -> runReader (f $ a r) r

ask :: Reader r r
ask = Reader id

Writer

Writer is a bit less common, but has its uses. You can think of Writer w a, a value a in the monad Writer w, as a computation that produces the desired a value alongside some additional information w. In short: (a, w). This can be used to collect information, such as debug logs or annotations, without having to do any manual bookkeeping.

In practice, Writer provides us with a few functions, including, most importantly:

tell :: Monoid w => w -> Writer w ()

That is: given some piece of information w, append it to the end of the already collected information. We need the Monoid constraint because we don’t want to restrict the information in the Writer to any kind of structure, like a list: they can be anything that has a default empty value (mempty) and a concatenation operation (mappend); this include all kinds of containers, like Seq Text in our example, but also more specific monoids like First and Last.

In our calculator example, if we didn’t use Either for error handling, if we decided to not handle errors, we could use Writer to handle our text output:

evaluate
  :: AppConfig
  -> Variables
  -> Expression
  -> Writer (Seq Text) Int
evaluate appConfig variables expression = case expression of
  Multiplication lhs rhs -> do
    lhsValue <- evaluate appConfig variables lhs
    rhsValue <- evaluate appConfig variables rhs
    let result = lhsValue * rhsValue
    when (debugMode appConfig) $
      tell $ Seq.singleton $ Text.pack $
        printf ": %d * %d = %d" lhsValue rhsValue result
    pure result
  Division lhs rhs ->
    lhsValue <- evaluate appConfig variables lhs
    rhsValue <- evaluate appConfig variables rhs
    when (rhsValue == 0) $
      -- we are no longer do error handling, so we panic
      error "division by zero"
    let result = lhsValue `div` rhsValue
    when (debugMode appConfig) $
      tell $ Seq.singleton $ Text.pack $
        printf ": %d / %d = %d" lhsValue rhsValue result
    pure result
  _ -> error "TODO"

While we lost the ability to do error handling with Either, this do block being in the Writer monad means we no longer have to manually collect debug text lines and concatenate them: this is handled for us by the monad. If we want to output a log line, we just tell that log line. Seq is a monoid, so we tell a new sequence, and it gets concatenated to the existing sequence of logs.

Exercise 4

Here’s a simplified implementation of Writer:

newtype Writer w a = Writer { runWriter :: (w, a) }

Implement Functor, Applicative, Monad, and tell:

instance Functor (Writer w) where
  fmap :: (a -> b) -> Writer w a -> Writer w b
  fmap = undefined -- TODO

instance Monoid w => Applicative (Writer w) where
  pure :: a -> Writer w a
  pure = undefined -- TODO

  (<*>) :: Writer w (a -> b) -> Writer w a -> Writer w b
  (<*>) = undefined -- TODO

instance Monoid w => Monad (Writer w) where
  (>>=) :: Writer w a -> (a -> Writer w b) -> Writer w b
  (>>=) = undefined -- TODO

tell :: Monoid w => w -> Writer w ()
tell = undefined -- TODO

Solution

instance Functor (Writer w) where
  fmap :: (a -> b) -> Writer w a -> Writer w b
  fmap f (Writer (w, a)) = Writer (w, f a)

instance Monoid w => Applicative (Writer w) where
  pure :: a -> Writer w a
  pure a = Writer (mempty, a)

  (<*>) :: Writer w (a -> b) -> Writer w a -> Writer w b
  Writer (w1, f) <*> Writer (w2, a) = Writer (w1 <> w2, f a)

instance Monoid w => Monad (Writer w) where
  (>>=) :: Writer w a -> (a -> Writer w b) -> Writer w b
  Writer (w1, a) >>= f =
    let Writer (w2, b) = f a
    in  Writer (w1 <> w2, b)

tell :: Monoid w => w -> Writer w ()
tell w = Writer (w, ())

State

Last but certainly not least, State. As the name suggests, State s handles some state s for us. You can think of State s a as a value a that has access to and can modify a state s. Something like s -> (s, a): a function that takes the previous state, and returns the result of the computation alongside the new state.

State provides a few functions to access and modify the state:

get    :: State s s
put    :: s -> State s ()
modify :: (s -> s) -> State s ()

get does something similar to ask: it retrieves the inner state value, put replaces the state with the new provided value, and modify transforms the existing state by applying the provided function (by doing a get then a put).

For a slightly contrived example, we can imagine adding caching to a recursive fibonacci function using State:

-- naive fibonacci (no caching)
fibo :: Int -> Int
fibo 0 = 0
fibo 1 = 1
fibo n = fibo (n-1) + fibo (n-2)

-- with manual caching using a hashmap
fibo :: Int -> Int
fibo n = snd $ go n HashMap.empty
  where
    go
      :: Int
      -> HashMap Int Int
      -> (HashMap Int Int, Int)
    go 0 cache0 = (cache0, 0)
    go 1 cache0 = (cache0, 1)
    go n cache0 =
      case HashMap.lookup n cache0 of
        -- found the value in the cache
        Just result -> (cache0, result)
        -- did not find the value in the cache
        Nothing ->
          let
            -- compute the result recursively
            (cache1, nm1) = go (n-1) cache0
            (cache2, nm2) = go (n-2) cache1
            result = nm1 + nm2
          in
            -- return the new cache
            (HashMap.insert n result cache2, result)

-- with caching using State
fibo :: Int -> Int
fibo n = snd $ runState (go n) HashMap.empty
  where
    go :: Int -> State (HashMap Int Int) Int
    go 0 = pure 0
    go 1 = pure 1
    go n = do
      -- retrieve cache from state
      cache <- get
      case HashMap.lookup n cache of
        -- found the value in the cache
        Just result -> pure result
        -- did not find the value in the cache
        Nothing -> do
          -- compute the result recursively
          nm1 <- go (n-1)
          nm2 <- go (n-2)
          let result = nm1 + nm2
          -- modify the cache
          modify $ HashMap.insert n result
          pure result

As you can notice, thanks to State, we don’t have to manually pass the cache around, which reduces the risk of passing the wrong state (such as passing cache0 to go (n-2)).

In our calculator example, we could use State to store the variables, instead of having execute take a hashmap and return a hashmap, like we currently do.

Exercise 5

Here’s a simplified implementation of State:

newtype State s a = State { runState :: s -> (s, a) }

Implement Functor, Applicative, Monad, get, put, and modify:

instance Functor (State s) where
  fmap :: (a -> b) -> State s a -> State s b
  fmap = undefined -- TODO

instance Applicative (State s) where
  pure :: a -> State s a
  pure = undefined -- TODO

  (<*>) :: State s (a -> b) -> State s a -> State s b
  (<*>) = undefined -- TODO

instance Monad (State s) where
  (>>=) :: State s a -> (a -> State s b) -> State s b
  (>>=) = undefined -- TODO

get :: State s s
get = undefined -- TODO

put :: s -> State s ()
put = undefined -- TODO

modify :: (s -> s) -> State s ()
modify = undefined -- TODO

Solution

instance Functor (State s) where
  fmap :: (a -> b) -> State s a -> State s b
  fmap f (State ma) = State $ \s0 ->
    let (s1, a) = ma s0
    in  (s1, f a)

instance Applicative (State s) where
  pure :: a -> State s a
  pure a = State $ \s0 -> (s0, a)

  (<*>) :: State s (a -> b) -> State s a -> State s b
  State mf <*> State ma = State $ \s0 ->
    let
      (s1, f) = mf s0
      (s2, a) = ma s1
    in
      (s2, f a)

instance Monad (State s) where
  (>>=) :: State s a -> (a -> State s b) -> State s b
  State ma >>= f = State $ \s0 ->
    let
      (s1, a) = ma s0
    in
      runState (f a) s1

get :: State s s
get = State $ \s -> (s, s)

put :: s -> State s ()
put s = State $ const (s, ())

modify :: (s -> s) -> State s ()
modify f = do
  s <- get
  put $ f s

Limitation

We’ve seen how the Reader, Writer, State, and Either monads can help us structure our code: each provides a unique “capability” that makes our code simpler, by moving all the tedious chaining to the background. There is, however, a catch: a do block is in one specific monad. It’s in State, or it’s in Either… So, it looks like we have to choose which monad we are using, which capability we really need, and manually deal with everything else manually, right?

Composition

Of course, no, we don’t have to choose: there are ways for us to create one big monad that combines all of the capabilities of the monads we have already seen, allowing us to use all of them at once.

Amalgam

One approach is to create our own monad, that matches exactly our needs. Something like this:

newtype AppMonad a = AppMonad (
  AppConfig -> Variables -> Either Text (Variables, Seq Text, a)
)

This would solve our needs, but would require a lot of code: we would need to reimplement ask, tell, get, modify… And we would also need to write our own instance of Monad, which, for this type, would look like this:

instance Monad AppMonad where
  AppMonad ma >>= f = AppMonad $ \appConfig variables0 ->
    case ma appConfig variables0 of
      Left errorMsg -> Left errorMsg
      Right (variables1, output1, a) ->
        let AppMonad mb = f a in
          case mb appConfig variables1 of
            Left errorMsg -> Left errorMsg
            Right (variables2, output2, b) ->
              (variables2, output1 <> output2, b)

This approach works, and is better than what we had before: all the complexity is in one place, this implementation of >>=, and the rest of the code can be built in terms of AppMonad. But it is a bit rigid, and requires a lot of manual code. Thankfully, there’s an even more elegant solution: monad transformers.

Transformers

Monad transformers are building blocks, that we can use to create new monads. Their implementation details do not belong in this post but in an hypothetical part 2, so we’ll only cover the basics here. The gist of the idea is this: a monad transformer “transforms” a base monad by adding its capability on top of it, creating a new monad that combines them. It is possible to stack several of them this way, creating more and more complex monads as the stack grows. Many monads define a transformer variant, commonly denoted by a T suffix: StateT, ReaderT, and so on. In fact, combining Reader, Writer, and State is common enough that there’s already a monad that combines all three of them, simply called RWS (or RWST for its transformer version).

This means that instead of defining our AppMonad manually, we can define it by combining all the monads we have seen so far:

type AppMonad =
  -- the reader capability, with our app config, on top of
  ReaderT AppConfig (
    -- the writer capability, for our logs, on top of
    WriterT (Seq Text) (
      -- the state capability, for our variables, on top of
      StateT Variables (
         -- the either capability, for our errors
         Either Text
  )))

If you were to expand all those types one by one, using the simplified implementation provided in the exercises, you’d obtain something extremely similar to our custom amalgam:

type AppMonad a
  =  Variables
  -> AppConfig
  -> Either Text (Variables, (Seq Text, a))

And thanks to some implementation details that we won’t get into, our resulting AppMonad automatically has all of the combined capabilities of its individual parts, and is already a monad by construction. It means we don’t have to implement >>=, we can use ask to retrieve the AppConfig without passing it around manually, we can modify the variables without passing them around manually, we can tell a debug log line without doing any concatenation, and we can even throwError to short-circuit with a Left value whenever we need!

Putting it all together

We can now put everything we’ve seen together, and finally write versions of execute and evaluate that are simple and readable:

evaluate :: Expression -> AppMonad Int
evaluate expression = case expression of
  Multiplication lhs rhs -> do
    lhsValue <- evaluate lhs
    rhsValue <- evaluate rhs
    let
      result  = lhsValue * rhsValue
      logLine = printf ": %d * %d = %d" lhsValue rhsValue result
    debugLog logLine
    pure result
  Division lhs rhs -> do
    lhsValue <- evaluate lhs
    rhsValue <- evaluate rhs
    when (rhsValue == 0) $
      throwError "division by zero"
    let
      result  = lhsValue `div` rhsValue
      logLine = printf ": %d / %d = %d" lhsValue rhsValue result
    debugLog logLine
    pure result
  _ -> error "TODO"
  where
    debugLog :: String -> AppMonad ()
    debugLog line = do
      appConfig <- ask
      when (debugMode appConfig) $
        tell $ Seq.singleton $ Text.pack line

execute :: Statement -> AppMonad ()
execute statement = case statement of
  SetVariable name expression -> do
    value <- evaluate expression
    modify $ HashMap.insert name value
  ComputeExpression expression -> do
    value <- evaluate expression
    tell $ Seq.singleton $ Text.pack $ show value

And I hope that this last example convinces you of the usefulness and beauty of this monadic structure. Look at our recursive calls to evaluate: they only take one argument! No manual bookkeeping whatsoever. The AppConfig is implicitly made available to anyone who asks (like the debugLog helper function), debug logs are concatenated for us without needing to do more than just telling what we want to output, and all short-circuiting on error is handled for us by Either.

Finally, dear reader, one last exercise: draw the rest of the owl! :3

Exercise 6

Implement all the missing parts of evaluate! Each undefined will cause a panic and needs to be replaced with the correct implementation.

evaluate :: Expression -> AppMonad Int
evaluate expression = case expression of
  Literal lit -> do
    undefined
  Variable varName -> do
    variables <- undefined
    case undefined of
      Nothing ->
        throwError $ "variable not found: " <> varName
      Just value -> do
        undefined
  Addition lhs rhs -> do
    undefined
  Subtraction lhs rhs -> do
    undefined
  Multiplication lhs rhs -> do
    lhsValue <- evaluate lhs
    rhsValue <- evaluate rhs
    let
      result  = lhsValue * rhsValue
      logLine = printf ": %d * %d = %d" lhsValue rhsValue result
    debugLog logLine
    pure result
  Division lhs rhs -> do
    lhsValue <- evaluate lhs
    rhsValue <- evaluate rhs
    when (rhsValue == 0) $
      throwError "division by zero"
    let
      result  = lhsValue `div` rhsValue
      logLine = printf ": %d / %d = %d" lhsValue rhsValue result
    debugLog logLine
    pure result
  Modulo lhs rhs -> do
    undefined
  where
    debugLog :: String -> AppMonad ()
    debugLog line = do
      config <- ask
      when (debugMode config) $
        tell $ Seq.singleton $ Text.pack line

Solution

evaluate :: Expression -> AppMonad Int
evaluate expression = case expression of
  Literal lit ->
    pure lit
  Variable varName -> do
    variables <- get
    case HashMap.lookup varName variables of
      Nothing ->
        throwError $ "variable not found: " <> varName
      Just value -> do
        debugLog $ printf ": %s = %d" varName value
        pure value
  Addition lhs rhs -> do
    lhsValue <- evaluate lhs
    rhsValue <- evaluate rhs
    let
      result  = lhsValue + rhsValue
      logLine = printf ": %d + %d = %d" lhsValue rhsValue result
    debugLog logLine
    pure result
  Subtraction lhs rhs -> do
    lhsValue <- evaluate lhs
    rhsValue <- evaluate rhs
    let
      result  = lhsValue - rhsValue
      logLine = printf ": %d - %d = %d" lhsValue rhsValue result
    debugLog logLine
    pure result
  Multiplication lhs rhs -> do
    lhsValue <- evaluate lhs
    rhsValue <- evaluate rhs
    let
      result  = lhsValue * rhsValue
      logLine = printf ": %d * %d = %d" lhsValue rhsValue result
    debugLog logLine
    pure result
  Division lhs rhs -> do
    lhsValue <- evaluate lhs
    rhsValue <- evaluate rhs
    when (rhsValue == 0) $
      throwError "division by zero"
    let
      result  = lhsValue `div` rhsValue
      logLine = printf ": %d / %d = %d" lhsValue rhsValue result
    debugLog logLine
    pure result
  Modulo lhs rhs -> do
    lhsValue <- evaluate lhs
    rhsValue <- evaluate rhs
    when (rhsValue == 0) $
      throwError "division by zero"
    let
      result  = lhsValue `div` rhsValue
      logLine = printf ": %d % %d = %d" lhsValue rhsValue result
    debugLog logLine
    pure result
  where
    debugLog :: String -> AppMonad ()
    debugLog line = do
      config <- ask
      when (debugMode config) $
        tell $ Seq.singleton $ Text.pack line

Conclusion

I really hope this example highlights the practical aspect of monads: how we can use them to structure our code, how each of them provides a “capability”, and how we can compose them to get all of their benefits at once. Obviously, this post glosses over many details: we don’t explain how monad transformers actually work, we don’t cover the use of typeclasses for genericity of capabilities in monadic code, we don’t cover some of the drawbacks and trade-offs (such as performance concerns), we don’t mention the problem of stack ordering… There’s still some ground to cover: this is just the start of the journey!

But I hope this was useful nonetheless! :)

You can find the full code for this trivial calculator on GitHub. Additionally, I’d like to thank Jack Kelly for his in-depth review of this post, and das-g for spotting and fixing an error in the code!

A step-by-step guide to Brainfuck

Antoine Leblanc — 2024-12-22

Making a video essay

Antoine Leblanc — 2023-09-05

I have recently released my first video essay! Unsurprisingly, it’s about monads. :)

Making a video about it rather than a blog post was a choice i made almost a year ago: i wanted to learn something new, i wanted to try something different. I started this journey basically from scratch: no knowledge of video editing, no microphone, no nothing. Looking at the result now, i am conflicted: on one hand i’m happy i have actually finished a project, instead of quietly abandoning it like i have done with so many others; on the other, now that i have a better understanding of what goes into making an essay like this, i see so many mistakes in the end product.

This is why i want to write this. The goal of this post is to collect a list of observations about the process, what went right, what went wrong, both so that i can refer to it when i work on the next one, and on the off chance it might prove useful to someone else.

Writing process

The closest thing to a video essay i had experience with before starting was talks, presentations, classes. Their structure is very similar to the one of an essay: there is an overall point i’m trying to make and argue for, there are pieces of information i’d like to impart along the way, usually in support of said point, and there is some accompanying visual material: slides.

When writing a talk, slides tend to be at the center of my writing process: they dictate the rhythm of the presentation. What i actually say over them is not crucial: as long as i make the point i want to make, the exact words do not matter too much.

But, and this is a lesson i had to learn: stumbling over one’s words is much more tolerable in a live setting, in which there’s no way to do a second take. For a YouTube video, recorded in the comfort of home… leaving mistakes in is simply not acceptable.

And, well, i have a bit of a speech impediment: i stammer a bit, and often trip over my own words. Every line in the final essay had to be recorded at least twice (and often more) to get one good take… To reduce this, when re-recording the voice-over sections, i used a fully written script instead. Reading text, rather than trying to come up with good sentences on the fly, significantly improved the quality of the lines, and reduced the number of errors. It also made writing closed captioning easier, since i already had most of the text.

So, first lesson learned: i need to write a full script, and perhaps use a prompter. It is not enough to just plan the outline, get in front of the camera, and improvise.

Writing block and scheduling

However, i found it difficult to write down every sentence i was planning to say ahead of time. Most of the script i actually wrote after shooting the live sections, when recording the lines over the slides, on the fly. A main reason why is that i was struggling to put things in writing before doing at least one live recording, before i could get a feel for the flow of it. I tried to use Google Docs’ speech recognition tool to do a test recording, and use the transcript, but the result wasn’t really usable.

What unblocked me was to do a real recording, in front of the camera. That’s when i spotted a lot of issues, identified what needed work, found the flow. Unfortunately, due to some time constraints, that recording ended up being the only recording session, meaning that every bit of live video in the final product is from the draft. You might notice that there are more pauses, more hesitations in some of the live sections: that’s why.

So, moving forward, one big lesson: start by recording a real draft. It can be used to identify problems, unblock the script writing process… It provides a base, that can be even be used to do a draft of the editing. But, if recording a draft is one of the earliest things to do; filming the live sections comes last. Video clips are the hardest part to fix after the fact: the slides, the voice over, the editing, everything can be changed at the last minute. But live sections require make-up, lighting, set-up… So they should be done last, when the script is set, to avoid needing reshoots or aggressive cuts.

Video

I do not have a dedicated camera, so i used my phone. Specifically, i used DroidCam OBS to use my phone as a video source in OBS on my computer. The upside was that i didn’t have to record everything on my phone, transfer it, and look at the result: i have direct visual feedback on my computer screen, and can pause / restart the recording without having to touch my phone. Overall, this worked pretty well, and i have no major takeaway here, beyond: it works. A phone is good enough for the video.

There are, however, two limitations i need to investigate for next time:

the feed was not a steady 60FPS, and some frame drops can be noticed in the final video; this is probably because i was connecting to OBS over WiFi instead of USB, so this might prove to be easy to fix;
with this solution i can only record in 1080p; the problem with this is that my final output is also in 1080p, meaning that any zoom / cropping of the recording visibly reduces the quality of the output; this can be observed in the essay, but is not shocking, but is nonetheless worth investigating moving forward.

Specifically, what i’ve done is to film from further afar than needed, to avoid problems of focus: my two first attempts at recording were lost because of that: in the first, my phone focused on the background, in the second the phone focused on my face and blurred the background. Filming from slightly afar gave a better result, worked better with the light, and i just zoomed the footage a bit during the editing. It might prove better to run experiments there as well to see if i can use the optical zoom of my phone to achieve the same effect without sacrificing the output resolution.

So, here, an obvious takeaway: take short test footage to test the parameters, instead of doing what i did and realizing after 45 minutes of recording that i am out of focus in the footage…

Audio

Good audio is primordial. It is commonly known that users can tolerate bad video quality, but won’t tolerate bad audio. I have invested in a decent dynamic microphone, with the idea that it would reduce the amount of background noise that would be picked up compared to a condenser microphone. I don’t know enough about the topic to know for sure if that was the correct decision; but the result, as far as my untrained ears can tell, is pretty decent: the voice-over sections sound pretty good: investing into a good microphone is worth it.

However, a downside of the particular microphone i’ve chosen: it has quite a short range. In the live sections, it is slightly too far compared to my setup during the voice-over sections, and the sound comes out a bit worse. There again, it should go without saying, but i seem to need the reminder: i should take short test footage to test the audio as well.

Two other improvements i’ll attempt for the next video:

use Audacity instead of OBS to record voice clips, at least for the voice-over sections, to have more control over the result (i’ve noticed some weird artefacts in some places that i suspect might have come from the mixing in OBS?)
i will invest in a pop filter: i’ve noticed that the plosives are very noticeable in some sections; i might not be able to use it in the live sections if i want my face to remain visible, but since my content is primarily voice-over it would make a difference where it matters.

Editing

I’ve been using DaVinci Resolve 18. I had no prior experience with it, and i didn’t have any experience with any other editing software either, so it’s hard for me to offer a detailed review, but: it’s free, it works great, it does much more than what i needed.

However, there’s one thing that’s been pointed out to me that i can relay and emphasize here: for live sections, avoid cross fades. I think there’s only one left that i forgot to remove, at the very beginning. Nothing wrong with them on a technical level, but that’s not what’s considered elegant nowadays as far as YouTube editing goes.

A small detail: it’s better to organize all the files that end up in the project (video clips, audio clips, images, sound effects…) under one given folder, rather than using them where they are, scattered across the drive, it makes making back-ups easier. There again, it feels obvious in hindsight, but…

Accessibility

Something extremely important to do on the YouTube side of things: always include close captioning. Exporting the script as a text file and feeding it to YouTube works surprisingly well as far as timing is concerned. The way it cuts sentences, however, is abysmal, and it took me several hours of work to get them in a good state. I’ll try next time to format the file differently to see if i can make the YouTube editor do the right thing on the first try.

Two other important accessibility notes that came up in the comments:

include a warning if the video contains flashing lights, which feels obvious, and yet is often forgotten;
avoid only using colors to convey information: information on screen should also be readable by colorblind folks.

Beyond

This was a first attempt, and while i’ve learned a lot in the process, i now better realize how little i know, and how much more i have to learn. But, the essay was overall a success: small audience, as can be expected for Haskell content from a previously unknown source, but positive feedback. I think the most important takeaway of all is that you don’t need a lot of resources to get started. I used my phone, free editing software… the only purchases were a decent microphone (that i needed anyway, since i’m a remote worker, and i don’t want to inflict a sub-par microphone on my co-workers) and a simple ring light / phone mount. If you’ve been wanting to try your hand at making video essays, but weren’t sure you were cut out for it, i hope that the example of me somehow managing to get something out while only having only draft video footage will convince you to give it a try. :)

I’ll try to apply all of those lessons to the next videos. I have a few ideas for what’s next, but nothing concrete yet. I hope this brief “postmortem” / look behind the scenes was interesting, ~~and remember to like, share, and subscribe!~~

Haskell type-level functions shenanigans

Antoine Leblanc — 2020-12-27

Last Wednesday, on Twitter, @TechnoEmpress posted a purposefully horrible solution to the following problem: given two types a and b, how does one test that type a is contained in type b? Can we write a function contains such that:

contains @Int         @(Either (Maybe [IO Int]) String) => True
contains @[IO Int]    @(Either (Maybe [IO Int]) String) => True
contains @(Maybe Int) @(Either (Maybe [IO Int]) String) => False

The answer is: of course we can; the real question is how. Looking into it, I found several possible implementations, that relied on parts of the language I wasn’t very familiar with. I thought it’d be interesting to go over them, and highlight why each extension is required, step by step. So… let’s go!

Runtime solution

The easiest approach relies on a base library: Data.Typeable, which provides functions that, to a given runtime value, associate a corresponding TypeRep value that represents the value’s type. Using typeRepArgs on that representation, one can obtain the list of the type arguments of a given type: from the representation of Either String Int, we can get [String, Int]. A first approach could therefore look like this:

contains :: (Typeable a, Typeable b) => a -> b -> Bool
contains a b = containsA typeB
  where
    typeA = typeOf a
    typeB = typeOf b
    containsA x = x == typeA || any containsA (typeRepArgs x)

There are several ways to improve on this: first, we can use typeRep instead of typeOf: its argument is a proxy type, such as Proxy from Data.Proxy: a type that does not contain any data and is only used as a way to convey type information. This allows us to call contains even if we do not have actual values of our types.

contains
  :: (Typeable a, Typeable b) => Proxy a -> Proxy b -> Bool
contains a b = containsA typeB
  where
    typeA = typeRep a
    typeB = typeRep b
    containsA x = x == typeA || any containsA (typeRepArgs x)

> contains (Proxy :: Proxy Int)  (Proxy :: Proxy (Maybe Int))
True
> contains (Proxy :: Proxy Char) (Proxy :: Proxy (Maybe Int))
False

> AllowAmbiguousTypes

But we can go one step further: what if our function had no runtime argument? After all, while we need a proxy to call typeRep, we can create it in the function itself, it doesn’t need to be passed as an argument. Ideally, we’d like to define our function as such:

contains :: (Typeable a, Typeable b) => Bool

However… This definition doesn’t compile: the compiler will not be able to identify what the types of a and b are from the arguments to the function, given that there’s no longer any argument! Calls to that function will therefore be ambiguous, and the compiler rejects it. The solution to this problem is provided by our first language extension: AllowAmbiguousTypes. It simply disables that check in the compiler. We can now implement our function:

contains :: (Typeable a, Typeable b) => Bool
contains = containsA typeB
  where
    typeA = typeRep (Proxy :: Proxy a)
    typeB = typeRep (Proxy :: Proxy b)
    containsA x = x == typeA || any containsA (typeRepArgs x)

> ScopedTypeVariables

But that still does not compile! The problem is that the bindings in our where block are independent from our function’s signature. So when we say Proxy a, it could be any a: it is understood to be generic, as it would be in a top-level function’s signature. What we would need is a way to tell the compiler that the a in the where block is the same as the one in the function’s signature, that they’re in the same scope. Introducing ScopedTypeVariables; thanks to it, type variables introduced with the forall syntax will, well, be scoped: the compiler will now know that the a in that Proxy a is indeed the same one as in the function’s signature.

contains :: forall a b. (Typeable a, Typeable b) => Bool
contains = containsA typeB
  where
    typeA = typeRep (Proxy :: Proxy a)
    typeB = typeRep (Proxy :: Proxy b)
    containsA x = x == typeA || any containsA (typeRepArgs x)

> TypeApplications

But now, how do we actually call that function? We have disabled the ambiguity check, but we need to resolve that ambiguity at the call site. And, of course, one more extension solves this problem: thanks to TypeApplications, we can use the @Type syntax to specify what a and b are.

> contains @Int         @(Either (Maybe [IO Int]) String)
True
> contains @[IO Int]    @(Either (Maybe [IO Int]) String)
True
> contains @(Maybe Int) @(Either (Maybe [IO Int]) String)p
False

You can find the code of this version in this gist.

But… we can do better. Type information is only relevant at compilation time, and is (mostly) elided at runtime. It should be possible to solve this entirely at compile time… With that, we could also extend our function to work on any type, not just the ones that define a Typeable instance.

Compile-time solution

If we are to write a solution at compile-time, we can’t write it as a function. Our input is going to be a type but… our output is also going to be a type. There’s no way to write a mapping from type to type in Haskell 98 (AFAIK); to do so, we’ll need our first language extension.

> TypeFamilies

TypeFamilies allows us to add type mappings to regular typeclasses. For instance, consider the class IsList (defined as part of another language extension): types that are not generic over their content can still be valid instances of IsList, and the typeclass therefore includes a type mapping, so that each instance can specify what the type of the contained items is:

class IsList l where
  type Item l
  fromList :: [Item l] -> l
  toList   :: l -> [Item l]

There’s several different ways to declare a type family; one that’s going to be useful for a us is a top-level closed type family, in which all instances are given together alongside the declaration. There’s additionally one very interesting property of those closed families, which solves the problem of overlapping instances:

The advantage of a closed family is that its equations are tried in order, similar to a term-level function definition.

But first: how are we going to represent our result?

> DataKinds

We could use some arbitrary new abstract types to represent truthiness:

data BTrue
data BFalse

type family Contains a b where
  Contains Int  (Maybe Int) = BTrue
  Contains Char (Maybe Int) = BFalse
  -- TODO: make this more generic

but there’s of course a better solution. But first, we need to talk about ~~parallel universes~~ kinds. Kinds are, in essence, the type of types. Int has kind Type; Maybe requires a type argument to yield a type, such as in Maybe Int, and has therefore kind Type -> Type. DataKinds is an extension that allows to “lift things one level up”. Types are allowed to be used at the kind level, which means that their constructors are allowed to be used at the type level. Which means that here, we can use good ol’ Bool type as a kind, and use True and False as “types”. Syntax-wise, we have to prefix a constructor with a single quote to use it at the type level.

With this, and with the fact that patterns are tried in order, we can write our first attempt:

type family Contains (a :: Type) (b :: Type) :: Bool where
  Contains a a = 'True
  Contains _ _ = 'False

> :kind! Contains Int Int
'True
> :kind! Contains Char Int
'False

What we have here is a very naive version of type equality: if the compiler can match the first line, it will associate the “type” 'True to the type application of contains, otherwise fall back to the second instance, which is defined for all possible types. The only thing left to do is for us to handle recursion: we’ll need to decompose more complex types and recurse over them:

type family Contains (a :: Type) (b :: Type) :: Bool where
  Contains a a     = 'True
  Contains a (f x) = Contains a x
  Contains _ _     = 'False

> :kind! Contains Int (Maybe Int)
'True
> :kind! Contains Int (Maybe (Maybe Int))
'True
> :kind! Contains Char (Maybe Int)
'False

Recursively: Contains Int (Maybe Int) = Contains Int Int = 'True. We don’t match the recursive case first to avoid decomposing our type when we have a match: Contains [IO Int] [IO Int] should return True without matching the recursive case.

But… we’re not out of the woods yet:

> :kind! Contains Int (Int, Char)
'False
> :kind! Contains Int (Either Int Char)
'False

The problem lies in our recursive match: f x. In the case of Either Int Char, x is Char, a type, and f is Either Int, a type function of kind Type -> Type. In our recursion, we only check x, but we would need to decompose f too…

A naive solution would be to manually decompose up to as many arguments as we deem reasonable, but that’s very verbose, not complete, and quite unsatisfying:

type family Contains (a :: Type) (b :: Type) :: Bool where
  Contains a (_ a _ _ _) = 'True
  Contains a (_ _ a _ _) = 'True
  Contains a (_ _ _ a _) = 'True
  Contains a (_ _ _ _ a) = 'True
  Contains a (_ a _ _)   = 'True
  Contains a (_ _ a _)   = 'True
  Contains a (_ _ _ a)   = 'True
  Contains a (_ a _)     = 'True
  Contains a (_ _ a)     = 'True
  Contains a (_ a)       = 'True
  Contains a a           = 'True
  Contains _ _           = 'False

A better solution would be, in the case of f x, to recurse on both parts: is a contained in f, or is a contained in x? This poses two problems; the first is: how can we recurse on f?

> PolyKinds

The problem we face is that we have explicitly declared the second argument of Contains to be of kind Type. To be able to recurse on f, we’d need a similar type family, in which the second argument would be of kind Type -> Type. And, in the recursion case of that second type family, we’d need to delegate the recursion to a third type family for types of kind Type -> Type -> Type… and so on.

What we need is instead to define our family so that it is generic over kinds. That’s what we can do with PolyKinds: we can now declare that the kind of our b parameter is generic: any kind k will do, which allows us to recurse on f too:

type family Contains (a :: Type) (b :: k) :: Bool where
  Contains a a     = 'True
  Contains a (f x) = Contains a f ??? Contains a x
  Contains _ _     = 'False

The only thing that’s left is to combine our two recursive calls: what we’ll need is a boolean “or” at the type-level! It’s thankfully pretty straightforward, now, with all our extensions:

type family Or (a :: Bool) (b :: Bool) :: Bool where
  Or 'True  _ = 'True
  Or 'False b = b

> UndecidableInstances

Putting it together:

type family Contains (a :: Type) (b :: k) :: Bool where
  Contains a a     = 'True
  Contains a (f x) = Or (Contains a f) (Contains a x)
  Contains _ _     = 'False

But as you might have guessed, this doesn’t compile. GHC really wants to guarantee that instance resolution terminates in finite time; for that reason, it forbids several patterns that it deems “dangerous”, such as nested type family applications, which is precisely what we’re trying to do here! A dangerous extension, UndecidableInstances, disables some of those checks at our own risk, and allows our solution to compile.

> TypeOperators

While our solution is now correct, we can make it better. One last thing we can do is use an existing implementation of type-level boolean or, rather than reimplementing our own: there is one already in Data.Type.Bool. You’ll notice however that it is defined as an operator! As you will have guessed, this is what is allowed by TypeOperators.

With that, we can finally settle on one final version:

type family Contains (a :: Type) (b :: k) :: Bool where
  Contains a a     = 'True
  Contains a (f x) = Contains a f || Contains a x
  Contains _ _     = 'False

Coming to terms with our solution

For convenience, and without any extension, we can define a simple typeclass to bring our type-level booleans back to term-level:

class ToBool (b :: Bool) where
  toBool :: Bool

instance ToBool 'True  where toBool = True
instance ToBool 'False where toBool = False

We can now finally test it:

> toBool @(Contains Int (Either Int String))
True
> toBool @(Contains Int (Either Int))
True

And… that’s it! You can find this version of the code in this other gist. This was a silly but fun exercise, I learned a ton, hopefully this will be useful to you too!

Happy new year, and all that sort of things. :)

Parser Combinators: a Walkthrough

Antoine Leblanc — 2020-12-04

Talk: Site Reliability Engineering

Antoine Leblanc — 2017-11-17

C++ open double dispatch

Antoine Leblanc — 2015-05-13

I’m currently trying to validate a method I’ve found that allows a C++ library writer to do double dispatch via a visitor that also supports user-defined types (hence the “open”). I have yet to make sure that it is correct with respect to the standard and to compiler implementations… The goal of the post is to explain why I’m doing that, to present my proposal, and to plead for help from people more knowledgeable than me. :)

Let’s go back to the very beginning: what’s dynamic dispatch?

Dynamic dispatch

Dynamic dispatch is the process that, at run time, dispatches a method call to the correct implementation, based on the type of its arguments. In C++, it is used for virtual methods, and is therefore restricted to single dispatch: the object on which the method is called is the only one considered by the dispatcher. It is usually implemented via a vtable, though as far as I know this is implementation defined.

In the following example, the call b->onClick(l) is dispatched to Button’s implementation of the onClick method based only on b’s type. There is no way via virtual methods to have this call dispatched to different methods based on the runtime type of l.

class Element {
  public:
    virtual void onClick(Element* sender) = 0;
};

class Button : public Element {
  public:
    virtual void onClick(Element*) {
      std::cout << "You clicked on a button!" << std::endl;
    }
};

class Label : public Element {
  public:
    virtual void onClick(Element*) {
      std::cout << "You clicked on a label?" << std::endl;
    }
};

void main() {
  Element* b = new Button();
  Element* l = new Label();
  b->onClick(l);
}

Of course, the whole issue stems from the fact that C++ only has single dispatch. With multiple dispatch, with multi-methods for instance, we wouldn’t have this problem. However, multi-methods have yet to go beyond their status as proposal.

So, with this restriction, how can we do double dispatch in C++?

Visitor pattern

GOF’s Visitor pattern is the usual answer to this question. Although a verbose solution, it remains a simple enough one: one simply has to define a Visitor interface that has a pure virtual method for each of the types on which the first dispatch is performed. One then only has to implement a class that derives from Visitor to achieve double dispatch.

class Visitor {
  public:
    virtual void apply(Button*) = 0;
    virtual void apply(Label*)  = 0;
};

class Button : public Element {
  public:
    virtual void apply(Visitor* v) {
      v->apply(this);
    }
};

class Label : public Element {
  public:
    virtual void apply(Visitor* v) {
      v->apply(this);
    }
};

class IdentificationVisitor : public Visitor {
  public:
    virtual void apply(Button*) { std::cout << "Button!" << std::endl; }
    virtual void apply(Label*)  { std::cout << "Label!"  << std::endl; }
}

It’s verbose, since any function that needs multiple dispatch has to be written as a class that inherits from Visitor, but it does the job, with the added benefit of providing a clean way of leveraging the dispatch mechanism to add new behavior to existing class without breaking the single responsibility principle. Good stuff.

But this approach suffers from one severe drawback: the list of classes has to be fully known in order to declare Visitor. If those classes and the visitor are exposed in a library, the library user can’t create her own classes inheriting from Element and use a Visitor on them…

A macro proposal

In the specific case previously mentioned, in which a library exposes a class hierarchy that might be extended by the user, an other approach would be to extend the Visitor declaration with user-defined types via macros. This would mean that the library itself wouldn’t be able to declare visitors internally, since it wouldn’t, at the library compile time, have the full list of classes.

A small example of such an approach would look like that.

// in library

class Visitor
{
  public:
#ifdef USER_TYPES
    BOOST_PP_MAGIC_MACROS(USER_TYPES)
    // expands to an "apply" declaration for each type in USER_TYPES
#endif
    virtual void apply(const Button&) const = 0;
    virtual void apply(const Label&)  const = 0;
};

class Button : public Element {
  public:
    virtual void apply(Visitor* v) {
      v->apply(*this);
    }
};

class Label : public Element {
  public:
    virtual void apply(Visitor* v) {
      v->apply(*this);
    }
};


// in client

class TextBox;

#define USER_TYPES (TextBox)
#include <library>

class TextBox : public Element {
  public:
    virtual void apply(Visitor* v) {
      v->apply(*this);
    }
};

Seems good! The Visitor interface contains a method declaration for all classes, including the user-defined ones, which means we’ve reached our goal of open double dispatch, right? Well… not quite yet: a huge problem remains.

（╯°□°）╯︵ǝןqɐʇʌ

The problem lies in the fact that the library and the client see different (and conflicting) versions of Visitor, which means the vtables differ… And both g++ and clang merge the conflicting vtables without a single warning. The horrifying result? Silent incorrect dispatch at runtime! Without realising it, I’ve managed to reach the dreaded “undefined compiler behavior” zone, which is both something I didn’t know existed and a term I just made up to describe it.

Compiling with g++ -fdump-class-hierarchy allows us to inspect the vtables layout. The following table displays how the vtable for Visitor is generated in each translation unit.

offset	library.o	client.o
0	0	0
8	destructor	destructor
16	apply(Button)	apply(TextBox)
24	apply(Label)	apply(Button)
32		apply(Label)

What happens at link time? Both g++ and clang silently choose the biggest one, defined in the client. However, this means that all call to methods of Visitor in the library are now rerouted according to this new vtable; in other words, Button::apply(Visitor*) ends up calling Visitor::apply(const TextBox&) instead of Visitor::apply(const Button&) at runtime! As one can imagine, this is bound to fail in very, very interesting ways…

A quick and dirty solution would be to reorder the declaration of Visitor in order to ensure that user-defined methods are declared after the library ones, preserving the declaration order in the client vtable. It does work… It is however highly unreliable. A better solution would be to prevent the vtable from being generated in the library altogether…

How to kill a vtable

The best way to prevent the Visitor vtable from being generated… is simply not to declare Visitor at all! A predeclaration is enough to declare the apply methods in the headers. The only place where its predeclaration is not enough is where, of course, its content is used: in the implementation of those apply method. If we manage to have both the Visitor declaration and the apply implementations in the client rather than in the library, we’ve won.

The simplest way I’ve found so far is to have both of them in a separate header, never included in the library itself, and included once in a compilation unit of the client (not in a header). What the library only ever sees is a predeclaration of Visitor: no vtable is generated. The only downside is therefore this need for a specific file to be included in one and only one C++ file: this puts some burden on the library user, even if she does not plan on declaring her own classes.

The only good vtable is a dead (or missing) vtable.

Pining for reviews

Aaaand… it seems to work! From what I can gather, there’s no way for erroneous code or conflicting vtables to be generated for a type that is only predeclared. But before celebrating too soon: I’d like reviews, please, to make sure this is indeed correct! A small working example can be found in this gist. All feedback will be appreciated. Thanks! :)

Haskell typeclasses in C++

Antoine Leblanc — 2015-04-26

Haskell’s typeclasses are somewhat akin to what object oriented languages call interfaces or abstract classes: they define a “contract”, sometimes offer a default implementation, and even share some common vocabulary: a type that is an instance of a typeclass is said to be “deriving” it.

However, amongst the many differences, one stands out: while one can implement a typeclass for an existing type without modifying it, a class in most object oriented languages has to explicitly declare which interfaces it implements. A language that is a notable exception to this rule is Go. But in C++, which doesn’t have interfaces but only abstract classes, such a feat is impossible.

While developing my MCL library, I chose to represent color transformations as endomorphisms. It led me to implement an equivalent of Haskell’s mconcat function, to compress a list of transformations into one. Wanting that code to remain generic, I had to find a way, in C++, to describe monoids, and therefore typeclasses, which is the reason why I started, as usual, a side project.

The code that emerged from this little experiment is on Github, this post is about the journey. In case you doubted it: this is not something you’re really advised to do. Don’t try this at home. Except for fun. Fun is good.

Partial specialization

Let’s start with Monoid, which was my starting point. What’s a monoid anyway? Well, briefly, it’s a set (in the mathematical sense) equipped with an associative binary function and its neutral element. As far as Haskell is concerned, it’s expressed this way:

class Monoid a where
    mempty :: a
    mappend :: a -> a -> a

How should we translate that in C++? The naive first approach is to simply use (template) functions that we redefine for each type that we want to make an instance of our typeclass. We have two strategies from which we can choose when redefining functions: specialization and overloading. If we choose to specialize our functions, we have to create an alternate definition of our function with explicit type parameters; the compiler will know that both are only one function, with different implementations. Overloading, in contrast, consists in creating a brand new function with the same name but a different signature.

template <typename A>
using Endomorphism = std::function<A(A)>;

template <typename A>
A mempty();

template <typename A>
A mappend(A const&, A const&);

template <typename A>
Endomorphism<A> mempty<Endomorphism<A>>()
{
  return id<A>;
}

template <typename A>
Endomorphism<A> mappend<Endomorphism<A>>(Endomorphism<A> f,
                                         Endomorphism<A> g)
{
  return compose(f, g);
}

But alas, none of this can work. Partial specialization of functions isn’t allowed by the language, and overloading is not worth trying, at it will obviously only result in insolvable ambiguous function calls…

Which means we have no choice but to move to traits!

Traits

Traits are a useful tool while dealing with generic C++ template code. They’re metaprogramming functions over types: they’re template structs that map their parameter types to stuff: other types, functions, constants… And since they’re implemented with structs, they can be partially specialized, which is exactly what we need here. So, if we move everything in a Monoid class and partially specialize it…

template <typename A>
class Monoid
{
  public:
    static A empty();
    static A append(A, A);
};

template <typename A>
class Monoid<Endomorphism<A>>
{
  public:
    static Endomorphism<A> empty()
    {
      return id;
    }

    static Endomorphism<A> append(Endomorphism<A> f, Endomorphism<A> g)
    {
      return compose(f, g);
    }
};

This works wonders! For convenience, we only have to define two helper functions outside of the Monoid class, and voilà. Those two can be easily inlined and only provide syntaxic sugar.

template <typename A>
A empty()
{
  return Monoid<A>::empty();
}

template <typename A>
A append(A x, A y)
{
  return Monoid<A>::append(x, y);
}

But this solution isn’t a silver bullet… When trying to apply the same strategy to Functor, we encounter a new problem. -

Too much kindness

The issue is that, in Haskell, Functor isn’t defined over what we would call a concrete type (of kind *), but on a parameterized type (of kind * -> *). Trying to mimick this in C++ yields a new bunch of issues.

template <typename A>
using Vec = std::vector<A>;

template <template<typename> class F>
class Functor
{
  public:
    template <typename A, typename B>
    static F<B> fmap(std::function<B(A)>, F<A>);
};

template <>
class Functor<Vec>
{
  public:
    template <typename A, typename B>
    static Vec<B> fmap(std::function<B(A)>, Vec<A>)
    {
      // left as an uninteresting exercise to the reader. :)
    }
};

template <template<typename> class F, typename A, typename B>
F<B> fmap(std::function<B(A)> f, F<A> fa)
{
  return Functor<F>::template fmap<A, B>(f, fa);
}

The first issue is that almost all STL containers have more than one template parameter: vector for instances has two, which means we can’t specialize Functor with it, as Functor expects types with only one template parameter. This seems to be avoidable thanks to C++11 template type synonyms, such as the introduced Vec. However, the compiler has a hard time resolving our types with such shenanigans, because alias templates are never used in template template argument detection, which means that we have to call fmap with a fully explicit F parameter, as in fmap<Vec>(f, v).

This might seem acceptable, albeit ugly, until we move to Monad. Because, for Monad, we will want to override the >> and >>= operators. And we can’t really specify explicit parameters on operators… This means we have to choose between painfully writing verbose wrappers for all classes that don’t have the appropriate “kindness” (standard containers, Either…) or going back to the drawing board and find a new way to declare Functor and Monad…

Going full template

How can we make sure the compiler will resolve our types correctly while still making it easy to implement said typeclasses? Our only remaining option: using concrete types in template specialization. Monad should not be specialized over Vec but over Vec<A>. However, this requires a bit more information in the typeclass itself.

template <typename MA>
class Monad;

template <typename A>
class Monad<Vec<A>>
{
  public:
    typedef A Type;

    static Vec<A> mreturn(A a);

    template <typename B>
    static Vec<B> bind(Vec<A> as, std::function<Vec<B>(A)> f);
};

template <typename MA, // deduced from ma
          typename MB, // deduced from f
          typename A>  // deduced from f
MB operator >>= (MA ma, std::function<MB(A)> f)
{
  return Monad<MA>::bind(ma, f);
}

template <typename MA, // deduced from ma
          typename MB> // deduced from mb
MB operator >> (MA ma, MB mb)
{
  typedef typename Monad<MA>::Type A;
  std::function<MB(A)> f = [=](A){ return mb; };
  return ma >>= f;
}

The only downside, regarding the >>= operator, is that, since we’re deducing the types of MB and A from the type of f, we can’t use lambdas or function pointers with bind: we’re restricted to real instances of std::function. But at last, monads work as expected! The following snippet correctly outputs [0,1,2,3,4,5,6,7,8] (given a proper implementation of show).

int main()
{
  Vec<int> v = Vec<int> { 1, 4, 7 };
  std::function<Vec<int>(int)> f =
    [](int x){ return Vec<int> { x-1, x, x+1 }; };

  std::cout << show(v >>= f) << std::endl;
}

Wrapping up

You might have noticed that we didn’t give any common pattern for Monad. That’s because we can’t: there’s no generic way to extract either M or A from the given MA. But this isn’t a bad thing: this is the pattern that yields the best error messages. Trying, for instance, to call fmap on a random type A gives the following error in clang: implicit instantiation of undefined template 'Functor<A<int> >'.

And… this is it! A way to build haskell-like typeclasses in C++. You can find all the code of this article plus some extra on Github. Although some of those typeclasses might be useful in some very specific cases (Monoid comes to mind), the cataclysmic performance penalty of Functor or Monad over lists or vectors compared to handwritten code using standard C++ algorithms isn’t worth the lines it saves. It remains, however, a fun way to explore the internals and limits of C++’s type system.

What comes next, implementing the Cont monad for instance, is left as an exercise to the motivated reader. :)

Going further

While proofreading this article, I discovered the Functional C++ blog; they have a very similar way of implementing the Monoid typeclass. But they also do fun stuff with the STL containers. Worth the read!

Colorful design

Antoine Leblanc — 2015-03-04

A few weeks ago, I proudly released the 1.0.0-alpha version of MCL ~~and updated the Projects page of this site accordingly~~, disregarding my resolution to release existing projects rather than work on new ones. In all fairness, this project isn’t of utmost importance and I’ll probably remain its only user, but to quote what I said back when I released SAW:

It’s not much, mainly because no one is using it besides me, which means I have no issues to deal with, no weird bugs that I can’t seem to reproduce… But it doesn’t mean that releasing it publicly is devoid of meaning.

So, let’s talk about colors, design, C++ and build systems! This post focuses on some technical aspects of the MCL, in no particular order. A (likely) next article will focus on color interpolation fun facts.

Once upon a time…

…there was an interesting article on Hacker News. It talked about procedural color generation, and color interpolation using the CIE LCHab color space. As it happens, I had already written a rudimentary RGB and HSV hybrid color class that I used for such a purpose, but it had several shortcomings, the main one being caching all fields of the two color spaces (R, G, B, H, S, V). As a result:

this Color class was rather heavy,
it was hard to extend with other color spaces,
it wasn’t efficient (frequent recomputation).

I was therefore usually using several color classes at the same time: this one for interpolation, translated into another one that I used with OpenGL code… It was far from being convenient. Inspired by that article, I launched head first into a better color class implementation, starting what would become the MCL.

Requirements

From the start, I had a few goals that I wanted to achieve. While some of the funny features emerged later, while coding, those were intended from day 1.

A lightweight RGB class

I wanted to have a RGB struct that I could cast to a float*, a double*, or a unsigned char*, depending on the chosen data type. This would allow me to have RGB arrays that I could give directly to OpenGL, amongst other possibilities.

Support for LCHab color space

In addition to the color spaces I already knew (namely RGB, HSV and HSL), I wanted this future library to be able to also handle LCHab values, which were at the heart of the aforementioned article.

Linear colormaps

There already was a colormap implementation along with the old color class. It would need to be adapted to the new color classes, as this was the main feature I wanted to achieve.

C++11

Although this isn’t exactly a requirement, I used the excuse of C++11 to convince myself it would be a good idea to start a brand new project: I hadn’t yet written anything using C++11’s new features.

Algebraic types over inheritance

Due to requirement #1, I could not have different classes for each color space (RGB, HSV…) all inheriting from a common Color base class abstraction. The reason being, of course, the vtable. No inheritance means no vtable, meaning in turn that the size of the class should be the sum of the size of its elements, providing they’re correctly aligned. As the compiler isn’t allowed by the standard to modify the members order, the resulting class should meet the requirement.

It is worth noting, however, that relying on the fact that compilers won’t pad those classes with any kind of metadata is a bit ugly, as there is no rule in the standard that enforces such a layout (those classes being non-POD). Although it behaves correctly on all tested systems and all tested compilers, using that knowledge to do ugly casts (for OpenGL purposes for instance) is a direct step into the uncharted unholy territory of undefined behaviour. Fun stuff. :)

The best solution to have a generic Color class is to use functional programming tools: in this case, algebraic data types. As there is no native support for such types in C++ (unions do not count), I unleashed the almighty boost::variant, which allows the creation of pseudo “typed unions”.

typedef boost::variant<
    CMY, CMYK, HSL, HSV, LAB, LCH, RGB, RGBf, RGBub, XYZ
> ColorData;

Compared to a type hierarchy, such a type is at the opposite end of the Expression Problem: while it makes it tedious to add new color spaces, new types (something that is, in this case, unlikely, or at least uncommon), adding new generic functions over color spaces is easy, and can be done without modifying the existing classes. But more importantly, this type allows for easy, polymorphic, pointer-free use of different color spaces instances on the stack.

Reference graph

A naive way of implementing color space conversion would be to have all N * N conversion functions, which would be a hassle to implement. Instead, the MCL splits the different color spaces in three groups.

Print group: CMYK, CMY.
Display group: RGB, HSL, HSV.
Absolute group: XYZ, LAB, LCH.

Each group has a “reference” type (highlighted above), which each type knows via a typedef. Converting from a color space A to a color space B is therefore done by moving along the resulting graph (see below). This severely limits the total number of functions needed. Furthermore, adding a new color space would only mean implementing conversion from and to its reference type.

Edges are hard-coded transformations.

Those groups were not chosen randomly. They exhibit a nice behavior: color conversion inside a group does not depend on external parameters such as a referent white (except for one very specific exception: XYZ <-> LAB). Conversions from one group to one of the others do however require such parameters. They’re all bundled in a class called Environment.

All MCL functions that might need at some point to convert from one color space to another have a Environment parameter. For convenience, however, they all have a Environment-free variant that passes in Environment::DEFAULT, which specifies that all device independent color spaces have to considered as being sRGB with a D65 standard illuminant. Users that want to specify another behavior can inject their Environment instances in all calls, or choose the sinful path of overriding Environment::DEFAULT, which is mutable.

This also means users are free to plug any advanced function of their choice in the MCL, such as LittleCMS ICC profiles transform functions, to convert from RGB to CMYK for instance.

Monoidal composition

Most transformation functions can be expressed as endomorphisms: their type is Color -> Color. As such, they form a monoid, providing that we implement the equivalents of mempty and mappend, in this case id and compose.

While in Haskell this is really straightforward,

instance Monoid (Endomorphism a) where
    mempty = id
    mappend = (.)

in C++, it’s a tiny bit more verbose…

// helper functions

template <typename T>
inline Endomorphism<T>
compose(const Endomorphism<T>& f,
        const Endomorphism<T>& g)
{
  using namespace std::placeholders;
  return std::bind(f, std::bind(g, _1));
}

template <typename T>
inline T
id(T const& x)
{
  return x;
}


// monoid instance

template <typename T>
inline Endomorphism<T>
Monoid<Endomorphism<T>>::empty()
{
  return id<T>;
}

template <typename T>
inline Endomorphism<T>
Monoid<Endomorphism<T>>::append(const Endomorphism<T>& f,
                                const Endomorphism<T>& g)
{
  return compose(f, g);
}

This allows for fun stuff, such as combining transformations, or even transformations folding: a list of color transformations can be reduced to a single one. This is also true for any user defined function over Color instances, as long as it can be implicitly made into an Endomorphism, which is defined as std::function<T (T const&)>.

Although this was not part of the requirements, this was aesthetically rather pleasing. It was also the opportunity to find a way to implement Haskell-like typeclasses in C++, for which I found a traits-based solution that I find funny if not particularly useful. I’ll speak more about it in an upcoming article.

Wrap up

Although I’m quite proud of how everything turned out, this library has several shortcomings.

The build system is my own ugly one, hand-written in 2008…
The only clamping functions provided for out of gamut colors is really naive.
I have made no thorough performance study of the code performance (though I suspect it’ll work better with a high inlining limit).
It severely lacks feedback from real users!

If you want to see more details about some technical aspects of the MCL, the wiki of the project details each major feature of the library.

To summarize: this was a lot of fun. :)

Doxygen and BOOST_PP

Antoine Leblanc — 2015-02-08

There are many topics I’d like to broach here… In order to start the writing process anew, a first, small, easy post.

Context

You might have noticed: I really enjoy messing with the infamous C preprocessor. Besides, I also took the habit of using Doxygen to automatically generate some documentation for my C++ project, as it offers a few interesting features in my opinion.

Unlike a separate hand-written API documentation, a documentation generated from the source code itself does not suffer the risk of being out of sync.
When there’s no other documentation available, a Doxygen generated documentation provides a good-enough source indexation and layout, which makes browsing for info a bit easier than just waltzing through source files.
Having a usable documentation can be just a matter of adding simple comments to the source code.

Overall, it is a very good solution for the lazy sloth I am, considering the limited scale of my projects. And furthermore, it can generate inclusion or inheritance graphs, and THAT is cool.

Issue

But in order to generate the documentation, Doxygen has to parse the source code. And due to BOOST_PP and to some similar macros usage, my code is sometimes somewhat… obfuscated. Usually, this means that the generated documentation is incomplete, or even sometimes plainly wrong. Here are two examples of the absurd or unreadable output it can yield…

Solution

The solution came from Doxygen’s filtering options. They allow one to specify how to preprocess a file before it is parsed. And with this, rather than letting Doxygen try to expand macros, we can use the tool that’s made for it: the compiler. The only tricky thing was to preserve comments and include directives, in order for Doxygen to do its job properly; but it was nothing a few sed calls couldn’t solve.

Ultimately, the resulting script is surprisingly small. Here it is in its entirety (you can also download it from here).

#! /usr/bin/env bash

FILE="$1"
CCOPTS="-C -x c++ -std=c++11 -I include -I src"
G1="__________B $(date +%s) B__________"
G2="__________E $(date +%s) E__________"

function surround()
{
    egrep    "^# *include" "$FILE" | grep -v '\.hxx.$'
    echo "$G1"
    egrep -v "^# *include" "$FILE"
    echo "$G2"
}

egrep "^# *include" "$FILE" | grep -v '\.hxx.$'
surround                       \
    | cpp $CCOPTS -            \
    | sed -n -e "/$G1/,/$G2/p" \
    | sed "/$G1\|$G2\|^#/d"

So, well, there it is. It isn’t much. But if, one day, you have to use Doxygen on some C++ source code which is full of macros… well, then, that day, you’ll be ready. :)