May 2017 - ghc-tickets

[GHC] #12814: Should GND infer an instance context when deriving method-free classes?
by GHC 01 Aug '17

01 Aug '17

#12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11369, #12810 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a design question that emerged from code that I originally discovered [https://ghc.haskell.org/trac/ghc/ticket/11369#comment:17 here] and [https://ghc.haskell.org/trac/ghc/ticket/12810#comment:3 here]. To recap, it's now possible to have code like this: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies #-} class C a where type T a newtype Identity a = Identity a deriving C }}} Compiling this (with `-Wredundant-constraints`) generates this code: {{{#!hs instance C a => C (Identity a) where type T (Identity a) = T a }}} But now GHC will complain: {{{ • Redundant constraint: C a • In the instance declaration for ‘C (Identity a)’ }}} This warning makes sense from the perspective that the `C a` constraint isn't ever used by the associated type family instance. So the question arises: should GND avoid generating an instance context for the representation type in the event it's deriving a class with no methods? Fortunately, patching GHC to do this is trivial: {{{#!diff diff --git a/compiler/typecheck/TcDeriv.hs b/compiler/typecheck/TcDeriv.hs index 4722f16..df2d3d5 100644 --- a/compiler/typecheck/TcDeriv.hs +++ b/compiler/typecheck/TcDeriv.hs @@ -1272,7 +1272,8 @@ mkNewTypeEqn dflags overlap_mode tvs [ let (Pair t1 t2) = mkCoerceClassMethEqn cls dfun_tvs inst_tys rep_inst_ty m in mkPredOrigin (DerivOriginCoerce meth t1 t2) TypeLevel (mkReprPrimEqPred t1 t2) - | meth <- classMethods cls ] + | meth <- meths ] + meths = classMethods cls -- If there are no tyvars, there's no need -- to abstract over the dictionaries we need @@ -1281,7 +1282,11 @@ mkNewTypeEqn dflags overlap_mode tvs -- instance C T -- rather than -- instance C Int => C T - all_preds = rep_pred_o : coercible_constraints ++ sc_theta -- NB: rep_pred comes + all_preds = if null meths then [] else [rep_pred_o] + -- See Note [GND and method-free classes] + ++ coercible_constraints + ++ sc_theta + -- NB: rep_pred_o comes first ------------------------------------------------------------------- -- Figuring out whether we can only do this newtype-deriving thing }}} After implementing this patch, I ran the testsuite, and there were some surprising results. One thing that shocked me was that the program reported in #6088, which had previously failed due to a patch resulting from #8984, was now passing! {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE EmptyDataDecls #-} module T6088 where class C a newtype A n = A Int type family Pos n data True instance (Pos n ~ True) => C (A n) newtype B n = B (A n) deriving (C) }}} That is because previously, GHC was trying to generate an instance like this: {{{#!hs instance (Pos n ~ True) => C (B n) }}} And this was rejected, since we don't infer exotic equality constraints when deriving. But with this patch, it now generates: {{{#!hs instance {- Empty context => -} C (B n) }}} Which is certainly valid. But is it what a user would expect? I'm not so sure. As hvr notes in #11369, sometimes empty classes are used to enforce invariants, like in the following case: {{{#!hs class Throws e readFoo :: Throws IOError => FilePath -> IO Foo readFoo fn = {- ... -} }}} What if you wanted to have a `Throws` instance for a newtype? You'd probably want something like this: {{{#!hs newtype Id a = MkId a instance Throws a => Throws (Id a) }}} Which feels like something GND should be able to take care of with ease. But to your surprise, you try this: {{{#!hs newtype Id a = MkId a deriving Throws }}} And now GHC generates not the instance above, but rather just: {{{#!hs instance Throws (Identity a) }}} So it's possible that we would lose some of the expressiveness of GND by implementing this change. Is that acceptable? I'm not sure, so I though I'd solicit feedback here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12814> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #13314: StandaloneDeriving and DeriveAnyClass don't work together
by GHC 01 Aug '17

01 Aug '17

