Proposal to solve the `EitherT` problem.

[Dan Burton]

Whoops I got the "code" wrong for ExceptionT, but you get the idea.

-- Dan Burton


On Wed, Aug 14, 2013 at 10:14 AM, Dan Burton <danburton.email at gmail.com>wrote:

> 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/a4b5b131/attachment.htm>