On Thu, Sep 24, 2009 at 8:11 AM, pepe
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...