If we want to combine two side effects into one, we can use the *> operator, which is pronounced then or sequence right. It takes two side effect objects and creates a new side effect object that executes both when itself is executed. The value produced by this new composite object is going to be the value produced by the second object its constructed from. In that sense, the *> operator is a lot like the comma operator in C: it chains together statements, and returns the result of the last.

(*>) :: IO a -> IO b -> IO b

For example, here we combine two print statements into a single side effectful function.

greeting :: IO ()
greeting =
  putStr "hello, " *> putStrLn "world"

This is a single side effect object called greeting, but its execution will involve the execution of two separate print statements.

We teach beginners to write this as

greeting = do
  putStr "hello, "
  putStrLn "world"

which is the exact same thing, although arguably easier to read. The interesting thing is the implication for how we look at do blocks. It turns out they may not be magical at all; maybe they are just inserting implicit commas, i.e. a pretty way of taking multiple side effect objects and combining them into a single, bigger, side effect object.

The one thing we cannot do with *> is take the result from the left-hand side effect and use it to influence the right-hand side function call, because the *> operator discards the first result before executing the second effect – just like the comma operator in C. The die throwing code we saw previously,

dice_print = do
  side <- randomRIO(1, 6)
  printf "It landed on %d\n" side

cannot be implemented with just *>. We need the additional operator >>= which takes a side effect object and plugs the value it produces into another side effectful function.6⁶ This operator is widely known as bind.

(>>=) :: IO a -> (a -> IO b) -> IO b

Using this operator, we could write the above do block as

print_side :: Int -> IO ()
print_side side =
  printf "It landed on %d\n" side

dice_print :: IO ()
dice_print =
  randomRIO(1, 6) >>= print_side

and this would take the result of executing the side effect of randomRIO and plugging it into another side effectful function, namely print_side.

This illustrates that do blocks are built from only two operators. If we stick with do blocks for all side effects, we will never learn why Haskell is the greatest procedural programming language in the world, because we are limiting ourselves to just two operators for dealing with side effects.

Let’s lift our gaze and see what happens when we look beyond those. There are more functions for dealing with side effects.

If we want to construct a new side effect object that always produces a specific value, we can use the function pure.

pure :: a -> IO a

For example, this creates a side effect object that always produces the integer 4.

loaded_die :: IO Int
loaded_die =
  -- Chosen by fair dice roll.
  -- Guaranteed to be random.
  pure 4

Creating side effect objects that always produce a known value might not seem very useful, but it comes up all the time when bridging the worlds of pure code and side effects.

One of the most used functions when working with side effects in Haskell is fmap.

fmap :: (a -> b) -> IO a -> IO b

This takes a pure function, and a side effect object, and returns a new side effect object that is similar to the one it got, except the value produced will be transformed by the function first. Transforming the results of side effects is so common that fmap has an operator alias: <$>. For example, to get the length of the path to the user’s home directory, we can do

path_length :: IO Int
path_length = length <$> getEnv "HOME"
-- equivalent to
-- path_length = fmap length (getEnv "HOME")

This creates a new side effect object which will produce the result of applying the length function to the result of the side effect of getEnv.

Where fmap allows us to transform the value produced by a single side effect, sometimes we need to create a side effect object that produces something based on multiple other side effects. This is where liftA2 and friends come in.

liftA2 :: (a -> b -> c)      -> IO a -> IO b -> IO c
liftA3 :: (a -> b -> c -> d) -> IO a -> IO b -> IO c -> IO d

These can be thought of like fmap, except they don’t transform the result of just one side effect, but they combine the results of multiple side effects with one function, and create a new side effect object that produces the return value of that function. This is also common enough that it can be written with two operators: the <$> we already saw for the first argument, and then <*> for the rest of the arguments. To check if a user’s home directory contains the user name, we do

home_username :: IO Bool
home_username = isInfixOf <$> getEnv "LOGNAME" <*> getEnv "HOME"
-- equivalent to
-- home_username = liftA2 isInfixOf (getEnv "LOGNAME") (getEnv "HOME")

