Skip to content

Adapt to MonadFail changes in GHC 8.8. #516

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

Merged
merged 1 commit into from
Jan 14, 2020

Conversation

quasicomputational
Copy link
Contributor

Note that this is an enforced public API change.

I went with changing the MonadFile typeclass rather than threading
through a MonadFail at every use-site, but that would be possible as
well if it makes more semantic sense - however, since MonadFile
already seems to require an IO-ish implementation, adding that
superclass doesn't seem like an imposition.

@Anton-Latukha
Copy link
Collaborator

Migration is probably widely known.

Citing release docs:

The fail method of Monad has been removed in favor of the method of the same name in the MonadFail class.

MonadFail(..) is now exported from the Prelude and Control.Monad modules.
The MonadFailDesugaring language extension is now deprecated, as its effects are
always enabled.

Link: https://gitlab.haskell.org/ghc/ghc/wikis/migration/8.8#base-41300
Proposal: https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail

I'm writing error-handling PR, so, looked at code, and 👍

@Anton-Latukha
Copy link
Collaborator

Anton-Latukha commented Sep 30, 2019

Travis timed-out due to your commit got into timing of compiling Cabal & such.

If you want - you can re-push this change, so Travis compiles it.

@domenkozar domenkozar requested a review from jwiegley October 1, 2019 07:34
@jwiegley
Copy link
Member

jwiegley commented Oct 1, 2019

I restarted the builds.

Note that this is an enforced public API change.

I went with changing the `MonadFile` typeclass rather than threading
through a `MonadFail` at every use-site, but that would be possible as
well if it makes more semantic sense - however, since `MonadFile`
already seems to require an IO-ish implementation, adding that
superclass doesn't seem like an imposition.
@quasicomputational
Copy link
Contributor Author

I've given it another kick; let's see if the cache is full enough for it to complete now...

@quasicomputational
Copy link
Contributor Author

Doesn't seem like the cache is warming up at all. Cabal keeps getting rebuilt each try. I thought cachix would passively upload artifacts for later re-use?

@vaibhavsagar
Copy link
Collaborator

I think cachix only uploads after a build succeeds, so we would need to upload a built Cabal out-of-band to get past that issue.

@jwiegley
Copy link
Member

jwiegley commented Oct 2, 2019

Trying to build and upload to cachix now.

@jwiegley
Copy link
Member

jwiegley commented Oct 3, 2019

I'm having all kinds of problems building this branch...

@sjakobi
Copy link
Member

sjakobi commented Oct 18, 2019

Note that this branch doesn't currently build with cabal because regex-tdfa-text still needs a release compatible with GHC-8.8. See hackage-trustees/regex-tdfa-text#3.

EDIT: It now seems that regex-tdfa-text will not be updated, and that instead regex-tdfa will gain support for Text: haskell-hvr/regex-tdfa#4

@sjakobi
Copy link
Member

sjakobi commented Oct 23, 2019

I think it might be a good idea to include these changes in the upcoming release, even if real GHC-8.8 support is still blocked by regex-tdfa[-text].

Users who don't mind depending on this fork could then still easily compile with GHC-8.8. Users of GHC-8.4 and 8.6 don't lose anything.

@jwiegley
Copy link
Member

I just need to find time then to reproduce this build and make sure it works for me before uploading.

@jwiegley jwiegley merged commit 37c2bb2 into haskell-nix:master Jan 14, 2020
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.

5 participants