Proposal to solve the `EitherT` problem.
schlepptop at henning-thielemann.de
Wed Aug 14 10:56:01 CEST 2013
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.
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.
More information about the Libraries