#13314: StandaloneDeriving and DeriveAnyClass don't work together -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | 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: -------------------------------------+------------------------------------- I'm starting with the `SPretty` example from the `DeriveAnyClass` section in the GHC users guide: {{{#!hs #!/usr/bin/env stack -- stack --resolver lts-8.0 {-# LANGUAGE DefaultSignatures, DeriveAnyClass, StandaloneDeriving #-} import Prelude import Numeric.Natural (Natural) class SPretty a where sPpr :: a -> String default sPpr :: Show a => a -> String sPpr = show }}} I can write an empty instance for `Natural`: {{{#!hs instance SPretty Natural where }}} So then I would expect to be able to write an equivalent definition using standalone deriving: {{{#!hs deriving instance SPretty Natural }}} But instead it fails with this error: {{{ error: • Can't make a derived instance of ‘SPretty Natural’: The data constructors of ‘Natural’ are not all in scope so you cannot derive an instance for it • In the stand-alone deriving instance for ‘SPretty Natural’ }}} It seems like this ought to work; I'm not sure why the constructors should need to be in scope, given that the instance can be derived trivially without defining any methods. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13314> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving?
by GHC 01 Aug '17

01 Aug '17

#8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Nathan Howell posts this code: {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} -- Uncomment to compile on GHC 7.8 -- {-# LANGUAGE ImpredicativeTypes #-} module Repro where import Control.Monad.Trans.Cont import Control.Monad.Trans.State.Lazy newtype AnyContT m a = AnyContT { unAnyContT :: forall r . ContT r m a } class MonadAnyCont b m where anyContToM :: (forall r . (a -> b r) -> b r) -> m a instance MonadAnyCont b (AnyContT m) where anyContToM _ = error "foo" data DecodeState = DecodeState newtype DecodeAST a = DecodeAST { unDecodeAST :: AnyContT (StateT DecodeState IO) a } deriving (MonadAnyCont IO) }}} Compiling on HEAD produces {{{ [1 of 1] Compiling Repro ( repro.hs, interpreted ) repro.hs:24:13: Cannot instantiate unification variable ‛b0’ with a type involving foralls: (forall r. (a1 -> IO r) -> IO r) -> DecodeAST a1 Perhaps you want ImpredicativeTypes In the expression: GHC.Prim.coerce (anyContToM :: (forall (r :: *). (a -> IO r) -> IO r) -> AnyContT (StateT DecodeState IO) a) :: forall (a :: *). (forall (r :: *). (a -> IO r) -> IO r) -> DecodeAST a In an equation for ‛anyContToM’: anyContToM = GHC.Prim.coerce (anyContToM :: (forall (r :: *). (a -> IO r) -> IO r) -> AnyContT (StateT DecodeState IO) a) :: forall (a :: *). (forall (r :: *). (a -> IO r) -> IO r) -> DecodeAST a Failed, modules loaded: none. }}} Two questions: 1. Should we require users to specify !ImpredicativeTypes here? Or, should the !GeneralizedNewtypeDeriving mechanism (which sometimes is impredicative) just assume the extension? 2. Can we improve the error message? I'd like to note that the original example really ''does'' require impredicativity -- the question is whether and how to bother the user with this technicality. Small program note: I've done a lot of stuff with !GeneralizedNewtypeDeriving lately but am on holiday until Jan. 6, so don't expect responses! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8631> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9444: -ddump-deriv doesn't dump failed newtype-deriving
by GHC 01 Aug '17

01 Aug '17

#9444: -ddump-deriv doesn't dump failed newtype-deriving -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When I say {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies #-} {-# OPTIONS_GHC -ddump-deriv #-} type family F a type instance F Int = Bool class C a where meth :: a -> F a instance C Int where meth = (> 0) newtype Age = MkAge Int deriving C }}} I get an error (which I should), but I don't get the derived `C` instance, as requested by `-ddump-deriv`. The output should include this helpful information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10361: DeriveAnyClass does not fill in associated type defaults
by GHC 01 Aug '17

01 Aug '17

