Merging polykinded typeable

[Simon Peyton-Jones]

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 at gmail.com [mailto:josepedromagalhaes at gmail.com] On Behalf Of José Pedro Magalhães
Sent: 08 February 2013 09:59
To: Simon Peyton-Jones
Cc: ghc-devs at 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.html), 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130209/68f75d4c/attachment-0001.htm>