#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