#11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari):
These representations are handled as a bit of a special case. I need to [sic] Ooh. It's like a mystery novel.
:-) That was meant to say that I needed to take another careful look at the implementation surrounding the representations primitive type since it seems a bit fragile at the moment.
Other points: - I vote only pattern synonyms.
That sounds reasonable to me.
- Serialization is used in Cloud Haskell, no?
- I like the idea of including the paranoid checks as an option for
Yes; it's also used in GHC (there is a `Binary` instance). I'm a bit unsure at the moment of what this should look like. paranoid users. Although perhaps not, given that I believe it's likelier for a cosmic ray to flip a bit than for the fingerprints to give a false positive. I'm not opposed to providing it, although it would be good to state clearly what our threat model is here. What guarantees are we trying to keep? This question seems to become rather hairy in the presence of serialization.
As for names: I think a proper migration story needs to be articulated. In a few years, I'd hate to have all these extra Ts lying around. Use a new module name for the new features and keep the old module with the old interface around? Maybe the new module can be Data.Reflection.
I'm not sure the `T`s are necessarily bad given that the quantified `TypeRep` still serves a purpose. Especially in light of my proposal in comment:18 it seems like the `T` prefix could be a useful convention. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11011#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler