[Haskell-beginners] Maybe, Either

[Conor McBride]

Hi

This topic comes up a lot, and this is what I usually say when
it does. It's a thing I learned from James McKinna, many years
ago...

Might I gently suggest that there is a much better, more
natural way to abstract over every type-former which has
some sort of return/pure-like thing and some sort of mzero/empty
like thing? You could use the type-former which is inductively
defined to be the least such thing, and as such has a canonical
mapping to all the others, namely Maybe.

It's not necessarily a good idea to fix on Monad or MonadPlus
as there are other choices. For example,

On 15 Sep 2009, at 07:14, Yusaku Hashimoto wrote:

> I prefer Alternative to MonadPlus for explaining failure. It has
> better name and operator for failure and try-another.
>
> import Control.Applicative
>
> aLookup :: (Alternative f, Eq k) => k -> [(k,v)] -> f v
> aLookup key pairs = maybe empty pure $ lookup key pairs

there are notorious non-monadic instances for the above f
(some formulations of parsing, in particular). So,

>> I understand that fail being in Monad is controversial, but my  
>> version of
>> the function works in *all* monads.

this is a touch presumptuous. On the one hand, Brent is right
when he says

 > It doesn't work in *all* monads -- it only works in monads which
 > support a sensible notion of failure.

but he's perhaps excessive when he says

 > This is exactly what is captured by the MonadPlus constraint
 > on my version of mLookup.

because it's not exact: it requires mplus as well as a sensible
notion of failure. And yes, why should we insist on (>>=) when
we just need a return and an mzero?  Incidentally, I don't know
where the MonadPlus instance

 > (IO, Maybe, [], ...) are already instances of MonadPlus.

of IO is coming from, but I want it caught and locked up now (in
STM, for example) before it does any permanent damage.

Why not factor out the failure-prone operations from the business
of interpreting failure in some failure-supporting context? Work
concretely while you can (types stay shorter, error messages make
more sense) then apply adapters

malt :: Alternative f => Maybe x -> f x
malt = maybe empty pure

mop :: MonadPlus m => Maybe x -> m x
mop = maybe mzero return

when you need to? This also reduces the risk of connecting an
ambiguous supplier to an ambiguous consumer, (show . read) style.

The message clearly bears repeating. Inductive definition is
a concrete form of abstraction. Don't be fooled by its
appearance: Maybe is the most abstract choice here -- the
classier options demand more structure than is needed and
thus exclude use-cases.

I'll crawl back under my stone now.

All the best

Conor