[GHC] #11067: Spurious superclass cycle error with type equalities

[GHC]

#11067: Spurious superclass cycle error with type equalities
-------------------------------------+-------------------------------------
        Reporter:  oerjan            |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.0.1
       Component:  Compiler (Type    |              Version:  7.10.2
  checker)                           |
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  GHC rejects       |  Unknown/Multiple
  valid program                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D1594
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by oerjan):

 Replying to [comment:11 simonpj]:
 > Can I ask: does `wip/T11067` make it easier?
 > It's pretty simple: with `UndecidableSuperClasses` the whole superclass
 restriction is lifted.

 From reading the notes, that sounds promising (although I think I found an
 error, will try to comment on that in Phab).

 I do have a hunch there's a bit of a potential annoyance, though: With
 something like `UndecidableInstances`, only the module ''declaring'' the
 instance needs to enable the extension. But the cycle check for
 superclasses is not locally restricted to the declaration "responsible"
 for the rule violation. If I'm understanding the notes correctly, if a
 class requires the extension, then any other class using it as a
 superclass also will.

 So a module such as `Data.Constraint.Forall` cannot just ''itself'' use
 `UndecidableSuperClasses` and thereby free the users from having to
 mention it.

 E.g. I suspect users would have to enable the extension explicitly in
 their own code to use a `ForallV` superclass (because `ForallV` has a type
 family superclass) or a nested `ForallF` superclass (because that
 ''would'' recurse on the `ForallF`, although in this case the "blame"
 might be more shared.)

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