#10361: DeriveAnyClass does not fill in associated type defaults -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I would expect `test1` and `test2` below to typecheck. This is a reduced test case from trying to use `DeriveAnyClass` on the `Generic` class of the `generics-sop` package, which unfortunately fails due to this bug. {{{ {-# LANGUAGE DeriveAnyClass, StandaloneDeriving, TypeFamilies #-} module Test where class C1 a where type T1 a type instance T1 a = Char class C2 a where -- equivalent to C1 type T2 a type instance T2 a = Char class C3 a where -- equivalent to C1, C2 type T3 a type instance T3 a = Char data A = B deriving C1 deriving instance C2 A instance C3 A -- fails -- test1 :: T1 A -- test1 = 'x' -- fails -- test2 :: T2 A -- test2 = 'x' -- succeeds test3 :: T3 A test3 = 'x' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10361> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type
by GHC 01 Aug '17

01 Aug '17

#10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #8678 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently, the {{{-XDeriveFoldable}}} extension will reject any derived {{{Foldable}}} instance for a data type where the last argument of the type constructor is constrained. For example, using this data type from [http://git.haskell.org/ghc.git/blob/9f968e97a0de9c2509da00f6337b612dd72a038… TcDeriv.hs] as inspiration: {{{#!hs {-# LANGUAGE DeriveFoldable, GADTs, StandaloneDeriving #-} module DeriveFoldableRejected where data T a b where T4 :: Ord b => b -> T a b T5 :: b -> T b b T6 :: T a (b,b) deriving instance Foldable (T a) }}} Compiling {{{DeriveFoldableRejected.hs}}} with GHC 7.10 will currently fail: {{{ DeriveFoldableRejected.hs:9:1: Can't make a derived instance of ‘Foldable (T a)’: Constructor ‘T4’ must be truly polymorphic in the last argument of the data type In the stand-alone deriving instance for ‘Foldable (T a)’ Failed, modules loaded: none. }}} I don't think this restriction needs to apply to {{{Foldable}}} instances. Unlike {{{Functor}}} and {{{Traversable}}} instances, which require the last argument to be truly universal, {{{Foldable}}} instances can get away without this. To demonstrate, here's a slightly modified {{{T}}} data type, without the constraints: {{{#!hs {-# LANGUAGE DeriveFoldable, GADTs, StandaloneDeriving #-} {-# OPTIONS_GHC -ddump-deriv #-} module DeriveFoldableLegal where data T a b where T45 :: b -> T a b T6 :: T a b deriving instance Foldable (T a) }}} The output of {{{-ddump-deriv}}} is: {{{ Derived instances: instance Data.Foldable.Foldable (DeriveFoldableRejected.T a_aDc) where Data.Foldable.foldr f_aDd z_aDe (DeriveFoldableRejected.T45 a1_aDf) = f_aDd a1_aDf z_aDe Data.Foldable.foldr f_aDg z_aDh DeriveFoldableRejected.T6 = z_aDh Data.Foldable.foldMap f_aDi (DeriveFoldableRejected.T45 a1_aDj) = f_aDi a1_aDj Data.Foldable.foldMap f_aDk DeriveFoldableRejected.T6 = GHC.Base.mempty }}} Copying this back into {{{DeriveFoldableRejected.hs}}} (after some cleanup): {{{#!hs {-# LANGUAGE DeriveFoldable, GADTs, StandaloneDeriving #-} module DeriveFoldableRejected where data T a b where T4 :: Ord b => b -> T a b T5 :: b -> T b b T6 :: T a (b,b) instance Foldable (T a) where foldr f z (T4 a) = f a z foldr f z (T5 a) = f a z foldr f z T6 = z foldMap f (T4 a) = f a foldMap f (T5 a) = f a foldMap f T6 = mempty }}} reveals that it will compile correctly with the generated code. Therefore, it seems like the check for universality in the last type argument shouldn't be used in {{{-XDeriveFoldable}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10447> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor
by GHC 01 Aug '17

01 Aug '17

