Proposal to solve the `EitherT` problem.

Henning Thielemann schlepptop at
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 mailing list