Brent Yorgey wrote:
Well, first of all, the definition of compCommand should use calls to compBlock, not recursive calls to compCommand. But that's not the main source of your problems.
What exactly are you trying to accomplish? And why do you need a type class?
Whatever the code is supposed to accomplish, there is something strange going on with the type checking. I have managed to reduce the code (while keeping the type error message) thus data Command = Skip class Java block command where block_ :: [command] -> block compBlock :: [Command] -> block --compBlock = block_ . map compCommand compCommand :: Command -> command This compiles ok. But when I ask ghci for the type of the body of the default definition of compBlock I get *Main> :t block_ . map compCommand block_ . map compCommand :: forall block block1 command. (Java block command, Java block1 command) => [Command] -> block and if I remove the comment from the default definition of compBlock I get Could not deduce (Java block command1) from the context (Java block command) arising from use of `block_' at Bla.hs:7:14-19 Possible fix: add (Java block command1) to the class or instance method `compBlock' In the first argument of `(.)', namely `block_' In the expression: block_ . (map compCommand) In the definition of `compBlock': compBlock = block_ . (map compCommand) It would be nice if someone could explain (in language that can be understood by non-type-system-experts) why ghc(i) deduces these strange 'duplicated' contexts. Cheers Ben