Opened 4 years ago

Closed 3 years ago

#10755 closed task (fixed)

Add `MonadPlus IO` and `Alternative IO` instances

Reported by: hvr Owned by:
Priority: normal Milestone: 8.0.1
Component: Core Libraries Version:
Keywords: report-impact Cc: simonpj, hvr, ekmett, core-libraries-committee@…, bergmark, ross
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D1148
Wiki Page:

Description

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.

Change History (13)

comment:1 Changed 4 years ago by hvr

Differential Rev(s): Phab:D1148
Status: newpatch

comment:2 Changed 4 years ago by RyanGlScott

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

comment:3 in reply to:  2 Changed 4 years ago by 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... :-/

comment:4 Changed 4 years ago by 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.

comment:5 Changed 4 years ago by 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.

comment:6 in reply to:  5 Changed 4 years ago by 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...).

Last edited 4 years ago by hvr (previous) (diff)

comment:7 Changed 4 years ago by bergmark

Cc: bergmark added

comment:8 Changed 4 years ago by 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.

comment:9 Changed 4 years ago by RyanGlScott

Cc: ross added

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?

comment:10 Changed 3 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:11 Changed 3 years ago by 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.

comment:12 Changed 3 years ago by 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

comment:13 Changed 3 years ago by bgamari

Resolution: fixed
Status: patchclosed

This is done.

Note: See TracTickets for help on using tickets.