This has created a new side effect object that will produce true if $LOGNAME is a part of $HOME, and false otherwise.

I am raving ecstatic about this. Combining the results of side effects through liftA2 and friends is such a fundamental technique that the favicon of this website is a stylised version of the <*> operator.

But the reader may understandably be a little underwhelmed. It seems like we have only learned to do in Haskell what we can do in Python and every other programming language already. All popular programming languages let us use the results of side effects as arguments to other functions. There are already two reasons we should care about Haskell, though, even before we see what’s to come. These are refactorability and discipline.

Biggest benefit is probably refactorability. We might have the following code that throws two dice and sums them up:

sum_dice :: IO Int
sum_dice =
  liftA2 (+) (randomRIO(1,6)) (randomRIO(1,6))

and we think the repetition is annoying, so we put the actual die-tossing code into a variable.

sum_dice :: IO Int
sum_dice =
  let
    toss_die = randomRIO(1,6)
  in
    liftA2 (+) toss_die toss_die

If we did this in Python, we would accidentally store the result of the die toss in the toss_dice variable! If the die lands on 3, we will compute 3+3, rather than the intention of summing two different tosses. With the way side effects are first class values in Haskell, we are always free to blindly (!) extract code into a variable name, and this will never change how the code runs.7⁷ This is called equational reasoning and it’s incredibly powerful and one of the things that make Haskell such a strong enterprise language, and so nice to work with procedural code in.

A second benefit is that by being structured in how we allow side effects to affect subsequent computation, we have a lower risk of accidentally introducing side effects where they were not intended. We also have greater control over what can affect what, reducing the risk of interaction bugs.

The reader might, for example, argue that the previous refactoring example works just fine in Python, by using an anonymous function as a faux side effect object:

def sum_dice():
    toss_die = lambda: random.randint(1, 7)
    return toss_die() + toss_die()

but this (a) requires being careful in refactoring, (b) does not prevent accidentally triggering the side effect where it was not intended, and (c) requires a language feature (sequence points) to disambiguate in which order side effects get executed. With Haskell, we just don’t have to care. We can rest easy in knowing that the compiler and libraries have our backs.

We are starting to see the benefits of side effects as first class values, so let’s shift to a higher gear. We have seen that Haskell allows us to store side effect objects in variables without accidentally executing their effects. The next step is storing these side effect objects in data structures.

We could, for example, create a list of three different ways to get the username of the currently logged in user.

getting_usernames :: [IO (Maybe String)]
getting_usernames = [lookupEnv "USER", lookupEnv "LOGNAME", lookupEnv "SUDO_USER"]

This list cannot be executed for its side effects directly, because the list itself is not a side effect – it’s a list of side effects. There are library functions to deal with this, though. One is

sequenceA :: [IO a] -> IO [a]

This is what we need in this case: it takes a list of side effect objects and creates a new side effect object that executes all the side effects of the list, and then produces a list of all the values produced by those side effects. To make a side effect that produces a list of candidate usernames, we define

actual_usernames :: IO [Maybe String]
actual_usernames = sequenceA getting_usernames

If we execute this side effect and print the result (either by connecting it up with print using the >>= operator, or in a do block), then on my system we get the result

[Just "kqr", Just "kqr", Nothing]

Sometimes we have a list of side effects but we don’t care about the value they produce. This might be the case if we have collected a bunch of log statements from a pure function. We want to execute their side effects (the actual logging action) but we don’t care about what the log function itself returns (it is usually a void or unit-type value.)

log_statements :: [IO ()]
log_statements = [
    log Info "Creating user",
    log Warn "User already found"
    log Info "Updating user"
]

As a reminder: these function calls to the log function do not cause anything to be logged. The log function returns a side effect object that, when executed, makes the logging happen. The log_statements variable contains a list of such side effect objects – it is not itself a side effect object.

To execute these, we can again combine the side effects in the list into one side effect object with sequenceA. When we do so, we get a side effect object that produces the value [(), (), ()]. To get the code to type check, we may have to discard this value. We already know how to do this, because discarding values is what the *> operator does.

execute_logged :: IO ()
execute_logged =
  sequenceA log_statements *> pure ()

When the side effect of execute_logged runs, it will run the side effects of the log statements and then discard the dummy values produced in the process.

Remember that loaded die from before? Now we can check that it indeed always returns the same number. First we create a list by repeating the same side effect object an infinite number of times.

many_loaded_dice :: [IO Int]
many_loaded_dice =
  repeat loaded_die

Then we construct a side effect object that executes the first few of these and keeps the values they produced.

some_thrown_dice :: IO [Int]
some_thrown_dice =
  sequenceA (take 20 many_loaded_dice)

If we connect this up with a print (again, do block or the >>= operator) and execute it, we get

[4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4]

We could do the same thing with a better die:

many_good_dice :: [IO Int]
many_good_dice =
  repeat (randomRIO (1,6))

some_thrown_dice :: IO [Int]
some_thrown_dice =
  sequenceA (take 20 many_good_dice)

If we print this once, we get

[2,1,4,1,3,2,2,2,1,4,6,4,1,4,6,4,5,3,4,6]

If we print it again, we might get

[4,5,3,2,4,2,5,4,6,1,1,5,1,3,6,4,4,5,1,4]

Even though we constructed the list by repeating the same side effect object, we get a fresh set of random numbers every time the composite side effect object is executed. This is additional proof that what we store in the list is not the result of the side effect, but the side effect itself.

But also note what we did. We used list functions (repeat, take 20) to manipulate a data structure of side effect objects as if they were regular values – because they are! Then we used a side effect manipulation function (sequenceA) to combine the side effects in the list into one new side effect object that executes all of them. This is a kind of meta programming, except it’s not using a special macro language but performed at the level of regular values.

The Haskell standard libraries also contain a few convenience functions to do what we have done above except easier. For example, when we discarded the value produced by a side effect, we used object *> pure (). This exists as a shortcut function called void:

void :: IO a -> IO ()

We could wrap the call in this instead:

execute_logged :: IO ()
execute_logged =
  void (sequenceA log_statements)

But there is an even more convenient way to do it. Many of the functions I will show have a variant that ends with underscore. These variants throw away the result. So we could instead have written

execute_logged :: IO ()
execute_logged =
  sequenceA_ log_statements

and this would run the effects and throw away the results. One benefit of using this variant is that it actually works with slightly more collection types than the one without underscore but the drawback is, of course, that we don’t get the results produced, only the side effects.8⁸ See the appendix for more details.

Separately, we used list manipulation functions repeat and take 20 to create an appropriately-sized list of side effect objects, and then executed it with sequenceA. This specific combination is common enough to exist as a library function

replicateM :: Int -> IO a -> IO [a]

With this, we can draw 20 loaded dice quite succinctly.

some_thrown_dice :: IO [Int]
some_thrown_dice =
  replicateM 20 loaded_die

This also exist as a result-discarding variant that runs a side effect object \(n\) times but does not collect the values produced by the side effect.

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

Back when I was in university I had a coursemate who had just learned programming and found the following joke very funny:

Teacher: Write “I will not cheat again” 500 times on the blackboard. That should get you to learn your lesson.

Student: for (int counter = 0; counter < 500; counter++) { System.out.println("I will not cheat again."); }

I didn’t find it funny – I found it sad. Is this really the type of low-level programming we are teaching students? Here’s how it should go.

Teacher: Write “I will not cheat again” 500 times on the blackboard. That should get you to learn your lesson.

Student: replicateM_ 500 (putStrLn "I will not cheat again.")

As a programmer, I do not want to babysit my computer and instruct it in exactly how to count to perform a side effect 500 times. I just want to tell it to perform the side effect 500 times and the standard libraries should know what the detailed steps are.

Anyway, let’s get back to the good stuff. Now we’re going into advanced techniques.

In a previous example, we had code that amounted to

