search

glaebhoerl / type-eq

Type equality evidence you can carry around
http://hackage.haskell.org/package/type-eq
Other
5 stars 2 forks source link

GHC 7.10 support #4

Closed bergmark closed 9 years ago

bergmark commented 9 years ago

Apart from bumping upper bounds, there's this build failure:

Type/Eq/Higher.hs:18:8:
    Could not find module ‘Data.OldTypeable’
    Perhaps you meant Data.Typeable (from base-4.8.0.0)
    Use -v to see a list of the files searched for.
glaebhoerl commented 9 years ago

Thanks for the report. Out of curiosity, do you happen to have any idea about what should happen to Type.Eq.Higher? Should I migrate it to use the new Data.Typeable? Kind of weird to have it use Data.OldTypeable in one version of GHC and Data.Typeable in another, but I don't know what would be less weird.

hesselink commented 9 years ago

@glaebhoerl There was a change to typeable in GHC 7.8. The Typeable module was changed, and the old version was renamed to Data.OldTypeable. That module was removed entirely in GHC 7.10. So it seems to me that to support GHC 7.10, you need to support the new typeable API. You can then use that for GHC 7.8 and 7.10. If you also want to support older GHCs, you can use CPP to use the old code for those, I guess.

glaebhoerl commented 9 years ago

@hesselink Yes, I know. I think I wrote this package at something like the worst imaginable point in time. For GHC 7.6 we had PolyKinds but the old mono-kinded Typeable, so the package used that, and provided Type.Eq.Higher for Typeable1 and 2. Then for GHC 7.8 it happened as you wrote, so I migrated Type.Eq.Higher to use OldTypeable and the rest to use the new Typeable. Now for 7.10 OldTypeable is gone and I frankly have no idea what to do with it. Part of me wants to just deprecate the package and tell people to migrate to the equivalent functionality in base, now that they provide it.

hesselink commented 9 years ago

@glaebhoerl Oh, then I misunderstood your question. I'm not familiar with the code in question at all, so I don't know how you should rewrite it for the new typeable specifically. @bergmark just pointed me here because he thought I knew about the problem in general. Sorry :(

hesselink commented 9 years ago

I just gave it a quick try, and it looks like the new typeable is backwards compatible. Just importing the new Data.Typeable and switching to explicit imports (since there are some more name clashes), and type-eq compiles. Let me know if you want me to clean it up and send a PR, or if you'll do it yourself (I don't have time now).

hesselink commented 9 years ago

I made a PR in case anyone wants the code: #5. It still has warnings, but otherwise works with GHC 7.4, 7.6, 7.8 and 7.10.

glaebhoerl commented 9 years ago

Thanks for doing this, and sorry for not being on top of things myself. Thinking about the 'right' way to expose the staggered compatibility breaks in GHC and base gives me a headache, but I think this should be fine (maybe it is the right way, if I were to think it through), and anyways, the package only has a single reverse dependency which uses a single function which is not even from the affected modules...

glaebhoerl commented 9 years ago

These represent breaking changes under GHC 7.8 so I bumped the version as well. Uploaded to Hackage also.

(At first I got:

This tarball is in the non-standard GNU tar format. For portability and long-term data preservation, hackage requires that package tarballs use the standard 'ustar' format. If you are using GNU tar, use --format=ustar to get the standard portable format.

which is peculiar considering that I just did runghc Setup.hs sdist. Google found nothing. Anyway, I solving it by unpacking and repacking with the flag.)

hesselink commented 9 years ago

Seems to be haskell/cabal#1901. Using cabal install should work, or you can install a newer version of the Cabal library since they fixed the bug.

glaebhoerl commented 9 years ago

Aha, thank you. :)

bergmark commented 9 years ago

Thanks guys!