Proposal to solve the `EitherT` problem.

Ross Paterson R.Paterson at
Mon Jun 17 02:32:29 CEST 2013

On Sun, Jun 16, 2013 at 02:52:46PM -0700, Gabriel Gonzalez wrote:
> There are three approaches that I'd like to submit for consideration
> and receive feedback on:
> * Approach 1: Remove the `Error` constraint from `transformers`
> Disadvantage: This silently breaks all existing uses of `fail`.  I
> don't know any way to add a compiler warning to notify downstream
> libraries of this change.

I'm in favour of this one.  We can catch some of these uses by deprecating
the Error class, as the only predefined instances are for IOException
and String.

> * Approach 2: Add `EitherT` to `transformers` alongside `ErrorT` and
> have them both implement `MonadError`.
> Disadvantage: Bloat from having two almost identical monad
> transformers.  However, there is precedent from duplicating
> `StateT`, `WriterT` and `RWST` for both strict and lazy instances.

Those is at least a rationale for two StateT transformers with strict
and lazy instances.  (Since the strict WriterT doesn't achieve its aim,
I'm in favour of deprecating it, and the strict RWST.)

More information about the Libraries mailing list