<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">On Sun, Jun 16, 2013 at 02:52:46PM -0700, Gabriel Gonzalez wrote:<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">> There are three approaches that I'd like to submit for consideration<br></span><span style="font-family:arial,sans-serif;font-size:13px">> and receive feedback on:<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">><br></span><span style="font-family:arial,sans-serif;font-size:13px">> * Approach 1: Remove the `Error` constraint from `transformers`<br></span><span style="font-family:arial,sans-serif;font-size:13px">><br>
</span><span style="font-family:arial,sans-serif;font-size:13px">> Disadvantage: This silently breaks all existing uses of `fail`. I<br></span><span style="font-family:arial,sans-serif;font-size:13px">> don't know any way to add a compiler warning to notify downstream<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">> libraries of this change.</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">I'm in favour of this one. We can catch some of these uses by deprecating<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">the Error class, as the only predefined instances are for IOException<br></span><span style="font-family:arial,sans-serif;font-size:13px">and String.</span></blockquote>
<div><br></div><div style>I'm going to add another disadvantage of this approach: `ErrorT` is not as good of a name. `EitherT` is a more neutral name, which matters if you want to use it for non-error-based flow control like the way I describe here:</div>
<div style><br></div><div style><a href="http://www.haskellforall.com/2012/07/breaking-from-loop.html">http://www.haskellforall.com/2012/07/breaking-from-loop.html</a></div><div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> * Approach 2: Add `EitherT` to `transformers` alongside `ErrorT` and<br></span><span style="font-family:arial,sans-serif;font-size:13px">> have them both implement `MonadError`.<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">><br></span><span style="font-family:arial,sans-serif;font-size:13px">> Disadvantage: Bloat from having two almost identical monad<br></span><span style="font-family:arial,sans-serif;font-size:13px">> transformers. However, there is precedent from duplicating<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">> `StateT`, `WriterT` and `RWST` for both strict and lazy instances.</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">Those is at least a rationale for two StateT transformers with strict<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">and lazy instances. (Since the strict WriterT doesn't achieve its aim,<br></span><span style="font-family:arial,sans-serif;font-size:13px">I'm in favour of deprecating it, and the strict RWST.)</span></blockquote>
<div><br></div><div style>The nice thing about Approach 2 is that it is backwards compatible for now and gives downstream libraries a chance to gracefully transition to `EitherT` if you decide to deprecate `ErrorT`. This works out better than usual because the names are different so they can peacefully coexist for one release.</div>
<div style><br></div><div style>However, you might still want to keep `ErrorT` around as long as `fail` is still part of the `Monad` class.</div></div>