[Haskell] Long live Edison

[Cale Gibbard]

On 20/02/06, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> Hello,
>
> On 2/20/06, John Meacham <john at repetae.net> wrote:
> > I think the problem is that 'mzero' exists, the correct solution seems
> > to be to get rid of the 'mzero' method of MonadPlus. Since haskell is
> > lazy, all Monads have at least the zero of _|_ which can be overriden by
> > 'fail' with a more suitable one. MonadPlus should be about extending
> > monads with an additive operator, there is no need for another concept
> > of zero and it seems to me that is the real issue. mzero can simply be
> > defined as 'fail "mzero"'.
>
> In what sense is _|_ a 'zero'?
>
> -iavor

This ties in with an important point which I've been pushing lately,
that bottom should not be used for expected failure. Expected failure
should be explicit, and  appropriate monads (not monads in general!)
make this convenient. I am rather strongly of the opinion that fail
should not be a method of the monad class, since it is so common that
the only implementation one can give, even in perfectly reasonable
monads, is 'error'. Bottom is acceptably used in sanity checks where
if it occurs, the programmer must be at fault. However, due to the
inconvenience of catching _|_ in IO, I really find that in the vast
majority of cases, explicitly representing failure (the Maybe and
Either String monads being common candidates) is much nicer when
errors are to be expected and handled internally to the application.

One thing which I found odd about the NotJustMaybe pattern is that not
much is really gained apart from a small amount of convenience. Of
course, you get to pass back that string which is sometimes an
advantage over Maybe but Either String gives you that as well. It's
rather easy to embed Either String, or Maybe into any suitable larger
monad which would otherwise apply, and you get more information about
what type of errors can be passed back. (Maybe of course just
represents partiality, while the use of Either String explicitly tells
you that the function is prepared to hand you some form of error
string.) Further, if the inconvenience of doing that embedding is
still too great, we have the typeclass MonadError to differentiate
between monads with and without failure mechanisms -- perhaps it could
be cleaned up a bit in a few ways, but I think the idea is right.

 - Cale