#8177: Roles for type families -------------------------------------+------------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * priority: high => normal Comment: Hmm... well, this just got a little more complicated. The full example John just posted would not be solved by fixing this ticket. That's because the data instance for `MVector` ''pattern-matches'' on `Int`. Currently in GHC, it would be sound to have both the instance given and a separate instance ending in `Age`, and have these instances be unrelated. Accordingly, if the `MVector` were declared to have a representational role for its last parameter, the instance given would be rejected for pattern-matching on a representational parameter. What it seems John wants is something new -- a data family that does ''representational'' matching, not nominal matching. Such a beast would consider `data instance MVector s Int` and `data instance MVector s Age` to overlap. Along similar lines, if a `MVector s Age` were requested, GHC would serve up the instance for `MVector s Int`. While I can imagine implementing such a feature (essentially by preventing newtypes from appearing in instance declarations, much like how type families can't appear in instance declarations today... and then normalizing with respect to newtypes at usage sites), the ramifications of the design are far from clear. In particular, what if the constructor of a newtype is not available? It would also mean, for example, that if a library exports a newtype `Foo` abstractly, a user wishing to have an `MVector` instance for `Foo` would need to know `Foo`'s representation type, something that the library author thought was hidden from users. It's all a little murky. So, I'm saying that John's use case does ''not'' qualify for this ticket, and I'll un-bump its priority. John, if in light of my analysis (and if you agree with it!) you still want this feature, create a new feature request with the priority you feel is appropriate. This seems related but quite separable to the features requested in this ticket. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8177#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler