llvm-general-pure doesn't compile with GHC 8.0

[crockeea]

src/LLVM/General/Internal/PrettyPrint.hs:166:19: error:
    • The constructor ‘DataD’ should have 6 arguments, but has been given 5
    • In the pattern: DataD _ _ tvb cons _
      In the pattern: TyConI (DataD _ _ tvb cons _)
      In a case alternative: TyConI (DataD _ _ tvb cons _) -> (tvb, cons)

src/LLVM/General/Internal/PrettyPrint.hs:171:3: error:
    • Ambiguous type variable ‘m0’ arising from a use of ‘sequence’
      prevents the constraint ‘(Monad m0)’ from being solved.
      Probable fix: use a type annotation to specify what ‘m0’ should be.
      These potential instances exist:
        instance Monad m => Monad (WrappedMonad m)
          -- Defined in ‘Control.Applicative’
        instance Monad (Either e) -- Defined in ‘Data.Either’
        instance Monad Dual -- Defined in ‘Data.Monoid’
        ...plus 10 others
        ...plus 27 instances involving out-of-scope types
        (use -fprint-potential-instances to see them all)
    • In the first argument of ‘(.)’, namely ‘sequence’
      In the expression: sequence . return
      In a stmt of a 'do' block:
        sequence . return
        $ instanceD
            (cxt [appT (conT (mkName "PrettyShow")) cv | cv <- cvs])
            [t| PrettyShow $(foldl appT (conT n) cvs) |]
            pending(rn) [<splice, foldl appT (conT n) cvs>]
            [funD
               (mkName "prettyShow")
               [clause
                  [...]
                  (normalB $ caseE (dyn "a") $ flip map cons $ \ con -> ...)
                  []]]

src/LLVM/General/Internal/PrettyPrint.hs:171:14: error:
    • Ambiguous type variable ‘t0’ arising from a use of ‘return’
      prevents the constraint ‘(Monad t0)’ from being solved.
      Probable fix: use a type annotation to specify what ‘t0’ should be.
      These potential instances exist:
        instance Monad m => Monad (WrappedMonad m)
          -- Defined in ‘Control.Applicative’
        instance Monad (Either e) -- Defined in ‘Data.Either’
        instance Monad Dual -- Defined in ‘Data.Monoid’
        ...plus 10 others
        ...plus 27 instances involving out-of-scope types
        (use -fprint-potential-instances to see them all)
    • In the second argument of ‘(.)’, namely ‘return’
      In the expression: sequence . return
      In a stmt of a 'do' block:
        sequence . return
        $ instanceD
            (cxt [appT (conT (mkName "PrettyShow")) cv | cv <- cvs])
            [t| PrettyShow $(foldl appT (conT n) cvs) |]
            pending(rn) [<splice, foldl appT (conT n) cvs>]
            [funD
               (mkName "prettyShow")
               [clause
                  [...]
                  (normalB $ caseE (dyn "a") $ flip map cons $ \ con -> ...)
                  []]]

src/LLVM/General/Internal/PrettyPrint.hs:192:18: error:
    • The constructor ‘DataConI’ should have 3 arguments, but has been given 4
    • In the pattern: DataConI _ _ _ (Fixity prec _)
      In a stmt of a 'do' block:
        DataConI _ _ _ (Fixity prec _) <- reify conName
      In the expression:
        do { DataConI _ _ _ (Fixity prec _) <- reify conName;
             let ns = ...;
             [p0, p1] <- mapM (const $ newName "f") ns;
             let ss = ...;
             .... }

At least two of these problems are due to changes in template-haskell. The latest Hackage release (3.5.10.0) claims to support base < 5, but the correct upper bound is base < 4.9. A new version should be released that does support base == 4.9.

[lialan]

The template-haskell change is slight, they can be found here:
https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0#template-haskell-2.11.0.0

I made an workaround for this, which can compile on both 7.10.3 and 8.0. Not sure if it is a good way to patch tho.

You can find the workaround at: https://gist.github.com/lialan/9173926b0b2f60dbb52774bf96531620

@bscarlet Hi Ben, do you have a plan for fixing this issue? lens is broken on Ubuntu 16.04 with ghc 7.10.3, and it makes things quite ugly... Would like to resolve it if it is possible.

[bscarlet]

I just haven't had time. Unfortunately I'm also going on vacation, off the grid, for the next two weeks.

[rikusalminen]

I encountered this same issue. @lialan 's Gist patch solves the problem.

[remexre]

Will this be fixed in the near future?

[cocreature]

It’s fixed in the llvm-3.8 branch and there is an (umerged) PR for 3.5

[remexre]

I'm rather new to the Haskell tools and language, so sorry if this is obvious, but how do I instruct cabal to use that branch?

[cocreature]

Just clone the repo, switch to the llvm-3.8 branch (note that you need LLVM-3.8 for this to work) and then run cabal install /path/to/llvm-general-pure and cabal install /path/to/llvm-general. If you are using a sandbox make sure you run these commands from the directory where your sandbox is located.

[remexre]

So it doesn't work with the "normal" cabal install though, right? Thanks!

[cocreature]

Not sure what you are referring to by normal cabal install. Afaik there is only one and that’s exactly the one you need here. If you are asking whether you have to use a sandbox, the answer is no. Just run the cabal install commands and you should be all set.

[remexre]

I meant cabal install <package-name>, where it downloads it from the web. I'm used to pip, npm, etc. where the tool automates the pull step for you, but if I need to do it myself here, it's not a big problem.

[cocreature]

That doesn’t work because the version with GHC-8 support has not yet been released to hackage.

[tibbe]

Could we please have a release including this fix?

[shockkolate]

A hackage release would be very useful for me also.

[yigitozkavci]

So, still no fix?

[RyanGlScott]

@yigitozkavci, this package has pretty much ceased active development. I recommend using llvm-hs, a fork of this project which is actively maintained.

[yigitozkavci]

@RyanGlScott It looks awesome, thanks for the suggestion. I'll definitely give it a try.