[Haskell-cafe] best practices for monad transformers and exceptions?

Evan Laforge qdunkan at gmail.com
Thu Sep 24 15:10:28 EDT 2009

On Thu, Sep 24, 2009 at 8:11 AM, pepe <pepeiborra at gmail.com> wrote:
> Exceptions in the ErrorT monad are not compositional.
> It's the first time I see the approach of stacking
> several ErrorT monads. It seems slightly better than
> having a 'global' exception type, although the explicit
> lifting looks quite painful.
> I really don't know whether there is a way to write
> catch_abort, sorry! Even if there is, I don't think you
> want to use it. A much better option is to use an extensible
> exception type.

Yeah, I had forgotten about Tyeable implementations, which is silly
since that's how the IO exceptions now work.

Your extensible error framework looks pretty nice!  I just made the
exceptions global (i.e. put them all in the lowest level type) since I
only have two at this point, but if I had more I would definitely
check out Control.Monad.Exception.

Ideally I would like to be able to package up a set of "services" as a
transformer and plug it in compositionally without worrying about its
implementation, but it seems monad transformers are only part of the
way there.  You can get some hiding with a newtype, and then you can
get unlifted access with classes as mtl does (but then you need a
bunch of instance boilerplate), but then if the one of the services
the transformer needs is "early return", then you have to pull the
ErrorT out and put it into the "final" monad, and handle all the
exceptions in the final monad's "run".

It would be nice someday to have more satisfactory way of combining
effects.  I dream of a way to effortlessly create encapsulated
transformers that easily compose with other transformers...

More information about the Haskell-Cafe mailing list