Proposal to solve the `EitherT` problem.
gabriel439 at gmail.com
Sun Jun 16 23:52:46 CEST 2013
As an application writer I'm a big fan of Edward's `either` package
because his `EitherT` does not require an `Error` constraint. As a
library writer, I am wary of heavy dependencies and I would prefer
something more light-weight that I can depend on.
Normally I would just directly contact Edward about reducing the number
of dependencies but there was a previous discussion here about possibly
merging his work into `transformers`, so I'm renewing that discussion
and bringing up a few approaches for consideration.
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
* 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.
* Approach 3: Convince Edward to reduce the dependencies of the `either`
package and submit the simplified version to the Haskell platform.
Disadvantage: One extra import instead of just importing `transformers`.
* Approach 4: None of the above.
Disadvantage: Packages that depend on `either` have very low prospects
of making it into the Haskell platform.
If you have time, just take a moment to vote on which approach you favor
or propose another alternative if you have another idea that I haven't
More information about the Libraries