[GHC] #8177: Roles for type families

[GHC]

#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