The Mechanics of Maybe

Our world is full of uncertainty. This uncertainty bleeds into our programs. A common way of dealing with this is null/nil. Unfortunately, this leads to even more uncertainty because this design means any value in our system could be null unless we’ve explicitly checked it’s presence. Constantly checking the presence of every value is a lot of work so we tend to only check the riskiest places and then have to deal with runtime null exceptions in the rest of our code.

Maybe

Elm and many other languages use a different approach to dealing with uncertainty: Maybe.

In Elm, all values are guaranteed to be present except for those wrapped in a Maybe. This is a critical distinction. You can now be confident in most of your code and the compiler will force you to make presence-checks in places where values are optional.

Case statements

The most basic way of dealing with a Maybe is via a case statement:

case someOptionalValue of
  Just value -> -- do something if present
  Nothing -> -- do something if NOT present

This is your standard presence-check.

Unfortunately, this can quickly devolve into a nightmare of nested case statements. For example, say you have a list of users and you want to uppercase the name of the first friend of the first user. You’d end up with this monstrosity:

case List.head users of
  Just user ->
    case List.head user.friends of
      Just friend ->
        Just (String.toUpper friend.name)

      Nothing ->
        Nothing

  Nothing ->
    Nothing

Luckily, the language can help us out with some helper functions.

Helper functions - unwrapping

A few checks are so common that there are convenient helper functions for them so you don’t have to write manual case statements.

For example, when trying to unwrap an optional value you need to handle the case where it isn’t present. This is typically done by providing some default value.

case optionalNumber of
  Just number -> number
  Nothing -> 0 -- return the default 0 when we didn't have a value

With the helper function Maybe.withDefault it becomes

Maybe.withDefault 0 optionalNumber

Helper functions - unwrapping and re-wrapping

Often there is no sensible default value so you just want to re-wrap in Maybe after doing a calculation. Isolating the first step of our big case statement (getting the friends of the first user) we might say:

case List.head users of
  Just user -> Just user.friends
  Nothing -> Nothing

This keeps propagating the Maybe forward down the chain. It’s very common to want to say “call this function if the value is present and return a new Maybe” so there’s a helper function we can use here: Maybe.map:

Maybe.map .friends (List.head users)

Helper functions - nested maybes

Sometimes, the function you call when the value is present already returns a Maybe so there’s no need to re-wrap it in Just. Isolating the second step of our big case statement (getting the first friend) might look like:

case maybeFriends of
  Just friends -> List.head friends -- no Just here
  Nothing -> Nothing

While it might look like we can use map here, there’s one crucial distinction: map re-wraps your successful computation with Just. That means using map here would result in a doubly-nested maybe which is not what we wanted.

Instead, we can use the Maybe.andThen function:

maybeFriends
  |> Maybe.andThen List.head

A more extreme case

Looking at a more extreme case, say we wanted to get at the head of the inner list [[[[1, 2]]]] using repeated uses of List.head:

[[[[1, 2]]]]
  |> List.head -- Just [[[1, 2]]]
  |> Maybe.map List.head -- Just (Just [[1,2]])
  |> Maybe.map (Maybe.map List.head) -- Just (Just (Just [1,2]))
  |> Maybe.map (Maybe.map (Maybe.map (List.head)) -- Just (Just (Just (Just 1)))

We got the head of the inner list but now it’s deeply nested inside of Maybes so every step we need nested maps. This will not scale 😰

Consider the andThen-based implementation instead

[[[[1, 2]]]]
  |> List.head -- Just [[[1, 2]]]
  |> Maybe.andThen List.head -- Just [[1,2]]
  |> Maybe.andThen List.head -- Just [1,2]
  |> Maybe.andThen List.head -- Just 1

Notice that each step is only a single Just deep, no matter how many times we chain.

map vs andThen

So when do you want to use map vs andThen? A quick trick is to look at the return type of the function you’re passing in:

something -> Maybe somethingElse -- use andThen
something -> somethingElse -- Use map

In our example above, .friends returns a list so we can use it with map while List.head returns a maybe so we need to use andThen.

Nested case statements

When first using Maybe, you’ll often end with large, nested case statements. A closer look usually reveals that they conform to one of the three patterns shown earlier.

Remember that nested case statement we started with?

case List.head users of
  Just user ->
    case List.head user.friends of
      Just friend ->
        Just (String.toUpper friend.name)

      Nothing ->
        Nothing

  Nothing ->
    Nothing

Nested branching logic, error handling, and duplicated cases make it very difficult to follow the logic here. 😁

All those trailing Nothing -> Nothing cases are a giveaway that we can clean this up using some of the helper functions. Combine them all into a pipeline and we get:

users
  |> List.head
  |> Maybe.map .friends
  |> Maybe.andThen List.head
  |> Maybe.map .name
  |> Maybe.map String.toUpper

This is much nicer to read but is still equivalent to the case statement. In part 2, we’ll look at problem solving with Maybe and how changing the structure of our logic can help push uncertainty to the edges of our system.