#10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Using {{{PolyKinds}}} and {{{DeriveFunctor}}} in tandem on GHC 7.10.2-rc1 will cause a kind incompatibility in certain cases: {{{ GHCi, version 7.10.1.20150612: http://www.haskell.org/ghc/ :? for help λ> :set -XPolyKinds -XDeriveFunctor -ddump-deriv λ> newtype Compose f g a = Compose (f (g a)) deriving Functor ==================== Derived instances ==================== Derived instances: instance forall (k_axa :: BOX) (f_axb :: k_axa -> *) (g_axc :: * -> k_axa). (GHC.Base.Functor f_axb, GHC.Base.Functor g_axc) => GHC.Base.Functor (Ghci1.Compose f_axb g_axc) where GHC.Base.fmap f_axd (Ghci1.Compose a1_axe) = Ghci1.Compose (GHC.Base.fmap (GHC.Base.fmap f_axd) a1_axe) Generic representation: Generated datatypes for meta-information: Representation types: <interactive>:3:52: Kind incompatibility when matching types: f0 :: * -> * f :: k -> * Expected type: f (g b) Actual type: f0 (f1 b) Relevant bindings include a1 :: f (g a) (bound at <interactive>:3:52) fmap :: (a -> b) -> Compose f g a -> Compose f g b (bound at <interactive>:3:52) In the first argument of ‘Compose’, namely ‘fmap (fmap f) a1’ In the expression: Compose (fmap (fmap f) a1) When typechecking the code for ‘fmap’ in a derived instance for ‘Functor (Compose f g)’: To see the code I am typechecking, use -ddump-deriv }}} A workaround is to use {{{StandaloneDeriving}}}: {{{ λ> :set -XStandaloneDeriving λ> newtype Compose f g a = Compose (f (g a)) λ> deriving instance (Functor f, Functor g) => Functor (Compose f g) ==================== Derived instances ==================== Derived instances: instance (GHC.Base.Functor f_ayO, GHC.Base.Functor g_ayP) => GHC.Base.Functor (Ghci1.Compose f_ayO g_ayP) where GHC.Base.fmap f_ayQ (Ghci1.Compose a1_ayR) = Ghci1.Compose (GHC.Base.fmap (GHC.Base.fmap f_ayQ) a1_ayR) Generic representation: Generated datatypes for meta-information: Representation types: }}} This problem does not seem to occur in GHC HEAD, however: {{{ GHCi, version 7.11.20150608: http://www.haskell.org/ghc/ :? for help λ> :set -XPolyKinds -XDeriveFunctor -ddump-deriv λ> newtype Compose f g a = Compose (f (g a)) deriving Functor ==================== Derived instances ==================== Derived instances: instance forall (k_a148 :: BOX) (f_a149 :: k_a148 -> *) (g_a14a :: * -> k_a148). (GHC.Base.Functor f_a149, GHC.Base.Functor g_a14a) => GHC.Base.Functor (Ghci3.Compose f_a149 g_a14a) where GHC.Base.fmap f_a14b (Ghci3.Compose a1_a14c) = Ghci3.Compose (GHC.Base.fmap (GHC.Base.fmap f_a14b) a1_a14c) Generic representation: Generated datatypes for meta-information: Representation types: }}} Can this fix be backported in time for GHC 7.10.2? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10524> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10561: "deriving (Functor)" on a polykinded type produces ill-kinded instance
by GHC 01 Aug '17

01 Aug '17

#10561: "deriving (Functor)" on a polykinded type produces ill-kinded instance -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Arose in #10524, and new since 7.10. {{{ rwbarton@morphism:/tmp$ ~/ghc/inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20150615: http://www.haskell.org/ghc/ :? for help Prelude> :set -XPolyKinds -XDeriveFunctor -ddump-deriv -fprint-explicit- kinds Prelude> newtype Compose f g a = Compose (f (g a)) deriving Functor ==================== Derived instances ==================== Derived instances: instance forall (k_and :: BOX) (f_ane :: k_and -> *) (g_anf :: * -> k_and). (GHC.Base.Functor f_ane, GHC.Base.Functor g_anf) => GHC.Base.Functor (Ghci1.Compose k_and * f_ane g_anf) where GHC.Base.fmap f_ang (Ghci1.Compose a1_anh) = Ghci1.Compose (GHC.Base.fmap (GHC.Base.fmap f_ang) a1_anh) Generic representation: Generated datatypes for meta-information: Representation types: Prelude> :i GHC.Base.Functor class Functor (f :: * -> *) where [...] }}} The context `(GHC.Base.Functor f_ane, GHC.Base.Functor g_anf)` is ill- kinded except when `k_and = *`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10561> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10835: Regression in standalone Data deriving for phantom types
by GHC 01 Aug '17

