need to enable RankNTypes in Internal/DecodeAST.hs and Encode

[cartazio]

theres a breaking change in 7.8 wrt whats considered higher rank / impredicative types

src/LLVM/General/Internal/DecodeAST.hs:62:5:
    Illegal polymorphic or qualified type:
      forall r. (a -> IO r) -> IO r
    Perhaps you intended to use RankNTypes or Rank2Types
    In an expression type signature:
      forall (a :: *).
      (forall (r :: *). (a -> IO r) -> IO r) -> DecodeAST a
    In the expression:
        ghc-prim:GHC.Prim.coerce
          (anyContToM ::
             (forall (r :: *). (a -> IO r) -> IO r)
             -> AnyContT (StateT DecodeState IO) a) ::
          forall (a :: *).
          (forall (r :: *). (a -> IO r) -> IO r) -> DecodeAST a
    In an equation for ‛anyContToM’:
        anyContToM
          = ghc-prim:GHC.Prim.coerce
              (anyContToM ::
                 (forall (r :: *). (a -> IO r) -> IO r)
                 -> AnyContT (StateT DecodeState IO) a) ::
              forall (a :: *).
              (forall (r :: *). (a -> IO r) -> IO r) -> DecodeAST a

via enthropy on irc (im still sorting out mac related issues)

[aavogt]

Hi, I am enthropy. If I add RankNTypes, ImpredicativeTypes to DecodeAST and EncodeAST it compiles (provided I also use -fshared-llvm)

On the other hand my ghc is version 7.7.20140120

[cartazio]

(also @aavogt 's testing on linux, so he's not hitting any mac issues too)

[cartazio]

i'm using cabal 1.18 too

[bscarlet]

Does it really require ImpredicativeTypes? RankNTypes alone is not enough?

Is there a separate issue requiring "-fshared-llvm"?

[cartazio]

Yup, Both impredicative types AND rank n are needed. I tried sans impredicative. No go.

-fshared-llvm is needed to use llvm-general in ghci in 7.8. get linker errors and associated madness with the static linked version. see https://gist.github.com/cartazio/8744168

[cartazio]

i've opened a separate ticket for the shared-llvm issue

@aavogt did you get the linking error with compiled code or just using it in ghci?

[aavogt]

@cartazio the linking error was when building library itself (so I didn't explicitly call ghci, but maybe with the template-haskell used somewhere in the library it is practically involved?)

[cartazio]

so both! (ghci in 7.8 uses the system dylinker on x86/x86_64/ARM, and TH runs via ghci).

[bscarlet]

Can you offer any documentation on the change in 7.8? It looks like the central code causing the change is the stuff in AnyContT (under Control.Monad.AnyCont), which previously had RankNTypes. Why is ImpredicativeTypes now necessary, and why in modules using AnyCont rather than just in AnyCont?

[cartazio]

i'll test / report back in a day or so (if i don't, holler and i'll put at the top of my queue of tasks again)

[iainnicol]

@bscarlet, https://ghc.haskell.org/trac/ghc/ticket/8565 is plausibly related.

[cartazio]

yup! Thats the relevant GHC change i was thinking of. Thanks for digging that up @iainnicol :)

[cartazio]

ok, only ImpredicativeTypes is needed in the decode / encode modules. No need to add the rankN types flags therein

[cartazio]

hrmm, so based on the most recent comments on thist ticket https://ghc.haskell.org/trac/ghc/ticket/8631#comment:12, the type checker issue might be resolved on the GHC side for 7.8.

[goldfirere]

Yes, this triggered a regression in GHC 7.8. It's now fixed in HEAD, and it should be merged for the release of 7.8 -- you shouldn't need ImpredicativeTypes to compile the module.

[bscarlet]

Thank's for doing all the work! As it looks, this issue should be a non-issue before 7.8 is released, so I'm going to close it. Feel free to re-open it if necessary.