#10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by ekmett): I definitely completely buy that it is a difficult request! I'd be happy if I had to utter all sorts of UndecidableSuperclasses incantations to get the compiler to let me even try it. Another example of where this goes wrong would be trying to define the notion of a module over a ring or rig. Every monoid forms a module over the naturals as a rig, every group forms a module over the integers, every ring forms a module over itself, etc. If you go to bake these requirements into your definition of a module or ring then you get into this same sort of cyclic definition. {{{ class Module g Integer => Group g class (Group g, Ring r) => Module g r class Module r r => Ring r }}} Right now about half the time I can fake this with newtype noise, and the other half of the time I can get away with hacks like the explicit dictionary passing through a member, but it's hard to sell that in an API to users. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10318#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler