[AnimalMuppet]

I'll take a shot at it.

Quoting tikhoni:

> For Maybe, being a monad gives us a standard way of working with values while automatically dealing with Nothing. It abstracts over repetitive null checking and lets us easily build up Maybe values based on other Maybe values.

To expand on that a bit, in a way that might work for you (or might not): I've got a function f a that exists. It works. It does exactly what I want. Unfortunately, the data I've got is a Maybe a, not just an a. So I can't use my nifty function f, because it takes an a. You can feel my annoyance/frustration - so near, and yet so far.

But, in fact, I can use my function f, because Maybe is a monad. That lets me apply f to my Maybe a, without having to change either f or a whatsoever. I don't even have to write the magic code to do this - Maybe already has it.

[rane]

Isn't Maybe being an instance of Applicative enough in this case?

[AnimalMuppet]

Maybe...

But seriously, I guess I think it's not a Monad. The Monad signature (in this case) is

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

and I think what we really want (and what I said we wanted to do) is

  Maybe a -> (a -> b) -> Maybe b

I don't know whether that's Applicative or Functor, but I don't think it's Monad.

[Muphrid]

That operation is called fmap, and it's characteristic of a functor. In Haskell, it's called liftM for monads, but they're really the same thing (and I think recent proposals are going to iron out this redundancy). fmap is one of the properties of a functor. All monads are functors, so all monads provide an operation with that signature.