usernames :: IO [Maybe String]
usernames =
  sequenceA [lookupEnv "USER", lookupEnv "LOGNAME", lookupEnv "SUDO_USER"]

This contains some duplication, namely the application of lookupEnv to each of the strings. We could write this instead as

usernames :: IO [Maybe String]
usernames =
  sequenceA (fmap lookupEnv ["USER", "LOGNAME", "SUDO_USER"])

relying on the fact that fmap works on lists as well9⁹ For a brief explanation of this, see the appendix., but there is a more efficient way to express this, though, and it’s using the function

traverse :: (a -> IO b) -> [a] -> IO [b]

which constructs a side effect object that produces the result of applying a side effectful function to each element in a collection. The above side effect object could then be constructed as

usernames :: IO [Maybe String]
usernames =
  traverse lookupEnv ["USER", "LOGNAME", "SUDO_USER"]

This is a fairly fundamental operation, and we can define e.g. sequenceA in terms of traverse:

sequenceA :: [IO a] -> IO [a]
sequenceA = traverse identity

where identity is the identity function that returns its argument unchanged.

As with sequenceA, there exists an underscored version of traverse that throws away the values produced by the side effect, for cases where we are only interested in the side effect itself.

traverse_ :: (a -> IO b) -> [a] -> IO ()

We can use this e.g. to create a side effect object that emits several log messages when it executes.

mass_log :: IO ()
mass_log =
  traverse_ (log Info) [
    "System startup in experimental mode."
    "This means it will attempt to divine in which order to run startup scripts."
    "The startup procedure may crash if things are performed in the wrong order."
    "Please see the manual for more details."
  ]

We have learned that when we have a collection of things, and we want to perform some side effectful work for each of those things, we use traverse. However, when we call traverse we have to give the function first, and the collection second. Sometimes it’s convenient to be able to pass the arguments the other way around, and for this, we have an alias called for that is exactly like traverse except with its arguments swapped around. In other words, this takes a collection as its first argument, and the scare-quotes “loop body” last.

for :: [a] -> (a -> IO b) -> IO [b]

As with traverse, it exists in an underscored version that throws away the values produced by the side effect.

for_ :: [a] -> (a -> IO b) -> IO ()

This swapped-parameters version of traverse is convenient whenever we need something that resembles a for loop in other languages. The general pattern of the Haskell for loop is

for collection $ \item -> do
  things

This, again, highlights how side-effects-as-first-class-values lets us do meta programming. The for loop is not syntax. There is nothing (other than side effects) built into the language supporting this construct. It is made entirely from library functions.

My imagination is running dry, so we will use a convoluted example to illustrate this. We are trying to break weak cryptography, and we have a list of numbers for which we want to get the largest prime factor of each. This is a pure function (no side effects) at its core, but we know factorisation is expensive, and we suspect we will receive the same numbers repeatedly, so we will cache the results of the computation. Once we involve the cache, the function becomes side effectful. Here’s a first draft of such a function.

factorise :: [Int] -> IO [(Int, Maybe Int)]
factorise numbers = do
  -- Create a mutable variable with an empty dictionary.
  cache <- newIORef M.empty
  -- Loop through all numbers we received.
  for numbers $ \n -> do
    -- Get what's in the cache for this number.
    cached <- M.lookup n <$> readIORef cache

    factor <- case cached of
      -- If the cache contained the factor for n, use it
      -- as it is.
      Just f -> pure f
      -- If the cache did not contain the factor, compute
      -- it fresh and cache it.
      Nothing -> do
        let f = greatest_factor n
        modifyIORef cache (M.insert n f)
        pure f

    -- If the greatest factor is the number itself, it is
    -- prime. Otherwise, it can be divided by factor.
    if factor == n then
      pure (n, Nothing)
    else
      pure (n, Just factor)

This seems rather … procedural. Even though we get all the nice guarantees of working with side effectful functions in Haskell, the code itself reads like any other procedural language would. With Haskell, we get the best of both worlds.