Proposal: merge either into transformers

[Edward Kmett]

Indeed. A proper "EitherT" was added, but due to bikeshedding turned into
ExceptT in the process complicating the migration story a fair bit. To get
a version of ExceptT for older transformers versions you can use
transformers-compat, so there is at least some migration story. =/

The either package will have the EitherT component deprecated eventually,
but should continue to exist for the combinators.

-Edward

On Sun, Jan 1, 2017 at 9:16 PM, Index Int <vlad.z.4096 at gmail.com> wrote:

> Perhaps ExceptT is what you're looking for? Check out the
> 'Control.Monad.Trans.Except' module in 'transformers'.
>
> On Mon, Jan 2, 2017 at 4:24 AM, Erik de Castro Lopo
> <mle+hs at mega-nerd.com> wrote:
> > Vincent Hanquez wrote:
> >
> >> 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 ?
> >
> > So now its me reviving a 2 1/2 year old response to a 6 year old thread.
> >
> > I came here exactly the same way as Vincent, wanting to a couple of new
> > combinators added to the either library, noticing that there was talk
> > of moving Control.Monad.Trans.Either to transformers or
> transformers-compat
> > and then it seemed to loose steam.
> >
> > Any clues as to where we're at with this?
> >
> > Erik
> > --
> > ----------------------------------------------------------------------
> > Erik de Castro Lopo
> > http://www.mega-nerd.com/
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170102/81420075/attachment.html>