Merge either into transformers

[Yitzchak Gale]

OK. I hope I wasn't misunderstood as implying that there
was any neglect here. If that's the situation, is there some
comment we can add to either so that new users will know
about it, and consider using ExceptT instead?

My own situation is that, as a frequent (addicted?) user
of either, I was't aware until now that there was anything to
look at in transformers.

I also often use the either package for things like early
escape from calculations. If that will eventually be moving
to transformers as well, then something ought to be
said about that in transformers, too.


On Mon, Dec 29, 2014 at 2:15 AM, Edward Kmett <ekmett at gmail.com> wrote:
> either is currently not deprecated because the move to a newer version of
> transformers is a very slow process.
>
> It is a ghc boot package, so most users of either currently can't upgrade
> it. We've yet to even get stackage able to use the new version of
> transformers, for instance.
>
> ErrorT was deprecated very very quickly, so many users are stuck in a
> situation where they can't move off it, but can't clear the warnings on
> modern builds.
>
> I've also had a number of users asking me explicitly not to remove it from
> the either package, either because they don't like the color of the new
> bikeshed, or because they need the existing style of instances and can't
> easily move. I'm somewhat dubious on that front, I personally think the
> right long term solution _is_ to consolidate behind ExceptT, when it has a
> wide enough installable user base that people can switch.
>
> I have users I must support on GHC 7.4 who need to use ghc-api and so are
> locked into the version of transformers that ships with the compiler.
>
> But as a result, I'm inclined to take things very slow with regards to any
> deprecation on the either side, rather than just randomly sow further
> confusion; the status quo is more one of deliberate inaction than neglect.
>
> -Edward
>
> On Sun, Dec 28, 2014 at 5:50 PM, Yitzchak Gale <gale at sefer.org> wrote:
>>
>> Glad to hear.
>>
>> The next step was supposed to be moving a few instances out of
>> the either library and deprecating that library. Is that no longer
>> planned?
>>
>> Whether or not it will be deprecated, a prominent note about this
>> really should be added to the package description of the either
>> library.
>>
>> And a note should be added to the module description of
>> Control.Monad.Trans.Except that throwing exceptions is only
>> one of many uses for this monad. I frequently use (the old
>> either library version of) this monad for complex conditional
>> logic and early exit from computations, at least as often as
>> I use it for throwing exceptions.
>>
>> Thanks,
>> Yitz
>>
>>
>> On Mon, Dec 29, 2014 at 12:29 AM, Roman Cheplyaka <roma at ro-che.info>
>> wrote:
>> > It is already merged (under the name of ExceptT).
>> >
>> > On 28/12/14 23:14, Yitzchak Gale wrote:
>> >> Roman Cheplyaka wrote in February 2014:
>> >>>> I proposed to merge either into transformers more than a year ago[1],
>> >>>> and everyone seemed to agree. Could you please do it?
>> >>>>
>> >>>> [1]:
>> >>>> http://www.haskell.org/pipermail/libraries/2012-December/019027.html
>> >>
>> >> Ross Paterson responded:
>> >>> Not everyone agreed when we discussed this last August.  My proposal
>> >>> then
>> >>> was to introduce a new constructor ExceptT on the same pattern as
>> >>> ReaderT,
>> >>> etc, and to deprecate ErrorT, and that's what I intend to include in
>> >>> the
>> >>> next major release, after GHC 7.8 comes out.
>> >>
>> >> First of all, GHC 7.8 is well past. Now we are well into the 7.10 zone.
>> >>
>> >> I re-read the original thread and did not find anyone who disagreed
>> >> with
>> >> this, so I'm not sure what you mean by that.
>> >>
>> >> I also didn't find any mention of ExceptT there. The discussion was
>> >> about
>> >> merging the either library into transformers as is, with the bits that
>> >> are problematic due to non-base dependencies written out by hand
>> >> where possible or else omitted.
>> >>
>> >> That said, I think everyone will support you, without bikeshedding, if
>> >> you decide to change any of the names and/or deprecate ErrorT.
>> >>
>> >> Thanks,
>> >> Yitz
>> >>
>> >
>
>