#14782: typeclass polymorphism defeats bang patterns -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: invalid | Keywords: | MonomorphismRestriction Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Let's look at your two examples: {{{#!hs main = seq (undefined :: Monoid a => a) (return ()) }}} The type-checker looks at the first argument of `seq` and sees something of `forall a. Monoid a => a`. So it instantiates this argument, providing a unification variable `t` and generating the constraint `Monoid t`. Later, the constraint solver discovers that it can't solve for `Monoid t`, and you've lost the game. {{{#!hs main = let n :: Monoid a => a; !n = undefined in return () }}} Here, the `undefined` is checked in an environment where we've quantified over `a` and can assume `Monoid a`, as is usual in the definition of a variable with a constrained type. No problem there. And, despite thinking of `!n` as desugaring to `seq n` somewhere, there is nowhere that GHC instantiates `n`. (Maybe you're arguing that we're not faithful to that desugaring... and you'd be right.) GHC just forces `n` right as it is, which exposes the lambda -- but not the `undefined` -- and then carries on. Does that help? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14782#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler