mgsloan / store

Fast binary serialization in Haskell
MIT License
109 stars 35 forks source link

compile time build failure of store v0.5.1 with ghc 7.10 and 7.8 #140

Closed cartazio closed 5 years ago

cartazio commented 5 years ago

Hello: is ghc 7.10 or 7.8 acutally part of the target support range or not?

https://matrix.hackage.haskell.org/#/package/store/0.5.1.0/ghc-7.10.3@1556132737 shows the build failures that happpen on those ghc versions.

the error in the matrixci builder tool is

src/Data/Store/Internal.hs:697:5:
    The exact Name ‘a_aO3e’ is not in scope
      Probable cause: you used a unique Template Haskell name (NameU), 
      perhaps via newName, but did not bind it
      If that's it, then -ddump-splices might be useful
    In the splice:
      $(derive
          [d| instance Deriving (Store All)
              instance Deriving (Store Any)
              instance Deriving (Store Void)
              instance Deriving (Store Bool)
              instance (Store a, Store b) => Deriving (Store (Either a b)) |])

src/Data/Store/Internal.hs:697:5:
    The exact Name ‘b_aO3f’ is not in scope
      Probable cause: you used a unique Template Haskell name (NameU), 
      perhaps via newName, but did not bind it
      If that's it, then -ddump-splices might be useful
    In the splice:
      $(derive
          [d| instance Deriving (Store All)
              instance Deriving (Store Any)
              instance Deriving (Store Void)
              instance Deriving (Store Bool)
              instance (Store a, Store b) => Der

one fix would be to add the constraint template-haskell > = 2.11 if 7.10 and older is no longer supported. If you intend to continue supporting those ghc versions, perhaps theres a more involved fix?

but pending that more involved fix, adding template-haskell > = 2.11 seems like a good way to roll

mgsloan commented 5 years ago

Hey Carter, thanks for reporting this issue. It looks like old TH treats type variables in expression signatures a bit funny, and expects to be able to look them up in the local scope.

I've worked around this by replacing type variables with Any when resolving derivers / instantiators. This fix is included in th-utilities-0.2.3.0, no changes to store needed.