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
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
Hi Simon,
On Sat, Feb 9, 2013 at 12:18 AM, Simon Peyton-Jones
** **
Yes do point me to where the check for deriving(Typeable) is awkard to test against AutoDeriveTypeable.
I add the instances in line 319 of TcDeriv. It's easy to add them here, because I just need to produce a simple DerivDecl. However, checking if there are instances defined already is cumbersome, because I'd have to look at both the inst_decls and the deriv_decls, while being careful to keep duplicates, because those are "real" errors. In general, I find it hard to extract the class and type from an InstDecl or a DerivDecl, because these are just HsTypes in the end, so I'd have to go deconstruct the HsType and hope it would have the right shape. But maybe there are some auxiliary functions that I missed? Thanks, Pedro
I'd instead do it in makeDerivSpecs
· Make the EarlyDerivSpecs as now (eqns1,2,3)
· You can easily extract which ones are for Typeable via the ds_cls field. No fancy decomposition required
· Generate more EarlyDerivSpecs for the extra Typeable instacnes you want
S
From: josepedromagalhaes@gmail.com [mailto:josepedromagalhaes@gmail.com] On Behalf Of José Pedro Magalhães
Sent: 13 February 2013 10:56
To: Simon Peyton-Jones
Cc: ghc-devs@haskell.org
Subject: Re: Merging polykinded typeable
Hi Simon,
On Sat, Feb 9, 2013 at 12:18 AM, Simon Peyton-Jones
participants (2)
-
José Pedro Magalhães -
Simon Peyton-Jones