#10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, it seems like the most controversial part of this is folding over types that aren't syntactically equivalent to the return type. I'm certainly open to the idea of not folding over types if it's not immediately clear that they're equal, but I'm not sure how many levels of indirection would be considered acceptable. In this data type: I'm open to the idea of only folding over fields that are syntactically identical to the type variable, but I'm not exactly sure where the line would be drawn. If I understand the discussion, then if you had this data type: {{{#!hs class (a ~ Int) => Foo a data A a where A1 :: Ord a => a -> T a A2 :: Int -> T Int A3 :: b ~ Int => b -> T Int A4 :: a ~ Int => Int -> T a A5 :: a ~ Int => a -> T a A6 :: (a ~ b, b ~ Int) => Int -> b -> T a A7 :: Foo a => Int -> a -> T a }}} How we would we define "syntactic equality" here? It seems like {{{A1}}} and {{{A5}}} are pretty uncontroversial here, but the other constructors require (at least) one type substitution to infer that their fields could be folded over. Which of these constructors would you all consider to be acceptable for folding over? I'd need to get an idea of this before responding to dolio's questions. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10447#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler