Proposal: merge either into transformers
ross at soi.city.ac.uk
Fri Dec 7 18:45:49 CET 2012
On Fri, Dec 07, 2012 at 09:44:27AM +0000, Roman Cheplyaka wrote:
> I propose to add the sole module of the 'either' package,
> 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).
Orphan instances are to be avoided, so moving the instances to those
packages seems the only option.
> 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).
That's true. Some other points:
The either package has mapEitherT as the binary map
mapEitherT :: Functor m => (e -> f) -> (a -> b) -> EitherT e m a -> EitherT f m b
but consistency with the rest of transformers would apply this name to
mapEitherT :: (m (Either e a) -> n (Either e' b)) -> EitherT e m a -> EitherT e' n b
mapEitherT f m = EitherT $ f (runEitherT m)
(The binary map can't be recovered using Bifunctor because of the argument
hoistEither :: Monad m => Either e a -> EitherT e m a
Maybe transformers should have similar functions for all the other monad
left and right are used with different meanings in Control.Arrow
(surmountable with qualification, of course). I see that the idea
is to be symmetrical, but the monad structure is asymmetric.
Would we want a catch function?
More information about the Libraries