#8851: Standalone deriving and GND behave differently --------------------------------------------+------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Aha. Right. Suppose we have {{{ class C r where op :: forall a. theta => op_ty newtype T a = MkT rep_ty deriving( C ) }}} Then the both newtype deriving and standalone deriving should succeed if this will typecheck {{{ instance C rep_ty => C (T a) where op = coerce (op :: op_ty[rep_ty/r] }}} When will this typecheck? Notice that we instantiate `op` (like any other variable occurrence) at its occurrence site, which throws the instantiated `theta` into the constraints to be solved. Answer: when * `Coercible (op_ty[rep_ty/r]) (op_ty[N a/r])` holds * Assuming `C rep_ty` and `theta[T a/r]`, we can prove `theta[rep_ty/r]` In this case, `theta[rep_ty/r]` is simply `Monad IdrisInlineParser` which holds from a top-level instance, not from any of the local "assuming.." parts. So I think the `deriving` mechanism should check this second bullet. I believe that "standalone deriving" is deliberately [http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html #stand-alone-deriving more gung-ho]: it simply generates the boilerplate and tries to typecheck it. The `deriving` clause makes checks up-front so that the generated code is certain to typecheck. We just need to fix those up-front checks. Thanks for looking at this Richard. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8851#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler