Closed RyanGlScott closed 5 years ago
@RyanGlScott this would probably be nice to have. Is there any reason not to?
The only downside is that we'd have to add another library dependency to transformers-compat
, which is itself pretty low on the dependency chain. As I mention in https://github.com/ekmett/transformers-compat/issues/40#issue-424537624, I think it would be worth it in the end, since fail
is itself extremely lightweight and would only need to be depended upon if one uses a version of GHC older than 8.0.
I have no objection to picking up a dependency on fail
.
While upgrading some libraries to support
base-4.13
, wherefail
is now exclusively a method ofMonadFail
, I attempted to change someMonad
constraints toMonadFail
to make the API consistent across all versions of GHC. Alas, this caused the code to no longer compile on pre-8.0 versions of GHC, since I later instantiated those functions at monad transformer types likeReaderT
,IdentityT
, etc., and thefail
compatibility package does not defineMonadFail
instances for those types. Unfortunately, this leaves me in a bit of a rut.I talked with @hvr about this at one point, and he was hesitant to add orphan
MonadFail
instances tofail
so as to keep the package as minimal as possible. This is a reasonable request, but it leaves the Haskell ecosystem without a canonical source for these useful orphan instances.Since
transformers-compat
already provides an orphan instances module (inControl.Monad.Trans.Instances
), I propose that we simply add the orphanMonadFail
instances there. This has one drawback in that we will have to incur a dependency on thefail
package on pre-8.0 GHCs, but I think the payoff would be worth it. Plus, there is already precedent for doing this, sincetransformers-compat
already depends onmtl
, another lightweight package.