Question

I am a beginner with haskell and am reading the Learn you a haskell book. I have been trying to digest functors and applicative functors for a while now.

In the applicative functors topic, the instance implementation for Maybe is given as

instance Applicative Maybe where
  pure = Just
  Nothing <*> _ = Nothing
  (Just f) <*> something = fmap f something

So, as I understand it, we get Nothing if the left side functor (for <*>) is Nothing. To me, it seems to make more sense as

  Nothing <*> something = something

So that this applicative functor has no effect. What is the usecase, if any for giving out Nothing?

Say, I have a Maybe String with me, whose value I don't know. I have to give this Maybe to a third party function, but want its result to go through a few Maybe (a -> b)'s first. If some of these functions are Nothing I'll want them to silently return their input, not give out a Nothing, which is loss of data.

So, what is the thinking behind returning Nothing in the above instance?

Was it helpful?

Solution

How would that work? Here's the type signature:

(<*>) :: Applicative f => f (a -> b) -> f a -> f b

So the second argument here would be of type Maybe a, while the result needs to be of type Maybe b. You need some way to turn a into b, which you can only do if the first argument isn't Nothing.

The only way something like this would work is if you have one or more values of type Maybe (a -> a) and want to apply any that aren't Nothing. But that's much too specific for the general definition of (<*>).


Edit: Since it seems to be the Maybe (a -> a) scenario you actually care about, here's a couple examples of what you can do with a bunch of values of that type:

Keeping all the functions and discard the Nothings, then apply them:

applyJust :: [Maybe (a -> a)] -> a -> a
applyJust = foldr (.) id . catMaybes

The catMaybes function gives you a list containing only the Just values, then the foldr composes them all together, starting from the identity function (which is what you'll get if there are no functions to apply).

Alternatively, you can take functions until finding a Nothing, then bail out:

applyWhileJust :: [Maybe (a -> a)] -> a -> a
applyWhileJust (Just f:fs) = f . applyWhileJust fs
applyWhileJust (Nothing:_) = id

This uses a similar idea as the above, except that when it finds Nothing it ignores the rest of the list. If you like, you can also write it as applyWhileJust = foldr (maybe (const id) (.)) id but that's a little harder to read...

OTHER TIPS

Think of the <*> as the normal * operator. a * 0 == 0, right? It doesn't matter what a is. So using the same logic, Just (const a) <*> Nothing == Nothing. The Applicative laws dictate that a data type has to behave like this.

The reason why this is useful, is that Maybe is supposed to represent the presence of something, not the absence of something. If you pipeline a Maybe value through a chain of functions, if one function fails, it means that a failure happened, and that the process needs to be aborted.

The behavior you propose is impractical, because there are numerous problems with it:

  1. If a failed function is to return its input, it has to have type a -> a, because the returned value and the input value have to have the same type for them to be interchangeable depending on the outcome of the function
  2. According to your logic, what happens if you have Just (const 2) <*> Just 5? How can the behavior in this case be made consistent with the Nothing case?

See also the Applicative laws.

EDIT: fixed code typos, and again

Well what about this?

Just id <*> Just something

The usecase for Nothing comes when you start using <*> to plumb through functions with multiple inputs.

(-) <$> readInt "foo" <*> readInt "3"

Assuming you have a function readInt :: String -> Maybe Int, this will turn into:

(-) <$> Nothing <*> Just 3

<$> is just fmap, and fmap f Nothing is Nothing, so it reduces to:

Nothing <*> Just 3

Can you see now why this should produce Nothing? The original meaning of the expression was to subtract two numbers, but since we failed to produce a partially-applied function after the first input, we need to propagate that failure instead of just making up a nice function that has nothing to do with subtraction.

Additional to C. A. McCann's excellent answer I'd like to point out that this might be a case of a "theorem for free", see http://ttic.uchicago.edu/~dreyer/course/papers/wadler.pdf . The gist of this paper is that for some polymorphic functions there is only one possible implementiation for a given type signature, e.g. fst :: (a,b) -> a has no other choice than returning the first element of the pair (or be undefined), and this can be proven. This property may seem counter-intuitive but is rooted in the very limited information a function has about its polymorphic arguments (especially it can't create one out of thin air).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top