Proposal to solve the `EitherT` problem.
gabriel439 at gmail.com
Wed Aug 14 17:03:34 CEST 2013
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.
More information about the Libraries