<div dir="ltr">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.<div>
<br></div><div>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.</div>
<div><br></div><div><a href="https://github.com/ekmett/exceptions">https://github.com/ekmett/exceptions</a><br></div><div><br></div><div style>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.</div>
<div style><br></div><div style>The haddocks for the development version are available here:</div><div style><br></div><div style>file://localhost/Users/ekmett/haskell/exceptions/docs/Control-Monad-Catch.html</div><div style>
<br></div><div style>-Edward</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 6, 2013 at 7:00 AM, Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Thu, 6 Jun 2013, Roman Cheplyaka wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a><u></u>> [2013-06-06 12:14:10+0200]<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Wed, 5 Jun 2013, Ross Paterson wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On the subject of ErrorT, I wonder if it's time to deprecate the Error class.<br>
</blockquote>
<br>
Since I think ErrorT gives the wrong association with the 'error'<br>
function, I would prefer to give up the Control.Monad.Trans.Error<br>
module entirely and start a new module Control.Monad.Trans.Exception.<br>
</blockquote>
<br>
... which would give the wrong association with exceptions (in the<br>
Control.Exception sense). I don't see how this is an improvement.<br>
</blockquote>
<br></div>
It's the better association and it is already mentioned in the module description of Control.Monad.Trans.Error:<br>
<br>
"This monad transformer adds the ability to fail or throw exceptions to a monad."<br>
<br>
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.<div class="HOEnZb"><div class="h5">
<br>
<br>
______________________________<u></u>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div></div>