Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make MonadLogic instances compatible with logict-0.7.1.0 #13

Merged
merged 1 commit into from
Feb 24, 2021
Merged

Make MonadLogic instances compatible with logict-0.7.1.0 #13

merged 1 commit into from
Feb 24, 2021

Conversation

Bodigrim
Copy link
Contributor

The latest logict relaxes superclasses of MonadLogic. Previously it required MonadPlus (which in its turn requires both Monad and Alternative), but now it requires Monad and Alternative directly. Nevertheless, because of transformers requiring MonadPlus m even for Alternative (StateT t m), instances of MonadLogic for StateT now require an additional MonadPlus m constraint. Since IntBindingT is a newtype over StateT, its instances require a change as well.

@phadej
Copy link

phadej commented Jan 19, 2021

@Bodigrim could you make a revision to logict-0.5.1.0 which makes it uninstallable (EDIT: eg base <0).. (It should been 0.8.0.0). Deprecation is "to weak" to prohibit it popping in install plans.

EDIT: it would allow making proper revisions to existing releases unification-fd, i.e. logict <0.8.

@Bodigrim
Copy link
Contributor Author

It should been 0.8.0.0

Yes, my fault, this is why I deprecated it in 12 hours after release.

Deprecation is "to weak" to prohibit it popping in install plans.

It seems to be strong enough for cabal?.. I can force it using constraints, but it does not pick deprecated versions if it has any choice.

Stackage has already picked up logict-0.7.1.0 (even while is has been already deprecated by that moment) and already removed unification-fd. Adding an unbuildable revision would probably make things worse, because Stackage won't be able to update and will get stuck with an unrevised version, providing it to users and causing all sorts of confusion.

unification-fd will need a new release and revisions for older versions (because neither of them has upper bounds) anyways. And if one will be making revisions, it is safer to put logict < 0.7.1, so that no version of logict (e. g., stuck in any Stackage nightly) causes troubles.

(I'm actually unsure if this repo is maintained or monitored, it is not mentioned at https://hackage.haskell.org/package/unification-fd)

@phadej
Copy link

phadej commented Jan 19, 2021

It seems to be strong enough for cabal?.. I can force it using constraints, but it does not pick deprecated versions if it has any choice.

Yes, I argue there is no reason to give choice. Just pretend that release never happened/

EDIT: Re Stackage: Please make new release of lgoict to which Stackage can move, and then make a revision. Revisions don't affect existing snapshots, thus it should be fine.

@wrengr wrengr merged commit 34c2b8e into wrengr:master Feb 24, 2021
@wrengr
Copy link
Owner

wrengr commented Feb 24, 2021

I already pushed a version to Hackage with an upper bound to exclude logict-0.7.1 as a hotfix. But this is the better thing to do in the long run, so I'll shortly release another version that relaxes the upper bound again

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants