November 2018 - ghc-tickets

[GHC] #15845: TH eta-reduces away explicit foralls in data family instances
by GHC 08 Nov '18

08 Nov '18

#15845: TH eta-reduces away explicit foralls in data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.7 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9692, #14179 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Language.Haskell.TH data family F1 a b data instance F1 [a] b = MkF1 data family F2 a data instance F2 a = MkF2 $(do i1 <- reify ''F1 i2 <- reify ''F2 runIO $ mapM_ (putStrLn . pprint) [i1, i2] pure []) }}} {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.7.20181101: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) data family Bug.F1 (a_0 :: *) (b_1 :: *) :: * data instance forall (a_2 :: *). Bug.F1 ([a_2]) b_3 = Bug.MkF1 data family Bug.F2 (a_0 :: *) :: * data instance Bug.F2 a_1 = Bug.MkF2 }}} The output here is quite baffling: * In the `F1` instance, we have an explicit `forall` which quantifies `a_2` but not `b_3`! * In the `F2` instance, there isn't an explicit `forall` at all despite the fact that there ought to be one, since there is a type variable `a_1` in this instance. The culprit in both of the bullet points above is the fact that GHC eta- reduces its internal representation of data family instance axioms. This is the same thing which caused #9692 and #14179, in fact. Luckily, the same fix for those tickets will also work here. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15845> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9692: Template Haskell reification for Data Families is buggy?
by GHC 08 Nov '18

08 Nov '18

#9692: Template Haskell reification for Data Families is buggy? -------------------------------------+------------------------------------- Reporter: hpacheco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: TemplateHaskell | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I have found an example where I think that the TH reification for data/newtype families is incorrect, in that if forgets non-instantiated type variables in instance declarations. For the attached example, it will infer the Info: {{{#!hs FamilyI (FamilyD DataFam TyFamReifyDefs.F [PlainTV a_1627399879,PlainTV b_1627399880] (Just StarT)) [DataInstD [] TyFamReifyDefs.F [ConT GHC.Types.Int] [NormalC TyFamReifyDefs.FInt [(NotStrict,VarT x_1627399881)]] []] }}} Note how the variable x is not declared in the body of the DataInstD. Since it does not need to have the same name as the family-declared variable, substituing is non-trivial this way... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9692> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14179: "Conflicting family instance" error pretty prints data family instances poorly
by GHC 08 Nov '18

08 Nov '18

#14179: "Conflicting family instance" error pretty prints data family instances poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This can be observed on GHC 8.0.1 or later: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where data family Fam a data instance Fam Int data instance Fam Int }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:5:15: error: Conflicting family instance declarations: Fam Int = -- Defined at Bug.hs:5:15 Fam Int = -- Defined at Bug.hs:6:15 | 5 | data instance Fam Int | ^^^ }}} Notice how GHC attempts to pretty-print the RHS by using a `=` symbol, but there is no RHS! This gets even more confusing with this program, which requires GHC HEAD: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where data family Fam :: k -> * data instance Fam :: * -> * data instance Fam :: * -> * }}} {{{ $ ghc5/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170818: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:15: error: Conflicting family instance declarations: Fam = -- Defined at Bug.hs:6:15 Fam = -- Defined at Bug.hs:7:15 | 6 | data instance Fam :: * -> * | ^^^ }}} Not only is there no RHS, but the kind signatures of each instance aren't printed either. This is an issue, since the entire reason why the two instances conflict are because of their kinds! We should rethink how data family instances are pretty printer here to avoid this issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14179> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b)
by GHC 08 Nov '18

08 Nov '18

#11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: libraries | Version: 7.8.3 (other) | Keywords: array | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `Array` has `Eq`, `Ord`, `Show` and `Read` instances but `UArray` only has `Eq`, `Ord` and `Show`. Add the missing `Read` instance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11335> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled
by GHC 08 Nov '18

08 Nov '18

#15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module Exp where type family F a data T a = MkT (F a) deriving instance Eq (F a) => Eq (T a) data T2 a = T2 (T a) deriving (Eq) }}} results in a type error {{{ • No instance for (Eq (F a)) arising from the first field of ‘T2’ (type ‘T a’) }}} According the manual this is expected behaviour (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… #inferred-context-for-deriving-clauses), but it is unfortunate; it seems to me that there is no deep reason that this instance should be rejected, other than an overly conservative check in the deriving machinery; I propose that this check is relaxed when the `UndecidableInstances` extension is enabled. Mind that I'm ''not'' proposing that it should also be able to infer the right constraints for `T` itself; but once I write such an explicit context myself once (for `T`), it seems to me that deriving the ''same'' constraints also for `T2` should be easy. Note that right now we can work-around this problem using {{{#!hs class Eq (F a) => EqF a deriving instance EqF a => Eq (T a) data T2 a = T2 (T a) deriving (Eq) }}} Normally however for such a class synonym we would then provide a single "authoritative" instance: {{{#!hs class Eq (F a) => EqF a instance Eq (F a) => EqF a }}} but if we do that then we are back at the same error for `T2`, because ghc will go from the `EqF a` constraint to the `Eq (F a)` constraint, and then refuse to add that constraint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15868> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15878: Unused data type with a "deriving" clause is falsely considered used
by GHC 08 Nov '18

