Proposal to solve the `EitherT` problem.

[Gabriel Gonzalez]

On 08/14/2013 01:56 AM, Henning Thielemann wrote:
> Am 13.08.2013 23:18, schrieb MightyByte:
>
>> For me, the name EitherT wins by a large margin.  Way back when I
>> first learned about MaybeT, it totally rocked my world.  I had been
>> plagued for quite some time by the problems that MaybeT addresses but
>> didn't know of the solution.  I had already seen things like ReaderT
>> and StateT, but for some reason I hadn't yet made the connection to
>> how the idea would carry over to the Maybe monad.  After I learned
>> about MaybeT, EitherT was the natural name I expected.  If EitherT had
>> been in transformers, I think I would have used it even sooner.
>>
>> I think the discoverability of the name EitherT is huge win given the
>> existing conventions.  I think I had even seen ErrorT before MaybeT,
>> but the name obscured its significance for me.
>
> 1. You discovered Either as a monad first, which I think is the 
> initial problem. Either should never have been abused for exception 
> handling and it should never have been a monad. If Either would not be 
> a monad then no-one would look for EitherT.
>

If you care about this so much you are free to define your own `Either` 
alternative without a `Monad` instance.  You can call it `Union` and 
release it in a `union` package and program with it all you want.

However, I don't support this notion of fragmenting the ecosystem in 
search of the perfect nomenclature when the `Either` one has served us 
so well for so long.  This whole `ExceptT` thing sounds like a solution 
in search of a problem.  I've never heard of somebody that got bitten by 
`Either` having a `Monad` instance.

While we're at it, why don't we remove the default `Num` instance for 
`Integer`s?  I have some project where I use numbers as labels and 
addition breaks the type safety of my labels, therefore the `Num` 
instance is an abuse of `Integer`s.

That might sound ridiculous because I can *obviously* newtype `Integer`s 
to remove the `Num` instance for `Integer`s, just like you can obviously 
newtype `Either` to remove the `Monad` instance if you really feel 
strongly that it's an abuse within the context of your project.  
However, I think most people will agree that the appropriate default 
should be supply a `Monad` instance and opt out as necessary, rather 
than opt in.

> 2. Now since Either is a monad and people are looking for EitherT, it 
> would be simple to note that in the documentation of ExceptT. One 
> could even upload a new version of "EitherT" and "either" packages 
> that redirects people to ExceptT.
>

We don't want to use `EitherT` solely for error handling.  There are 
other legitimate uses of an `Either` monad other than error handling, 
like short-circuiting, which is why it does not make sense to link those 
packages to `ExceptT`.  I can't tell you how many times the `EitherT` 
`Monad` and `Alternative` instances have done the right thing in 
contexts that have nothing to do with errors, such as in conjunction 
with the `lens` package.  The people in favor of `ExceptT` have a very 
narrow view that the only legitimate use of the `Monad` instance is 
error handling, which is simply not true.