Third, working around this by manually floating out type families can be hugely painful, ''as it requires sacrificing one of the major benefits of type families, namely the ability to avoid passing around extra class
#15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): parameters which are already determined by other parameters'' Would it be possible to distil the example into a smaller form that still illustrates your key point, in italics. My example in comment:10 did not substantiate this point. Can you give a small example that does? The `Category` example is so big that I lost the wood for the trees. That is, so far I do not understand why floating out type families (a straightforward source-to-source transformation that does not change the number of class parameters) would sacrifice a major benefit. Thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15347#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler