Mark Lentczner (@mzero) sent in his Control.Monad.Exception, and there is also MonadCatchIO-transformers.
Do these belong within the scope of the mtl?
The code was merged into master in my project, so please see this link: Control.Monad.Exception
This code is similar to MonadCatchIO, but differs in three ways:
The code doesn't assume the monad stack is rooted in IO. It is possible to have a non-IO stack that does exceptions.
The code provides a pure, non-IO implementation: ExceptionT
Async handling is based on the newer mask operation, not the now-deprecated block and unblock.
A consequence of 1 & 3 is that the typeclass MonadException has throw, catch, and mask in it. Whereas MonadCatchIO has catch, block, and unblock.
ping! Any thoughts on this as a direction? There is now at one package (cgi) that is being held back in the Platform because mtl hasn't incorporated some solution to extensible exceptions, and later versions of that package are using MonadCatch-IO which isn't in the platform.
If my code is along the lines mtl wants to go, I'll happily prepare my code as a patch to mtl.
I'm somewhat leery of adding something like it directly into the mtl in that it starts requiring the mtl to take on more extensions than we currently use.
mtl has maintained portability across every compiler with MPTCs since pretty much the dawn of time.
Have you looked at the existing attempt package ?
I'd be happy to collaborate on a solution, but the more I think about it the more I do think it belongs in a separate package. It'd allow it to rev faster to get acceptance.
I'm not advocating for attempt as the solution to what you want, just as a source of ideas.
In particular we don't currently use higher rank types in the MTL. This caveat matters because otherwise we could have a nicer callCC, etc. so its a fairly long held position for the library. One reason is they tend to require lots of signatures, haven't been supported historically on all platforms, inference around them behaves differently across even different GHC versions, etc.
I'm agnostic. If you'd like to leave it out, fine. At present, though, extensible extensions are here to stay in GHC, and packages that use mtl will need a canonical way to use them. Until that canonical way is in the platform, it will leave packages that use mtl, and need this, somewhat out of sorts.
We can definitely make a separate exceptions package, and lobby to add it to the platform, etc. but it seems to me to be bad citizenship to take away the ability to use the mtl from everyone else to support a feature GHC unilaterally brought into the picture. ;)
Mind you, I use extensible exceptions heavily and can only even vaguely recall how they used to work. =)
I've initialized http://github.com/ekmett/exceptions and added you with commit access.
As this has been taken up by exceptions, I'm closing this out.