Re: exceptions API (Was: deprecating Error class, which Was: Proposal: add handleError to mtl))

On a somewhat related note, I've started but not yet released an 'exceptions' package based on some work from Mark Lentczner, after he encouraged me to explore the design space with an eye towards inclusion in the platform because some packages like CGI need something like MonadCatchIO-transformers, but GHC HEAD removed block and unblock, so the MonadCatchIO-transformers API is broken. It doesn't fall into the scope of the mtl as it relies on the extensible exceptions mechanism and so needs ExistentialQuantification, but it provides a generalization of the Control.Exception API that lifts it over monad transformers along with a pure untagged exception-handling monad. https://github.com/ekmett/exceptions I was going to sound folks out about what improvements they wanted to see in the API over this weekend at Hac Phi, but I suppose I can throw that out to the larger libraries list as well, given the current discussion. The haddocks for the development version are available here: file://localhost/Users/ekmett/haskell/exceptions/docs/Control-Monad-Catch.html -Edward On Thu, Jun 6, 2013 at 7:00 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Thu, 6 Jun 2013, Roman Cheplyaka wrote:

* Henning Thielemann [2013-06-06

...

12:14:10+0200]

...

On Wed, 5 Jun 2013, Ross Paterson wrote:

On the subject of ErrorT, I wonder if it's time to deprecate the Error

...

class.

Since I think ErrorT gives the wrong association with the 'error' function, I would prefer to give up the Control.Monad.Trans.Error module entirely and start a new module Control.Monad.Trans.Exception.

... which would give the wrong association with exceptions (in the Control.Exception sense). I don't see how this is an improvement.

It's the better association and it is already mentioned in the module description of Control.Monad.Trans.Error:

"This monad transformer adds the ability to fail or throw exceptions to a monad."

Nonetheless, you may suggest another module name. Independent from the name of a new module, I would suggest to deprecate the Error name instead of removing something from the Error module.

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://www.haskell.org/mailman/listinfo/libraries