#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: I feel like batterseapower is arguing for a change in the way associated family instances work at a fundamental level. To illustrate what I mean, consider this code: {{{#!hs {-# LANGUAGE TypeFamilies #-} class C a where data D a c :: a -> a -> Bool instance Eq a => C [a] where newtype D [a] = DList [a] c = (==) dlist :: D [a] dlist = DList [] }}} Notice that I was able to construct a value of type `D [a]` without needing an `Eq a` constraint! That flies in the face of the fact that the `C [a]` instance does seem to require an `Eq a` constraint—rather, it requires an `Eq a` constraint, but only when typechecking its associated methods. For better or worse, the `D [a]` family instance appears to be pretty much independent of the `C [a]` instance (and its methods). So if we accept batterseapower's proposal above and propagate class constraints down to the associated family instances as well, would it be correct to say that my example code would now fail to typecheck? Is this desirable behavior? I don't really understand the intricacies of associated family instances that well, so perhaps there is a reason that the current design is the way it is. I'd need Simon's judgment to know for sure. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4815#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler