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

Fixing build with MonadFailDesugaring #80

Merged
merged 3 commits into from
Nov 13, 2018
Merged

Conversation

recursion-ninja
Copy link
Contributor

This resolves #79.

I had to use CPP for conditional imports and constraints, which is ugly, but not too intrusive.

.travis.yml Outdated
@@ -38,6 +38,15 @@ matrix:
- env: CABALVER=1.24 GHCVER=8.0.1
compiler: ": #GHC 8.0.1"
addons: {apt: {packages: [cabal-install-1.24,ghc-8.0.1], sources: [hvr-ghc]}}
- env: CABALVER=1.24 GHCVER=8.2.2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add these into the .cabal file as well please?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added these to to the tested-with field of fgl.cabal.

@@ -1,3 +1,4 @@
{-# LANGUAGE CPP #-}
Copy link
Contributor

@ivan-m ivan-m Aug 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please merge this into the next line:

{-# LANGUAGE CPP, MultiParamTypeClasses #-}

@@ -39,7 +44,11 @@ import Data.Graph.Inductive.Graph

-- Monadic Graph
--
#if MIN_VERSION_base(4,12,0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One way to make this a little less intrusive is to have something like:

class
#if MIN_VERSION_base(4,12,0)
  (MonadFail m)
#else
  (Monad m)
#endif
  => GraphM m gr where

The advantage of this approach is that you can ensure that GraphM is defined regardless in the same way, just that the constraint differs.

@ivan-m
Copy link
Contributor

ivan-m commented Aug 21, 2018

I don't mind CPP; I've had to use it enough times myself :/

If nothing else, this PR has also pointed out to me that I may need to re-implement the benchmarks away from microbench as it hasn't been touched in 10 years and looks like it won't work with 8.8 :(

@recursion-ninja
Copy link
Contributor Author

I try to avoid CPP if I can and like to let people know when I've added it.

I applied your code review suggestions and squashed the commits.

@recursion-ninja
Copy link
Contributor Author

Should be ready to merge.

@peti
Copy link

peti commented Sep 27, 2018

Ping?

@ivan-m
Copy link
Contributor

ivan-m commented Sep 27, 2018 via email

.travis.yml Outdated
addons: {apt: {packages: [cabal-install-1.24,ghc-8.4.3], sources: [hvr-ghc]}}
- env: CABALVER=1.24 GHCVER=8.6.1
compiler: ": #GHC 8.6.1"
addons: {apt: {packages: [cabal-install-1.24,ghc-8.6.1], sources: [hvr-ghc]}}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please use cabal-install-2.4 for GHC-8.6.1, 2.2 for 8.4, 2.0 for 8.2. Otherwise things may fail.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have updated the cabal versions to match the newer ghc versions.

@@ -19,6 +19,10 @@ module Data.Graph.Inductive.Monad(


import Data.Graph.Inductive.Graph
#if MIN_VERSION_base(4,12,0)
import Control.Monad.Fail
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

recommended way is to depend on fail package, then you can provide uniform interface across different GHC versions


In general https://ghc.haskell.org/trac/ghc/wiki/Migration/8.6 and other migration guides are good reads.


Note that changing context of a class is breaking change, requiring a major bump to fgl-5.7

Copy link
Contributor Author

@recursion-ninja recursion-ninja Sep 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are absolutely correct that this is a breaking change and I've bumped the version to fgl-5.7 to reflect that along with updating the changelog.

I was also unaware of the fail package. I'm happy to also update fgl to depend on the fail package and remove the CPP I had to add in lieu of that solution. However, I want to get feedback from @ivan-m to make sure that's their preferred way for fgl to support the MonadFail constraint on the GraphM typeclass.

@phadej
Copy link
Contributor

phadej commented Sep 30, 2018

@recursion-ninja if you think breaking change is better way, could you depend on fail to provide uniform API.

It would be very surprising for downstream if when upgrading to GHC-8.6 they need to write MonadFail instance for their monad (if someone is so silly that doesn't use IO or ST directly).

@ivan-m
Copy link
Contributor

ivan-m commented Sep 30, 2018

I prefer to keep FGL depending solely on boot packages.

@recursion-ninja
Copy link
Contributor Author

@ivan-m, so we'll stick with the CPP and not depend on the fail package.

Since that's the case, this should be ready to merge.

@recursion-ninja
Copy link
Contributor Author

Is there a time line for merging this? I'd like it to be able to use the fgl and libraries that transitively depend of fgl with GHC-8.6.1. Is there anything else required for this to be merged?

@martijnbastiaan
Copy link

@recursion-ninja as a temporary workaround you could use:

source-repository-package
  type: git
  location: https://github.com/recursion-ninja/fgl.git
  tag: d49cd7b0cd766d9f4647e140e263de1b94ace0c5

in your cabal.project. I believe this only works if you're already using new-*, though. I've tested this for https://github.com/clash-lang/clash-compiler/ which seems to work fine. It would be great if this patch could be merged soon though!

@recursion-ninja
Copy link
Contributor Author

@martijnbastiaan that is a nice, temporary solution. However, this pull request should be merged and a new version of fglupload sooner rather than later.

@peti
Copy link

peti commented Nov 8, 2018

Does someone have the time to initiate a non-maintainer upload request as per https://wiki.haskell.org/Hackage_trustees?

@ivan-m
Copy link
Contributor

ivan-m commented Nov 8, 2018

Sorry, this slipped my mind; I'll do it this weekend.

@ivan-m ivan-m merged commit 4381a44 into haskell:master Nov 13, 2018
@ivan-m
Copy link
Contributor

ivan-m commented Nov 13, 2018

I'm not sure why Travis-CI didn't catch this, but this actually fails with cabal-install-2.4 due to the deprecation of cabal install.

grumbles

@phadej
Copy link
Contributor

phadej commented Nov 13, 2018 via email

@ivan-m
Copy link
Contributor

ivan-m commented Nov 14, 2018

Sorry, you're right; I fail at reading error messages.

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.

FLG doesn't build with MonadFailDesugaring
5 participants