GHC 8 Support

[xich]

Just so no one else wastes the time, I'm pretty far along on updating HERMIT to build with GHC 8 RC1, and plan to finish it up tonight.

[xich]

Well, I think I'm past all the hard stuff, but its taking longer than expected, so probably another day.

[RyanGlScott]

It just hit me that I promised Neil a while back that I'd update HERMIT to use kure-3.0, but time got away from me :(

Are you updating to kure-3.0 on the way?

[xich]

Not in this diff... I figure that will be pretty major in itself. I can have a go at it though.

[xich]

Just pushed da8af6bd50f58140d30f6ca1af809c7b3aac12fa, which makes HERMIT compile with GHC 8. This is not the whole story. (There are TODOs in the commit message, which I plan to address this weekend or next week.)

Also, the only remaining dependency to sort out is the exceptions package. I installed a custom one with bounds on transformers and template-haskell bumped to < 0.6 and < 2.12 respectively.

[xich]

Oh wait, new exceptions got released today, but I think with a too-tight bound on transformers-compat. Anyway, hopefully all this gets sussed out in the next few days and travis can start building for us.

[RyanGlScott]

More bookkeeping: there was talk earlier of replacing marked-pretty with the new annotated version (1.1.3+) of pretty that comes bundled with GHC 8.0. I don't know if we want to do this now and use marked-pretty as a fallback, or if we want to wait until only GHC 8.0+ is supported. This comment provides a sketch of the changes needed.

[xich]

I think we should just wait until we drop 7.10 support before we move over to pretty.

[conal]

I'm trying to track down what I think is a GHC bug, so I'm installing GHC HEAD from Git sources. I get the following error message when compiling a freshly git-pulled HERMIT:

src/HERMIT/External.hs:60:45: error:
    Module 'Data.Typeable.Internal’ does not export 'funTc’

[xich]

@conal Richard renamed that to tcFun in https://github.com/ghc/ghc/commit/6746549772c5cc0ac66c0fce562f297f4d4b80a2

Best fix would be to move that import to HERMIT.GHC, CPP wrap it to get both versions, then define funTc = Data.Typeable.Internal.funTc or funTc = Data.Typeable.Internal.tcFun in HERMIT.GHC and export that to HERMIT.External. We try to use HERMIT.GHC to provide a consistent API across GHC versions, so we don't have to add CPP through the codebase.

[conal]

@xich Sounds good. I think it'll be a little more involved, since tcFun isn't exported. I think we can rebuild it with exported interfaces. I'm happy to give it a shot now. Should I wrap with #if __GLASGOW_HASKELL__ > 710?

[conal]

Oh, and maybe we'd rather use the more modern name, tcFun, with the intent to drop the CPP wrapping and use the Data.Typeable.Internal version directly at some point. Thoughts?

[conal]

I made the changes, using the older name "funTc" for now. Included in my pull request #172 . I didn't intend to combine pull requests. I guess I don't understand how to keep them separate.

[xich]

Ah, if it is not exported, let's just create our own:

tcFun = typeRepTyCon (typeRep (Proxy :: Proxy (Int -> Int)))

Has the added benefit of not needing the Internal module at all. All that stuff is in Data.Typeable.

[xich]

Also might not even need CPP with that definition.

[conal]

Good idea. I'll change it and re-push.

[conal]

When I give that tcFun definition type TyCon, I get an error (with GHC 7.10.3):

Couldn't match expected type ‘TyCon’
            with actual type ‘Data.Typeable.Internal.TyCon’
NB: ‘TyCon’ is defined in ‘TyCon’ in package ‘ghc-7.10.3’
    ‘Data.Typeable.Internal.TyCon’
      is defined in ‘Data.Typeable.Internal’ in package ‘base-4.8.2.0’

Instead, I'm using type Data.Typeable.Internal.TyCon. Do you know what's going on here?

[conal]

Okay. Updated pull request #172.

[xich]

Yeah, GHC has it's own TyCon type, which is different than the TyCon type in Data.Typeable... hence the error.

I'll comment on the pull request.

[conal]

Oh! Thanks for the explanation.