01 Aug '17

#10835: Regression in standalone Data deriving for phantom types -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Thise code {{{#!hs {-# LANGUAGE DeriveDataTypeable, StandaloneDeriving, PolyKinds #-} module M where import Data.Data import Data.Typeable data Phantom t = Phantom deriving Typeable deriving instance Typeable t => Data (Phantom t) }}} compiles with 7.8.4 but not with 7.10.2. The error is {{{ data.hs:8:1: Could not deduce (Typeable Phantom) arising from the superclasses of an instance declaration from the context (Typeable t) bound by the instance declaration at data.hs:8:1-48 In the instance declaration for ‘Data (Phantom t)’ }}} PolyKinds here is a hack I came up with to make this compile with 7.8; but ideally, this code should compile whether PolyKinds is enabled or not. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10835> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12080: RebindableSyntax breaks deriving Ord
by GHC 01 Aug '17

01 Aug '17

#12080: RebindableSyntax breaks deriving Ord -------------------------------------+------------------------------------- Reporter: afarmer | Owner: afarmer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11396 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The code generated with `deriving (Ord)` includes if-expressions which are subject to rebindable syntax: {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RebindableSyntax #-} import Prelude class IfThenElse a b where ifThenElse :: a -> b -> b -> b instance IfThenElse Bool b where ifThenElse c x y = if c then x else y data Foo = Foo | Bar | Baz deriving (Eq, Ord) main :: IO () main = print $ Foo < Bar }}} when loaded into ghci (7.10, but not specific to that version): {{{ [1 of 1] Compiling Main ( Foo.hs, interpreted ) Foo.hs:13:42: Bad call to tagToEnum# at type a_aQy Specify the type by giving a type signature e.g. (tagToEnum# x) :: Bool In the expression: (GHC.Prim.tagToEnum# (a# GHC.Prim.<# b#)) In the expression: if (GHC.Prim.tagToEnum# (a# GHC.Prim.<# b#)) then LT else if (GHC.Prim.tagToEnum# (a# GHC.Prim.==# b#)) then EQ else GT In a case alternative: b# -> if (GHC.Prim.tagToEnum# (a# GHC.Prim.<# b#)) then LT else if (GHC.Prim.tagToEnum# (a# GHC.Prim.==# b#)) then EQ else GT When typechecking the code for ‘compare’ in a derived instance for ‘Ord Foo’: To see the code I am typechecking, use -ddump-deriv Foo.hs:13:42: No instance for (IfThenElse a0 Ordering) arising from an if statement The type variable ‘a0’ is ambiguous Note: there is a potential instance available: instance IfThenElse Bool b -- Defined at Foo.hs:10:10 In the expression: if (GHC.Prim.tagToEnum# (a# GHC.Prim.<# b#)) then LT else if (GHC.Prim.tagToEnum# (a# GHC.Prim.==# b#)) then EQ else GT In a case alternative: b# -> if (GHC.Prim.tagToEnum# (a# GHC.Prim.<# b#)) then LT else if (GHC.Prim.tagToEnum# (a# GHC.Prim.==# b#)) then EQ else GT In the expression: case (Main.$con2tag_rjG b) of { b# -> if (GHC.Prim.tagToEnum# (a# GHC.Prim.<# b#)) then LT else if (GHC.Prim.tagToEnum# (a# GHC.Prim.==# b#)) then EQ else GT } When typechecking the code for ‘compare’ in a derived instance for ‘Ord Foo’: To see the code I am typechecking, use -ddump-deriv Failed, modules loaded: none. }}} The if-expressions are generated by `nlHsIf`, which calls `mkHsIf`, which uses `Just noSyntaxExpr` as its first argument. I'm going to add a new function `nlBuiltInHsIf` which uses `Nothing` as the first argument, forcing the built-in if (according to Note [Rebindable if]), then use this new function when deriving stuff. I'll post a patch soonish. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12080> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8