Haskell/Understanding monads/Maybe

We introduced monads using  as an example. The  monad represents computations which might "go wrong" by not returning a value. For reference, here are the definitions of  and   for   as we saw in the last chapter:

Safe functions
The  datatype provides a way to make a safety wrapper around partial functions, that is, functions which can fail to work for a range of arguments. For example,  and   only work with non-empty lists. Another typical case, which we will explore in this section, is mathematical functions like  and  ; (as far as real numbers are concerned) these are only defined for non-negative arguments.

> log 1000 6.907755278982137 > log (-1000) ERROR -- runtime error

To avoid this crash, a "safe" implementation of log could be:

> safeLog 1000 Just 6.907755278982137 > safeLog -1000 Nothing

We could write similar "safe functions" for all functions with limited domains such as division, square-root, and inverse trigonometric functions (, ,  , etc. all of which would have the same type as   but definitions specific to their constraints)

If we wanted to combine these monadic functions, the cleanest approach is with monadic composition (which was mentioned briefly near the end of the last chapter) and point-free style:

Written in this way,  resembles a lot its unsafe, non-monadic counterpart:

Lookup tables
A lookup table relates keys to values. You look up a value by knowing its key and using the lookup table. For example, you might have a phone book application with a lookup table where contact names are keys to corresponding phone numbers. An elementary way of implementing lookup tables in Haskell is to use a list of pairs:. Here  is the type of the keys, and   the type of the values. Here's how the phone book lookup table might look:

phonebook :: [(String, String)] phonebook = [ ("Bob",  "01788 665242"), ("Fred", "01624 556442"), ("Alice", "01889 985333"), ("Jane", "01732 187565") ]

The most common thing you might do with a lookup table is look up values. Everything is fine if we try to look up "Bob", "Fred", "Alice" or "Jane" in our phone book, but what if we were to look up "Zoe"? Zoe isn't in our phone book, so the lookup would fail. Hence, the Haskell function to look up a value from the table is a  computation (it is available from Prelude):

Let us explore some of the results from lookup:

Prelude> lookup "Bob" phonebook Just "01788 665242" Prelude> lookup "Jane" phonebook Just "01732 187565" Prelude> lookup "Zoe" phonebook Nothing

Now let's expand this into using the full power of the monadic interface. Say, we're now working for the government, and once we have a phone number from our contact, we want to look up this phone number in a big, government-sized lookup table to find out the registration number of their car. This, of course, will be another -computation. But if the person we're looking for isn't in our phone book, we certainly won't be able to look up their registration number in the governmental database. What we need is a function that will take the results from the first computation and put it into the second lookup only if we get a successful value in the first lookup. Of course, our final result should be  if we get   from either of the lookups.

If we then wanted to use the result from the governmental database lookup in a third lookup (say we want to look up their registration number to see if they owe any car tax), then we could extend our  function:

Or, using the -block style:

Let's just pause here and think about what would happen if we got a  anywhere. By definition, when the first argument to  is , it just returns   while ignoring whatever function it is given. Thus, a  at any stage in the large computation will result in a   overall, regardless of the other functions. After the first  hits, all  s will just pass it to each other, skipping the other function arguments. The technical description says that the structure of the  monad propagates failures.

Extracting values
If we have a  value, we can extract the underlying value it contains through pattern matching.

The usage pattern of replacing  with a default value is captured by the   function in.

The  Prelude function allows us to do it in a more general way, by supplying a function to modify the extracted value.

Prelude> :t maybe maybe :: b -> (a -> b) -> Maybe a -> b Prelude> displayResult (Just 10) "The result was 10" Prelude> displayResult Nothing "There was no result"

The possibility of, whenever possible, extracting the underlying values makes sense for : it amounts to either extracting a result from a successful computation or recovering from a failed computation by supplying a default. It is worth noting, though, that what we have just seen doesn't actually involve the fact of  being a monad. and, on their own, do not enable us to extract the underlying value from a monadic computation, and so it is perfectly possible to make a "no-exit" monad, from which it is never possible to extract values. The most obvious example of that is the  monad.

Maybe and safety
We have seen how  can make code safer by providing a graceful way to deal with failure that does not involve runtime errors. Does that mean we should always use  for everything? Not really.

When you write a function, you are able to tell whether it might fail to produce a result during normal operation of the program, either because the functions you use might fail (as in the examples in this chapter) or because you know some of the argument or intermediate result values do not make sense (for instance, imagine a calculation that is only meaningful if its argument is less than 10). If that is the case, by all means use  to signal failure; it is far better than returning an arbitrary default value or throwing an error.

Now, adding  to a result type without a reason would only make the code more confusing and no safer. The type signature of a function with unnecessary  would tell users of the code that the function could fail when it actually can't. Of course, that is not as bad a lie as the opposite one (that is, claiming that a function will not fail when it actually can), but we really want honest code in all cases. Furthermore, using  forces us to propagate failure (with   or monadic code) and eventually handle the failure cases (using pattern matching, the   function, or   from  ). If the function cannot actually fail, coding for failure is an unnecessary complication.