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 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

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 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 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 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