Maybe Is Just Awesome

In Haskell, functions must always return the same consistent type. There is also no concept of nil or null built into the language. This is not meant to handicap you, and the expressiveness and polymorphic-ness of Haskell’s types mean it certainly does not. One way to handle such situations where functions (conceptually) may or may not return a value is through the Maybe type.

data Maybe a = Just a | Nothing

Maybe is a perfect and simple solution for this situation. It says that, for all values of type a, we can construct values that are either Just that or Nothing.

This type is also perfect for illustrating some of Haskell’s more math-heavy concepts. If we take all the potential a values as one category and all the potential Maybe a values as another, then we can use this type to describe the Functors of Category Theory. If we also think about the difference between some a and its Maybe a counterpart as some sort of state to be managed throughout an execution chain, then we can also use this type to describe a Monad. In both cases, the benefits are more concise code and a greater understanding of these abstract concepts that we can take with us to more complex type interactions.

Functor 🔗

A Functor is a way to transform a function (more formally a morphism) that acts on one category of objects into one that can act on objects in another category. In Haskell, this concept is captured by the Functor typeclass. It states that for any type t that takes one argument (like Maybe), we can make it an instance of Functor by defining the translation function fmap:

fmap :: Functor t => (a -> b) -> (t a -> t b)

This specifies precisely how a function that acts on one set of types (a -> b) can be used on types that are wrapped versions of these (t a -> t b).

So how is Maybe a Functor?

instance Functor Maybe where
    fmap _ Nothing  = Nothing
    fmap f (Just a) = Just (f a)

Seems straight forward, if the value is Just we apply the morphism to the underlying object and rewrap the result in Just. Trying to apply a morphism to a Nothing value just results in Nothing.

Monad 🔗

A Monad is a very scary term to Haskell noobies. Mainly because the first Monad we are introduced to is IO. It’s used for any computation that affects (or draws on) the outside world. We’re told that it handles potential failures and manages state between computations. Most times we accept it as magic and blindly memorize the do notation and counter-intuitive return statements.

We can take a step back, talk about a Monad in very general terms, then describe how Maybe types work as a Monad. Given that understanding, we can get a better handle on what State and IO Monads are doing (even if we still have to think of it as a bit of magic).

A Monad is a way to chain multiple computations together and manage how that chain of actions works as a whole. The Monad laws will manage the state between these actions (ensuring dependent actions are run in the correct order since they might rely on more than just their direct arguments) and also any failing cases (if some action fails, future actions are aborted and the whole expression is a failure).

Somewhat surprisingly, any type can act as a Monad by defining a few simple functions. I’m going to show and talk about them separately because I think it can go a long way to understanding Monads in general.

instance Monad Maybe where
    -- (>>=) :: m a -> (a -> m b) -> m b
    (Just x) >>= k = k x
    Nothing  >>= _ = Nothing

Here we’re just showing how to chain two dependant actions together – that’s really all it is. The first “action” is a wrapped value (m a), the second argument is a function which acts on the unwrapped value producing a new wrapped value (a -> m b). For Maybe we just have to account for the Just and Nothing cases appropriately.

    -- (>>) :: m a -> m b -> m b
    (Just _) >> k = k
    Nothing  >> _ = Nothing

Here we’re showing how to chain two independant actions together. We’re still preserving the fact that if the first action “fails” the second action is not run, but in this case the result of the first action has no bearing on the second.

    -- return :: a -> m a
    return = Just

return is simply a way to take some non-monadic value and treat it as a Monadic action. In our case wrapping a value in Just does just that.

    -- fail :: String -> m a
    fail _ = Nothing

There’s also the concept of outright failure. For us it’s simple: Nothing is the failure case. The reason for the String argument is that Haskell allows you to include a message with the failure. There’s much contention in the Haskell community around including fail in the Monad type class, but we won’t get into that here as Maybe has a pretty simple implementation of it.

It should also be noted that the do and <- notation that everyone is used to can be “de-sugared” down to an expression using only the above 4 functions. If you’re having trouble seeing how an expression is leveraging the above laws to do what it does, it can be a good exercise to de-sugar it by hand.

Example Time 🔗

