[Haskell-cafe] Portability of MonadError

[Luke Palmer]

On Mon, Jan 5, 2009 at 1:48 PM, Peter Robinson <thaldyron at gmail.com> wrote:

> Hello,
>
> One thing that's been bothering me about MonadError monads is
> the non-portability of code that uses a custom Error type.  Meaning, if I
> have libraries A and B that use different error types, I won't be able to
> write a function func:
>
> func = (funcA >> funcB) `catchError` (\e -> ...)
>
> funcA :: ErrorT MyErrorA m ()
>
> funcB :: ErrorT MyErrorB m ()
>
> So I'm wondering whether there's a reason not to introduce a type class
> hierarchy instead of custom error types to make the code more portable.


I think this worry is related to a world view of "large monads", which also
proliferates claims like "monads are not appropriate for large programs",
and is related to fat interfaces in OOP.  I claim that, like objects, monads
are appropriate for little pieces of computations, and monadic computations in
different monads deserve to be composed just as much so as those in the same
monad.

The complex type-directed approach gives the feel of exceptions from
mainstream languages, but will run into problems when eg. two computations
both use ErrorT String, but you want to differentiate the errors.  All that
is necessary is a simple function:

mapError :: (e -> e') -> ErrorT e a -> ErrorT e' a
mapError f = ErrorT . liftM (left f) . runErrorT

(Where "left" is from Control.Arrow, and is a "semantic editor")

Then your example can become::

func = (mapError Left funcA >> mapError Right funcB) `catchError` (\e ->
...)

Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090105/4b10a6eb/attachment.htm