- ghc-tickets - Haskell.org

Re: [GHC] #7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion
by GHC 01 Aug '17

01 Aug '17

#7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion -------------------------------------+------------------------------------- Reporter: shachaf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_runt/T7436 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7436#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7742: StandaloneDeriving on Read fails for GADTs
by GHC 01 Aug '17

01 Aug '17

#7742: StandaloneDeriving on Read fails for GADTs -------------------------------------+------------------------------------- Reporter: hoffstaetter | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: invalid | Keywords: deriving Operating System: MacOS X | 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: => deriving -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7742#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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