Proposal to solve the `EitherT` problem.
gabriel439 at gmail.com
Wed Aug 14 17:43:33 CEST 2013
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
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
* 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:
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
> 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.
> On Wed, Aug 14, 2013 at 3:42 AM, Daniel Trstenjak
> <daniel.trstenjak at gmail.com <mailto: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?
> Libraries mailing list
> Libraries at haskell.org <mailto:Libraries at haskell.org>
> Libraries mailing list
> Libraries at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries