TyCon and TypeRep are supposed to be abstract, by providing these
additional few public operations the need to import
Data.Typeable.Internal is reduced, and future changes to the internal
structure of TypeRep/TyCon shouldn't require changes in packages such as
deepseq or hashable anymore (hopefully).
Details
Diff Detail
- Repository
- rGHC Glasgow Haskell Compiler
- Branch
- master
- Lint
Lint OK - Unit
No Unit Test Coverage - Build Status
Buildable 3264 Build 3291: GHC Patch Validation (amd64/Linux)
Fwiw, I'm tempted to also add hashTyCon :: TyCon -> Int
I'm just wondering if we shouldn't rather just expose :: Ty... -> Fingerprint accessors... or would that be already too concrete?
I don't have a strong opinion. A fingerprint is just a long hash-code! If we do, we should so so for TypeRep too., Maybe ask the CLC?
I have no problem with exporting the fingerprint extraction method. Any instability around something that obscure can be dealt with by users dedicated enough to understand it in the first place.
We may have to eventually change out the hash function used for Fingerprint to reduce the possibility of birthday attacks subverting the type system due to https://ghc.haskell.org/trac/ghc/ticket/7634 but that wouldn't affect merely getting your hands on the fingerprint.
expose field-accessors to Fingerprint field instead of providing Int-hash functions
naming is a bit awkward but follows from the existing tyConHash field-name