Do we want to do something about extensible Exceptions? #3

Closed
ekmett opened this Issue Nov 27, 2012 · 9 comments

Projects

None yet

2 participants

@ekmett
Owner

Mark Lentczner (@mzero) sent in his Control.Monad.Exception, and there is also MonadCatchIO-transformers.

Do these belong within the scope of the mtl?

@mzero

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:

  1. The code doesn't assume the monad stack is rooted in IO. It is possible to have a non-IO stack that does exceptions.

  2. The code provides a pure, non-IO implementation: ExceptionT

  3. 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.

@mzero

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.

@ekmett
Owner

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.

@ekmett
Owner

I'm not advocating for attempt as the solution to what you want, just as a source of ideas.

@ekmett
Owner

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.

@mzero

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.

@ekmett
Owner

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. =)

@ekmett
Owner

I've initialized http://github.com/ekmett/exceptions and added you with commit access.

@ekmett
Owner

As this has been taken up by exceptions, I'm closing this out.

@ekmett ekmett closed this May 5, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment