<div dir="ltr">Did you consider the transitive dependency from errors?<div><br></div><div>Errors re-exports Control.Monad.Trans.Either from Control.Error.</div><div><br></div><div>In particular I noted that snap then depends on errors.</div>
<div><br></div><div>I didn't grep through the source though.</div><div><br></div><div>-Edward<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 13, 2013 at 1:25 PM, Ross Paterson <span dir="ltr"><<a href="mailto:R.Paterson@city.ac.uk" target="_blank">R.Paterson@city.ac.uk</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">On Tue, Aug 13, 2013 at 10:30:23AM -0400, Edward Kmett wrote:<br>
> An argument against just randomly bikeshedding the name it is there<br>
> are a lot of packages out there currently transitively depending on<br>
> the existing either package, due to the popularity of Tekmo's errors<br>
> package and the fact that it has been picked up by snap. So half of<br>
> the web-apps in the ecosystem depend on this type transitively.<br>
<br>
</div>Fortunately it seems that EitherT is only used by the following packages:<br>
<br>
citation-resolve coroutine-object CSPM-Frontend errors<br>
happstack-heist hoodle-core hoodle-parser katt pdf-toolbox-core<br>
pianola restricted-workers terminfo-hs<br>
<br>
Moreover adding a new module and type means people can switch over an<br>
extended timescale. Thus I think internal consistency within transformers<br>
outweighs compatibility with the existing EitherT in this case.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>