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.