Proposal: merge either into transformers
Vincent Hanquez
tab at snarc.org
Thu Apr 24 14:45:34 UTC 2014
On 2012-12-07 09:44, Roman Cheplyaka wrote:
> I propose to add the sole module of the 'either' package[1],
> Control.Monad.Trans.Either, to the transformers package.
>
> It provides EitherT, a very basic and fundamental data type. The
> difference between EitherT and ErrorT is that the latter has an Error
> constraint, which is used to imlement 'fail'.
>
> Note that 'either' depends on the 'semigroupoids' and 'semigroup'
> packages to provide appropriate instances. The proposal is not to add
> those instances to 'transformers' to avoid additional dependencies. The
> instances can then be left in the 'either' package or moved to the
> 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids'
> already depends on 'transformers', while 'semigroups' does not).
>
> Compared to the 'either' package, Show, Read, Eq and Ord instances will
> be dropped to keep the code Haskell2010 (those instances require
> FlexibleInstances, FlexibleContexts, and UndecidableInstances).
>
> The patch is attached. [*]
>
> [*] against transformers-0.3.0.0, because the darcs version is not
> buildable (Control/Monad/Signatures.hs is not in the repository).
>
[Sorry to revive this 1 yr 1/2 thread, but I was looking at the reason
why we don't have eitherT is a more canonical place like transformers,
and ended up here ...]
Is there a reason why this thread ran out of steam ? It not totally
obvious from the answers what was missing to move forward.
It seems like there's general agreement that EitherT is a good addition,
did this proposal got forgotten ? Is there a way to revive this proposal ?
Cheers,
--
Vincent
More information about the Libraries
mailing list