[Haskell] A collection of related proposals regarding monads

ajb at spamcop.net ajb at spamcop.net
Wed Jan 4 16:30:47 EST 2006

G'day Cale.

Quoting Cale Gibbard <cgibbard at gmail.com>:

> I personally feel that the inclusion of 'fail' in the Monad class is
> an ugly solution to the problem of pattern matching, and gives the
> incorrect impression that monads should have some builtin notion of
> failure.

So do I.

> We ought to be using MonadZero when we want to express failure, but it's
> gone!

I agree!

> What do people think of the following proposal?

I don't like it.

My feeling is that do { p <- xs; return e } should behave identically
(modulo the precise error message if the pattern match fails) to
map (\p -> e) xs.  Your proposal would make it into a map/filter

Speaking more practically, if a pattern match is technically refutable,
but I, as the programmer, intend it never to fail, then I shouldn't need
to use MonadZero.

I don't like fail either, but I must admit that I like allowing refutable

> Thus, refutable pattern matches occuring in a do-expression would
> force the expression to be typed explicitly with MonadZero. This is
> probably a good thing, as it forces one to think about the
> consequences of not properly dealing with a pattern match in any monad
> which doesn't explicitly allow for failure.

Surely this is no different from not properly dealing with a pattern match
in a case statement?

> Even if this translation of do-syntax isn't accepted, I still think
> that we should have a separate MonadZero.

I agree.  I miss MonadZero.

> I'd also like to see the current use of MonadPlus split into MonadElse
> (or MonadOr) and MonadPlus, [...]

I agree, but I think such a proposal shouldn't be considered in isolation
from standardising some MTL-like library.

> Lastly, it would be nice to have some standard name for the function:
> option :: (MonadPlus m) => [a] -> m a
> option = foldr (mplus . return) mzero
> which seems to come up quite a bit in my experience with nondet monads.

I liked Oleg's suggestion: "choose", since it's the realisation of the
axiom of choice.  Though possible "mchoose" might be more appropriate.
Even more appropriate might be to rationalise some of these naming

Andrew Bromage

More information about the Haskell mailing list