Ticket #5568 (closed bug: fixed)
Add Show and Binary instances for TypeRep
|Reported by:||simonmar||Owned by:|
|Type of failure:||None/Unknown||Difficulty:||Unknown|
|Test Case:||Blocked By:|
Unfortunately the new TypeRepKey type is abstract and provides no operations apart from Eq and Ord instances. Hence, there is still no way to write a type representation into a file or across the wire. Jush showing a TypeRep won't cut it, since that loses the distinctions between similarly named types in different modules.
So, I think we need a Show instance for TypeRepKey, or better yet, a Binary instance. Moreover, a non-deprecated pure function TypeRep -> TypeRepKey is in place, since the keys have an actual use as a compact, efficient, and serializable injection of the typereps.
Alternatively, the Show instance of TypeRep could be made injective by printing out the package and module.
Commentary from #3480
I've exposed the representation via the Data.Typeable.Internal module. Of course that's not guaranteed to be a stable API, but I'm happy to add a stable API if we can agree on what it should be. Lennart Augustsson and Neil Mitchell are doing exactly this (serialising TypeRep) - I think they're using the Data.Typeable.Internal API right now.
So what shall we do?
For older versions of ghc I just used (show . typeOf). When ghc 7.2 broke this I had to start using Internal, so now I use tyConModule and tyConName to emulate the behaviour of the old show.
I'm sorry for messing up the ticket. I had assumed that the missing Show instance had been a simple oversight. If so, this would suffice:
instance Show TypeRepKey where show (TypeRepKey (Fingerprint hi lo)) = printf "%016x%016x" hi lo
A Binary instance is more difficult: where would it be put? It cannot be in Typeable.hs (as base cannot depend on binary), but it cannot be in Binary.hs either (as TypeRepKey is opaque and not exposed from Typeable).
I don't think it's a good idea to make TypeReps? themselves publicly deserializable, as that would allow the creation of fake typereps. A separate one-way injection to a serializable TypeRepKey seems much more secure.