08 Nov '18

#15878: Unused data type with a "deriving" clause is falsely considered used -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- module M () where data Foo = Bar deriving (Eq) If there are no explicit references to Foo and none to Bar, the data-type is necessarily unused, so I expect a warning about an unused data-type. Even if it is referenced, but only from instance declarations, it is necessarily unused in the program. One potential exception is functional dependencies, where the instance declaration itself has an effect. But even then, perhaps it is worth warning that the *type* is unused. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15878> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4020: Please consider adding support for local type synonyms
by GHC 07 Nov '18

07 Nov '18

#4020: Please consider adding support for local type synonyms -------------------------------------+------------------------------------- Reporter: nr | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 6.12.2 checker) | Resolution: | Keywords: type synonym 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 andreas.abel): I just tried to declare a `type` synonym in a `where` clause and was surprised that there is no GHC extension enabling this. Rationale: If the type abbreviation is only used to simply type- signatures of local functions, it should not have to be lifted to the top- level. See the Agda language why there is in principle no problem with having local type definitions. In the worst case, the type definition will not be in scope when trying to print it, but this problem already exists for type synoyms that are not in scope because they have not been imported. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4020#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13933: Support Typeable instances for types with coercions
by GHC 07 Nov '18

07 Nov '18

#13933: Support Typeable instances for types with coercions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: TypeInType, | Operating System: Unknown/Multiple Typeable | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I say {{{#!hs {-# LANGUAGE GADTs, TypeApplications, TypeInType #-} module Bug where import Type.Reflection data G a where MkG :: a ~ Bool => G a rep = typeRep @MkG }}} I get {{{ Bug.hs:10:7: error: • No instance for (Typeable <>) arising from a use of ‘typeRep’ • In the expression: typeRep @MkG In an equation for ‘rep’: rep = typeRep @MkG | 10 | rep = typeRep @MkG | }}} First off, the error message is confusing, mentioning the mysterious `<>`. But more importantly, it would be nice if the `Typeable` mechanism supported coercions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15710: Should accept a type that needs coercion quantification
by GHC 07 Nov '18

07 Nov '18

#15710: Should accept a type that needs coercion quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ f :: forall k (f :: k) (x :: k1). (k ~ (k1 -> *)) => f x f = error "uk" }}} Should we accept it? Now that we have coercion quantification (Trac #15497), I think the answer should be yes, with the elaborated signature being {{{ f :: forall k (f::k) (x::k1). forall (co :: k ~# (k1->*)). (f |> co) x }}} But there is a problem: the user wrote `k ~ (k1 -> *)`, and that's a boxed value that we can't take apart in types. I'm not sure what to do here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15710> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11008: GND with Type Families
by GHC 07 Nov '18

07 Nov '18

#11008: GND with Type Families -------------------------------------+------------------------------------- Reporter: crockeea | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the following code: {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts, UndecidableInstances #-} class C r type family F r newtype Foo r = Foo r instance (C (F r), Eq r) => Eq (Foo r) newtype Bar r = Bar (Foo r) deriving (Eq) }}} GHC produces the error {{{ No instance for (C (F r)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Eq (Bar r)) }}} If I enable `StandaloneDeriving`, I am able to derive the instance: `deriving instance (Eq (Foo r)) => Eq (Bar r)` [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/deriving.ht… #newtype-deriving The docs] indicate that this is exactly the instance that should be generated by GND for `newtype T v1..vn = MkT (t vk+1..vn) deriving (C t1..tj)`, where my code uses the following parameters: {{{ T = Bar v1 = r n = 1 MkT = Bar t = Foo r k= 1 C = Eq j = 0 }}} and all of the conditions enumerated in the docs seem to be met. Furthermore, `Bar` seems to fit squarely into the format of `data T1` in section 7.5.1 of the same documentation, which indicates it should not need `StandaloneDeriving`. It seems that the type family constraint on the `Eq` instance for `Foo` is causing the problem, but it's not clear why I'm forced to write a standalone instance that is identical to the one that should be generated by GND. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11008> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12