Add `MonadPlus IO` and `Alternative IO` instances

[hvr]

Cloned and adapted from #9588:

---

The following 2 instances are currently Orphans in transformers but shall be defined in base instead:

instance MonadPlus IO
instance Alternative IO

This proposal by SPJ already passed the CLC back in April and only needs implementing. I'll submit a patch shortly to Phab

---

This needs coordination w/ Ross as transformers must not define the same instances for new enough base versions.

[RyanGlScott]

Note that the ​upstream version of transformers has already removed these orphan instances.

[hvr]

Replying to RyanGlScott:

Note that the ​upstream version of transformers has already removed these orphan instances.

Oh, didn't notice... however that implies a major version bump for the next transformers package. It'd better if transformers kept providing those orphan instances to smooth over the transition for already released package versions... let's hope this doesn't affect too many... :-/

[RyanGlScott]

If removing them from transformers causes too much heartburn, I'd be fine with asking Ross to put them back. My rationale when making that pull request was that putting orphan IO instances in a library about monad transformers didn't make much sense, and probably belong somewhere like base-orphans instead.

[bgamari]

+1 to putting these in base-orphans. It's unfortunate that people will need to update their dependency lists, but it seems like the right thing to do.

[hvr]

Replying to bgamari:

+1 to putting these in base-orphans. It's unfortunate that people will need to update their dependency lists, but it seems like the right thing to do.

Adding those to base-orphans is not the problem (and I'm +1 on that as well). The problem is with already released packages. Specifically, consider the following case:

• A package foo-0.1 relies on transformer >= 0.4 to supply the MonadPlus IO instance.
• Now a new transformers-0.5 is released which lacks the instance.
• So now foo-0.1 breaks when using base-4.8+transformers-0.5.
• base-4.9 would however have the instance again and foo-0.1 happens to compile again with base-4.9+transformers-0.5

Now in order to fixup this breakage would need to add upper bounds to the foo-0.1, but the problem is we can either

• add a transformers < 0.5 bound to foo-0.1, which would block out the sensible base-4.9+transformers-0.5 combination, or
• add a base >= 4.9 bound to foo-0.1, which block base-4.8+transformers-0.4.3 (and even worse, make this a GHC-7.12+ only package retroactively!)

What we would need to be able to do is to retrofit the constraint "base >= 4.9 || transformers < 0.5", but this requires cabal conditionals and automatic cabal flags, which can't be edited into a package retroactively (for good reason).

If this specific constellation affects a very small amount of packages*versions, we can handle it by a combination of cabal-edits and interacting w/ the authors to upload point releases. Otherwise we're faced with some kind of amputation-dilemma (not sure if there's a better term for it: i.e. when we need to amputate healthy install-plan-limbs in order to save the Hackage-patient...).

[ekmett]

I think the ideal situation would be to have transformers continue to export those instances conditional on the version of base.

This would ensure that the maximal number of versions of base work with the maximal number of versions of transformers, rather than inducing an unneeded gate function on what works with what.

These sorts of gotchas are the things that drive away users, so it is worth spending the time to get this right.

[RyanGlScott]

While I don't want to cause unnecessary pain for users, I have to wonder about the placement of the instances in transformers. Currebtly, they're located in Control.Monad.Trans.Error, which has been deprecated for a while. If users want to backport these new IO instances in their code, they'll have to reach for a module which GHC will warn is deprecated, which doesn't feel satisfying.

Perhaps we could move the orphan instances to a different module in transformers, reexport it from Control.Monad.Trans.Error, and tell users to use the new module from here on out for conpatibility purposes?

[thoughtpolice]

Milestone renamed

[RyanGlScott]

The orphan MonadPlus IO and Alternative IO instances are back in the upstream version of transformers (guarded by #ifdefs so that they won't be defined in GHC 7.11 and later), so that should no longer be an issue as far as this ticket is concerned.

[Austin Seipp <austin@…>]

In b62605e5/ghc:

Add `MonadPlus IO` and `Alternative IO` instances

This requires adding a new primitive `mplusIO` to `GHC.IO`

Update transformers submodule to accomodate extant orphan instances.

Reviewed By: austin, bgamari

Differential Revision: https://phabricator.haskell.org/D1148

GHC Trac Issues: #10755

[bgamari]

This is done.