#16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. -------------------------------------+------------------------------------- Reporter: j9794 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeErrors Comment: `data Foo = Foo deriving Num via (NotNum Foo)` is generating a slightly different instance than you think it is: {{{ $ /opt/ghc/8.6.3/bin/ghci Bug.hs -ddump-deriv GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) ==================== Derived instances ==================== Derived class instances: instance (TypeError ...) => GHC.Num.Num Main.Foo where }}} GHC treats `TypeError` constraints as insoluble, so they're inferred to be a part of the instance context. A standalone `deriving via (NotNum Foo) instance Num Foo` declaration, on the other hand, asserts that there is no instance context, so GHC tries to solve for the residual `TypeError` constraint that is inferred during typechecking. This leads to the compile-time exception you see in the original program. Note that if you write this: {{{#!hs deriving via (NotNum Foo) instance TypeError (Text "Not a num") => Num Foo }}} Or even this: {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} deriving via (NotNum Foo) instance _ => Num Foo }}} Then you won't get an exception during compile-time. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16362#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler