Proposal to solve the `EitherT` problem.

[Dan Burton]

There is a lot of inertia for the convention to right-bias Either in
Haskell. The Monad instance on Either is not going away anytime soon, so I
think it only appropriate to have "EitherT" as its natural extension into
transformer-land. Now if we *also* want to have an isomorphic type, for
example ExceptionT e a = Exception e | NoExceptions a, and tell people that
it is best practice to use *this* for error-handling code, then I see no
problem with that. You could put something in the haddocks of EitherT about
how exception-based programming should really be done with ExceptionT
instead. But for discoverability's sake, for consistency's sake, I think
that transformers is incomplete without EitherT.

The day Either loses its Monad instance, we can also throw away EitherT.


-- Dan Burton


On Wed, Aug 14, 2013 at 8:43 AM, Gabriel Gonzalez <gabriel439 at gmail.com>wrote:

>  I echo Edward's sentiments.  If you disagree with Edward's design
> choices then you should vote with your code instead of your +1's by
> building and actively maintaining libraries that uphold your design
> principles.
>
> I see all these hypothetical arguments that `Either` might cause somebody
> to accidentally use its monad instance once, ever, but let's consult the
> facts:
>
> * Nobody here has even lifted a finger to write up a library with this
> hypothetical alternative to the `Either` without the `Monad` instance.
> This signals to me that the people arguing for removing the `Monad`
> instance don't actually care about this as much about this as they say they
> do.
>
> * Nobody has ever come onto Haskell cafe, Stack Overflow, or /r/haskell
> and asked: "Where can I find an `Either` without the `Monad` instance?"
> This signals to me that most Haskell programmers don't actually want this
> "feature" as much as you say they do.
>
> * Lots of Haskell programmers use Either and EitherT fluently for error
> handling without any confusion or programming mistakes.  My `errors`
> library is proof of that:
>
> http://packdeps.haskellers.com/reverse/errors
>
> The reason Edward's libraries are popular and so widely used is because
> they solve an *actual* need, not a hypothetical need.
>
>
> On 08/14/2013 07:51 AM, Edward Kmett wrote:
>
>  Like Maybe, Either has perfectly unambiguous semantics as a Monad as
> well.
>
>  It is only when you muddle the waters with this fail nonsense that you
> need to choose between the Either monad and the Error monad. Error and
> Either would be indistinguishable otherwise.
>
>  Re: unfair. I tried to take the sting out of it with a ";)" as I was
> really just trying to use it to indicate that the 'consistency with the
> rest of transformers' ship had sailed given that MaybeT exists and is
> within transformers.
>
>  I was trying to fire off one last shot across the bow that in the big
> 2.0 switch there was a move to make "State s" be "StateT s Identity" that
> was mostly argued for code reuse and simplification reasons, that it cut
> code duplication by a factor of 2 in the body of transformers and the mtl
> and reduced the chance for human error.
>
>  The fact that State s = StateT s Identity rather than merely being
> isomorphic seems to me to be an emergent property of this change, not its
> purpose.
>
>  Ultimately, transformers is Ross's package, and the while maintainers
> can poll and ask questions of the community and take the temperature of the
> room it is fully his decision about how to move forward. Whatever he
> decides goes.
>
>  I'm just vociferously advocating for the least painful transition for me
> personally and tend to favor the "don't rebikeshed" solution over making
> changes for cosmetic reasons, because every single one of these "lets
> standardize something from one of my packages but randomly rename it"
> proposals induces a lot of accumulated work for me.
>
>  I have come somewhat to dread the inevitable discussion when someone
> pops up on the mailing list here asking to standardize something from one
> of my packages. It seems it inevitably loses features, gets bikeshedded or
> otherwise broken in such a way that creates work for me and others. I still
> want to help with getting things out to a larger audience, but I prefer to
> do so in a way that doesn't break code gratuitously, or worse force users
> into a choice between the old and the new. However, that is wandering quite
> a bit off topic.
>
>  -Edward
>
>
>
> On Wed, Aug 14, 2013 at 3:42 AM, Daniel Trstenjak <
> daniel.trstenjak at gmail.com> wrote:
>
>>
>> On Tue, Aug 13, 2013 at 06:57:22PM -0400, Edward A Kmett wrote:
>> > I look forward to finding out the new name for MaybeT then. ;)
>>
>>  That's a bit unfair, because the Maybe data type has a clear meaning
>> which also holds for its Monad instance.
>>
>> That's not the case for Either. The Either data type doesn't propose
>> a special meaning to the 'Left' or 'Right' case, but the Monad
>> instance of Either does.
>>
>> Isn't just having a discussion about such a contradiction at the end
>> the reason why Haskell is the language it is?
>>
>>
>> Greetings,
>> Daniel
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
>
> _______________________________________________
> Libraries mailing listLibraries at haskell.orghttp://www.haskell.org/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130814/5d4caf44/attachment.htm>