Proposal to solve the `EitherT` problem.

Edward Kmett ekmett at
Tue Aug 13 22:39:13 CEST 2013

Did you consider the transitive dependency from errors?

Errors re-exports Control.Monad.Trans.Either from Control.Error.

In particular I noted that snap then depends on errors.

I didn't grep through the source though.


On Tue, Aug 13, 2013 at 1:25 PM, Ross Paterson <R.Paterson at>wrote:

> On Tue, Aug 13, 2013 at 10:30:23AM -0400, Edward Kmett wrote:
> > An argument against just randomly bikeshedding the name it is there
> > are a lot of packages out there currently transitively depending on
> > the existing either package, due to the popularity of Tekmo's errors
> > package and the fact that it has been picked up by snap. So half of
> > the web-apps in the ecosystem depend on this type transitively.
> Fortunately it seems that EitherT is only used by the following packages:
>         citation-resolve coroutine-object CSPM-Frontend errors
>         happstack-heist hoodle-core hoodle-parser katt pdf-toolbox-core
>         pianola restricted-workers terminfo-hs
> Moreover adding a new module and type means people can switch over an
> extended timescale.  Thus I think internal consistency within transformers
> outweighs compatibility with the existing EitherT in this case.
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list