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: [email protected] [mailto:[email protected]] On
Behalf Of José Pedro Magalhães
Sent: 08 February 2013 09:59
To: Simon Peyton-Jones
Cc: [email protected]
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
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