So why do we care? Well, besides using Maybe as an illustration for hard-to-grasp concepts like Functors and Monads, knowing when to use those instances of Maybe can really cut down on code clutter and lead to elegant solutions when you’ve got a lot of Maybe-heavy code.

Let’s say you’ve got a user model in your webapp with an optional email field. This field is a custom type Email but you’ve got a function for translating it to Text. You’ve also got another general function for displaying Text values on the page as Html.

Because you were thinking ahead and you knew there’d be a lot of Maybe Text values in use throughout your site, you’ve coded your display function to accept maybe values and show an empty string in these cases.

userEmail :: User -> Maybe Email
userEmail = undefined

emailToText :: Email -> Text
emailToText = undefined

display :: Maybe Text -> Html
display = undefined

In the described ecosystem your going to have a lot of core Maybe values and a lot of value-manipulation functions not in Maybe. To put this in category terms, you’ve got a lot of morphisms in the non-maybe category and a lot of objects in the maybe category. You’re going to want to fmap that.

Here’s how the code looks without leveraging the fact that Maybe is a Functor:

displayUserEmail :: User -> Html
displayUserEmail u = let me = userEmail u
                     in display $ case me of
                         Just e  -> Just (emailToText e))
                         Nothing -> Nothing

Not terrible, but notice how fmap shrinks it right up:

displayUserEmail :: User -> Html
displayUserEmail = display . fmap emailToText . userEmail

Not only does it make the code clearer and cleaner, but it serves a common purpose: you’re going to have a lot of value-manipulating functions that should operate on basic values and not care about any wrapping. Just because you’ve got a lot of these values wrapped up in Maybe, that shouldn’t stop you from using these morphisms from the other category in this one. The nature of that Maybe wrapper allows fmap to easily handle the translation for you.

Sure, you could write a small function that takes functions that operate on normal values and allows them to be used on maybe values (and I think I did just that at one point) – but this concept of a Functor abstracts all that down to a simple generic fmap that can be used with a zillion different compound “wrapper” types.

-- something like this:
prettyNow :: IO String
prettyNow = do
  now <- getCurrentTime

  return $ formatPretty now

-- can be shorter:
prettyNow = fmap formatPretty getCurrentTime

prettyNow :: IO ()
prettyNow =
    getCurrentTime >>= \now ->
        return (formatPretty now)

Using Maybe as a Monad allows for even more verbose “stair-case” code to become much more readable. For this example, we’ve got a series of functions that translate values from one type to another. Any of these functions can fail if the input is not as expected and they capture this by returning maybe values:

textToXml :: Text -> Maybe Xml
textToXml = undefined

xmlToJson :: Xml -> Maybe Json
xmlToJson = undefined

jsonToResponse :: Json -> Maybe Response
jsonToResponse = undefined

As before, here’s that code written in a way that does not leverage Maybe’s monadic properties:

textToResponse :: Text -> Maybe Response
textToResponse t = let mx = textToXml t
                   in case mx of
                       Nothing -> Nothing
                       Just x  -> let mj = xmlToJson x
                                  in case mj of
                                      Nothing -> Nothing
                                      Just j  -> jsonToRepsonse j

What do you have here? A series of dependant computations where if any one of them fails we want the whole expression to fail. Strictly using what we’ve learned in this post, we can simplify this to the following:

textToResponse :: Text -> Maybe Response
textToResponse t = textToXml t >>= xmlToJson >>= jsonToResponse

And if you prefer do notation (I do), then we could write the above like so:

textToResponse :: Text -> Maybe Response
textToResponse t = do
    x <- textToXml t
    j <- xmlToJson x
    r <- jsonToResponse j

    return r

The r <- and return r is redundant but I think it shows more clearly the interaction between the as and Maybe as.

main :: IO ()
main = do
    -- this is IO
    text <- getSomeText

    let mresponse = do
            -- but this is Maybe
            x <- textToXml t
            j <- xmlToJson x
            r <- jsonToResponse j

            return r

    -- and IO again
    sendResponse mresponse

So hopefully you’ve all learned a little bit through this post. I know it was helpful for me to write it all out. We’ve seen that Maybe is a type that is complex enough to be used in a variety of different contexts but also simple enough to illustrate those contexts in an easier to grasp way. We’ve also seen that using these higher-level qualities of Maybe can lead to smaller, easier to read code.