[GHC] #8599: Deriving in associated data families ignores instance's constraints

[GHC]

#8599: Deriving in associated data families ignores instance's constraints
-------------------------------------+------------------------------------
        Reporter:  mojojojo          |            Owner:
            Type:  bug               |           Status:  new
        Priority:  normal            |        Milestone:
       Component:  Documentation     |          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):

 * component:  Compiler => Documentation


Comment:

 This is by design, though quite non-trivially.

 The problem is caused by the confluence of two design decisions:

 1. Associated data/newtype instances do not interact with any specified
 context to the enclosing class instance.

 2. As the manual says in section 7.5.1, "each constraint in the inferred
 instance context must consist only of type variables, with no
 repetitions." In the case at hand, the inferred context would be `Eq (DF'
 a)`, which does not meet this criterion.

 The fact in (1) does not seem to be documented anywhere, which is why I'm
 relabeling this as a documentation bug. Changing this fact seems hard: do
 we want the context to be inherited by all data constructors of an
 associated data instance? How can the context interact with an associated
 type instance (without substantially changing the way type families work)?
 To me, the only place that the context should possibly be inherited is in
 derived instances, as the original report suggests. But, even here, its
 role would be unclear: is the context "fully-specified", like in a
 standalone-deriving instance? What if a larger context is necessary? What
 if a smaller one were sufficient? There are consistent points in this
 design space, but choosing one and articulating it might be hard, and
 somewhat arbitrary.

 Thoughts? If someone agrees with relabeling this as a documentation bug, I
 can update the stuff on data families when I return from holiday (Jan. 6).

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8599#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler