Pedro Yes, go ahead and merge. In your blog post you say class Typeable (a :: k) where typeRep :: Proxy (a :: k) -> TypeRep but isn't it this? forall proxy. proxy a -> TypeRep Also you speak about Typeable for classes but it badly needs an example. I'd put the AutoDeriveTypeable thing under a fresh section heading. It's rather a separate question. Re Proxy, why not export it from Data.Typeable? As you say, it's useful, and that seems as good a home as any. Yes do point me to where the check for deriving(Typeable) is awkard to test against AutoDeriveTypeable. Thanks Simon From: josepedromagalhaes@gmail.com [mailto:josepedromagalhaes@gmail.com] On Behalf Of José Pedro Magalhães Sent: 08 February 2013 09:59 To: Simon Peyton-Jones Cc: ghc-devs@haskell.org Subject: Merging polykinded typeable Hi Simon, I think the polykinded stuff is now ready to merge. A few issues remain: 1) dynamic004 fails when run without optimisation (it times out). This is potentially worrying. It's doing a comparison of the typeReps of nested lists, up to 1000 nested lists. This worked fine before with -O0, but not anymore. With -O1 it works fine, though. Hopefully it's ok to just run this test with optimisation only, and assume that no one should expect great performance of Typeable on huge types with -O0... 2) With -XAutoDeriveTypeable, if you also derive Typeable instances in the module, you'll get a "duplicate instances" error. I think you'd rather have this be a warning, so that the semantics if -XAutoDeriveTypeable would be "derive Typeable for types/classes for which Typeable is not yet derived", instead of "derive Typeable for all types/classes declared". But I found this a bit tricky to check for, and as such haven't implemented it yet. I can point you to the place in the code where this is happening. 3) I don't know where to put `data Proxy t = Proxy`. I kind of need it for defining things in the library, but it doesn't need to be exported to the user, as we now have `typeRep :: forall proxy. proxy a -> TypeRep`. I do export it from Data.Typeable.Internal, because I want to use it in Data.Typeable, but I don't re-export it from Data.Typeable. This is, in principle, all fine, but I think that the Proxy datatype is so commonplace that it should probably be defined in GHC somewhere, so that it doesn't start showing up repeated in all sorts of libraries. Perhaps we can just put it in GHC.Exts? Either way, I'd like to merge this to the master branch now, and deal with the issues above after that. This is because it's tiresome to keep my branch up-to-date with master, and I don't think the remaining issues are blocking, or will affect the stability of the master branch. Regarding documentation, I've updated the user's guide to mention the new behaviour of Typeable, the fact that you can't define instances by hand, and the new flags (-XAutoDeriveTypeable and -fwarn-typeable-instances). I've written a blog post in the past about the new features (http://hauptwerk.blogspot.co.uk/2012/11/coming-soon-in-ghc-head-poly-kinded....), and I'll write another one about how to make sure your old Typeable code works in the new version. If you want to have a look at the code before merging, let me know, and I'll update the new-typeable branch. (I've stopped working on that branch, and now I have a local branch ready for merging with a single commit to master). Cheers, Pedro