September 2016 - ghc-tickets

[GHC] #10450: RankNTypes type check on pattern match of "let" behaves different from "case"
by GHC 19 Apr '17

19 Apr '17

#10450: RankNTypes type check on pattern match of "let" behaves different from "case" -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Operating System: Unknown/Multiple Keywords: RankNTypes | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When pattern matching, "let/where" and "case" have different behaviours. I believe this to be a bug, and my hope is that all of the following should be accepted. Currently, this is accepted (a version using 'where' instead of 'let' type-checks too): {{{#!hs {-# LANGUAGE RankNTypes, ScopedTypeVariables #-} module Main where data Phantom x = Phantom Int deriving Show foo :: forall y. (forall x. (Phantom x)) -> Phantom y foo (Phantom x) = Phantom (x+1) -- trying to map foo over a list, this is the only way I can get it to work typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap intList = case intList of [] -> [] _ -> let (phead:ptail) = intList in foo phead : typeAnnotatedMap ptail }}} The following are not accepted: {{{#!hs typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap intList = case intList of [] -> [] (phead:ptail) -> foo phead : typeAnnotatedMap ptail typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap [] = [] typeAnnotatedMap (phead:ptail) = foo phead : typeAnnotatedMap ptail }}} The switches "ImpredicativeTypes" and "NoImpredicativeTypes" only change GHC's behaviour in the following example, for which I understand (but don't like) that it is not accepted, its error message is fine: {{{#!hs typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap lst = map foo lst }}} Tested this on 7.8.2. Version 7.6.3 and 7.4.2 seem to behave the same. Sorry for not testing this on the latest version. Should this not be a bug, it would help if the type checker would somehow point me in the direction of the solution (first version) when I write any one of the 'problem cases'. The current type error is something like: {{{ Couldn't match type ‘x0’ with ‘x’ because type variable ‘x’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: [Phantom x] }}} More helpful would be something like: {{{ Your pattern match bound the following types to a shared skolem variable: ptail :: [Phantom x0] (bound at rankNtest.hs:11:25) phead :: Phantom x0 (bound at rankNtest.hs:11:19) You may have intended to use a "let" or "where" pattern-match instead. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10227: Type checker cannot deduce type
by GHC 19 Apr '17

19 Apr '17

#10227: Type checker cannot deduce type -------------------------------------+------------------------------------- Reporter: augustss | 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: | -------------------------------------+------------------------------------- When using closed type families the type checker does not use all the information that the closedness condition implies. In the following module the type checker fails to deduce the type for `f`. But lets start with `descrIn` since it has the same problem. The deduced type is `(D d Bool ~ Bool, D d Double ~ Bool, D d (Maybe String) ~ Bool) => Descr d`. But it is (to quote Simon PJ) plain as a pikestaff that `D d Double ~ Bool` can only hold if `d ~ In`, since there are only two equations and it cannot be the second. Similar reasoning can be used to deduce all the commented out type signatures. {{{#!hs {-# LANGUAGE RecordWildCards, TypeFamilies, DataKinds, NoMonomorphismRestriction, FlexibleContexts #-} module Main(main) where import Data.Maybe data InOut = In | Out type family D (d :: InOut) a where D 'In a = Bool D 'Out a = a data Descr d = Descr { abc :: D d Bool, def :: D d Double, ghi :: D d (Maybe String) } --descrIn :: Descr 'In descrIn = Descr { abc = False, def = True, ghi = True } --f :: Descr 'Out -> Double f Descr{..} = def + read (fromMaybe "0" ghi) --g :: Descr 'In -> Descr 'Out g d = Descr { abc = if abc d then True else False, def = if def d then 1234 else 0, ghi = if ghi d then Just "3008" else Nothing } main :: IO () main = do print $ f $ g descrIn }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11511: Type family producing infinite type accepted as injective
by GHC 19 Apr '17

19 Apr '17

#11511: Type family producing infinite type accepted as injective -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple Injective | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A question came up during discussion at University of Wrocław: {{{#!hs type family F a = r | r -> a where F a = [F a] }}} Should this pass the injectivity check? Currently it does but I don't think this is correct. After all `F Bool` and `F Char` both reduce to the same infinite type `[[[...]]]`, which by definition of injectivity gives us `Char ~ Bool`. Is this dangerous in practice? It can cause reduction stack overflow (or an infinite loop if you disable that check) but I don't think this can be used to construct unsafe coerce. We'd have to unify two infinite types, which does not seem possible. This is not an implementation problem - this stays faithful to theory developed in injective type families paper. If others agree that this is indeed incorrect then I think the right solution here would be to drop equation (7) from our algorithm in the paper. For generalized injectivity we planned drop that equation anyway. Here's another reason for doing this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11511> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode
by GHC 15 Apr '17

15 Apr '17

#8426: one-shot compilation + TH doesn't see instances that is seen in batch mode ----------------------------------------------+---------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Other Blocked By: | Test Case: Related Tickets: #7867 | Blocking: ----------------------------------------------+---------------------------- Haskell prime and Haskell98 both states that instances are always seen if there is any chain of imports leading from the current module to the instance. http://darcs.haskell.org/haskell-prime-report/report/haskell-report- html/modules.html#import-instances The ghc manual contains a discussion why this specification is too performance heavy to näively implement and contains the definition of orphanness and an algorithm to reproduce the specification with better performance. http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/separate- compilation.html#orphan-modules Unfortunately this cleverness breaks template haskell. Namely, if: - `Class.hs` contains a class, - `NonOrphan.hs` contains a data that implements the class, - `Importer.hs` just imports `NonOrphan.hs`, - `Main.hs` imports `Importer.hs`, - `Main.hs` reifies the class; then: - one-shot compilation's reify doesn't see the instance, - batch compilation's reify sees the instance. This ambiguity is shown in the attached tgz. Furthermore if `NonOrphan.hs` is in a separate package, then of course even batch compilation mode wouldn't reify the instance correctly. In that case there is no disambiguity between one-shot and batch, simply both is missing the info. I propose to solve this by enforcing a loading of all the interface files for every import transitively for the current module, when we meet an open type family or class reification request in template haskell's reify handler in `TcSplice.hs`. So I propose to keep the optimization of orphan instances and use it 99.9% of the time. We would only ever go on the quest of reading interface files for every import transitively when the user tries to reify something where we have to return an instance list. This means that TH compilations that reify types will get a little bit slower in exchange of being correct and unambiguous. Compilation time in cases when TH reification is not used will not change. I volunteer to prepare the patch, but would like to hear others first. So, any opinions, alternative ideas? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10800: vector-0.11
by GHC 13 Apr '17

13 Apr '17

#10800: vector-0.11 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- vector-0.11 takes substantially longer to compile with 7.10 than 7.8 Unfortunately the issue appears to be in generated code. Lacking time right now so I'm just going to drop the IRC log here, Compile log: https://travis-ci.org/haskell/vector/builds/56179052 {{{ * hvr thought some compile-time improvements landed in 7.10.2 <dolio> I don't think it uses sufficiently less memory to prevent it from using all memory on travis and failing. <dolio> Which is why it suddenly went from 8 minutes to 35. <dolio> Although it's also significantly worse even when you have enough memory. <dolio> hvr: 7.8.4 takes 4m40s, 7.10.2 takes 16m40s. <dolio> i7 4770, 32GB RAM. <dolio> vector 0.11 branch. <dolio> It's not as bad in the 0.10 branch. <dolio> It uses like 60% more memory, too. <dolio> Maybe more. <dolio> It's really just one or two files in the test suite that take all the time/memory. <hvr> dolio: does vector do some aggressive INLINEing? <dolio> Well, yes. <hvr> more in 0.11 than in 0.10? <dolio> It does more stuff in 0.11, yes. <bgamari> vector 0.11 has this new chunked streaming abstraction IIRC <hvr> there's a generic one though iirc <dolio> 0.11 introduced the generalized stream fusion, so there's like three different things going on that specialization has to select one of. <dolio> Instead of just one thing like in 0.10. <dolio> Anyhow, the problem file(s) generate a bunch of tests using template Haskell, so they're pretty opaque. <dolio> I'm pretty sure it's the generated code that's the problem, though. <dolio> Not the template haskell that generates it. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10800> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9066: Template Haskell cannot splice an infix declaration for a data constructor
by GHC 13 Apr '17

13 Apr '17

#9066: Template Haskell cannot splice an infix declaration for a data constructor ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I say {{{ $([d| data Blargh = (:<=>) Int Int infix 4 :<=> |]) }}} I get {{{ Illegal variable name: ‘:<=>’ When splicing a TH declaration: infix 4 :<=>_0 }}} The code inside the TH quote works when not used with TH. I will fix in due course. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9066> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10109: Kinds aren't checked in the coverage condition
by GHC 13 Apr '17

13 Apr '17

#10109: Kinds aren't checked in the coverage condition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Following on from the debate in #9103 (but you don't need to read that ticket), I found a curiosity. The following module fails to compile, complaining about the unsatisfied coverage condition: {{{ {-# LANGUAGE PolyKinds, MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, UndecidableInstances #-} module Bug where data Succ a class Add (a :: k1) (b :: k2) (ab :: k3) | a b -> ab, a ab -> b instance (Add a b ab) => Add (Succ a) b (Succ ab) }}} With `-fprint-explicit-kinds`, I get {{{ Bug.hs:9:10: Illegal instance declaration for ‘Add * k * (Succ k a) b (Succ k ab)’ The liberal coverage condition fails in class ‘Add’ for functional dependency: ‘a b -> ab’ Reason: lhs types ‘Succ k a’, ‘b’ do not jointly determine rhs type ‘Succ k ab’ In the instance declaration for ‘Add (Succ a) b (Succ ab)’ }}} But, when I add `k3` to the right-hand side of the first functional dependency (viz. {{{ {-# LANGUAGE PolyKinds, MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, UndecidableInstances #-} module Bug where data Succ a class Add (a :: k1) (b :: k2) (ab :: k3) | a b -> ab k3, a ab -> b instance (Add a b ab) => Add (Succ a) b (Succ ab) }}} ) I get {{{ [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, modules loaded: Bug. }}} I always assumed that fixing a type in a fundep also fixed its kind. I get the same behavior in 7.8 as in 7.10.1RC2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10109> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10564: GHC 7.10.2 RC cannot build HList-0.4.0.0
by GHC 13 Apr '17

13 Apr '17

#10564: GHC 7.10.2 RC cannot build HList-0.4.0.0 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Another Stackage find: http://lpaste.net/135061 {{{ Data/HList/Record.hs:575:10: Illegal instance declaration for ‘HasFieldM l (r xs) v’ The liberal coverage condition fails in class ‘HasFieldM’ for functional dependency: ‘l r -> v’ Reason: lhs types ‘l’, ‘r xs’ do not jointly determine rhs type ‘v’ In the instance declaration for ‘HasFieldM l (r xs) v’ Data/HList/Record.hs:587:10: Illegal instance declaration for ‘HasField l (Record (Tagged l1 v1 : r)) v’ The liberal coverage condition fails in class ‘HasField’ for functional dependency: ‘l r -> v’ Reason: lhs types ‘l’, ‘Record (Tagged l1 v1 : r)’ do not jointly determine rhs type ‘v’ In the instance declaration for ‘HasField l (Record (Tagged l1 v1 : r)) v’ Data/HList/Record.hs:646:10: Illegal instance declaration for ‘HDeleteAtLabel Record l v v'’ The liberal coverage condition fails in class ‘HDeleteAtLabel’ for functional dependency: ‘l v -> v'’ Reason: lhs types ‘l’, ‘v’ do not jointly determine rhs type ‘v'’ In the instance declaration for ‘HDeleteAtLabel Record l v v'’ Data/HList/Record.hs:723:10: Illegal instance declaration for ‘HUpdateAtLabel2 l v (Tagged l' e : xs) xs'’ The liberal coverage condition fails in class ‘HUpdateAtLabel2’ for functional dependency: ‘l r v -> r'’ Reason: lhs types ‘l’, ‘Tagged l' e : xs’, ‘v’ do not jointly determine rhs type ‘xs'’ In the instance declaration for ‘HUpdateAtLabel2 l v (Tagged l' e : xs) xs'’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10564> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10570: Too restrictive liberate coverage condition
by GHC 13 Apr '17

13 Apr '17

#10570: Too restrictive liberate coverage condition -------------------------------------+------------------------------------- Reporter: danilo2 | 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: | -------------------------------------+------------------------------------- Hello! Let's look at this small example: {{{haskell class ConsByIdx2 x a m cls | x -> m where consByIdx2 :: x -> a -> m cls instance ConsByIdx2 Int a Proxy cls where consByIdx2 _ _ = Proxy }}} It fails to compile with the following error: {{{haskell Illegal instance declaration for ‘ConsByIdx2 Int a Proxy cls’ The liberal coverage condition fails in class ‘ConsByIdx2’ for functional dependency: ‘x -> m’ Reason: lhs type ‘Int’ does not determine rhs type ‘Proxy’ In the instance declaration for ‘ConsByIdx2 Int a Proxy cls’ }}} But Int determines the Proxy in a nice way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10570> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10797: Kind-level functional dependencies are not resolved properly
by GHC 13 Apr '17

13 Apr '17

#10797: Kind-level functional dependencies are not resolved properly -------------------------------------+------------------------------------- Reporter: danilo2 | 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: | -------------------------------------+------------------------------------- Hello! Let's consider such funny class and its instances. {{{ {-# LANGUAGE PolyKinds #-} ... class BaseType (a :: k) (b :: l) | a -> b, k -> l where baseType :: Proxy a -> Proxy b instance BaseType (a :: j -> k) (out :: l) => BaseType (a (t :: j) :: k) (out :: l) }}} The instance does not compile: {{{ Illegal instance declaration for ‘BaseType (a t) out’ The liberal coverage condition fails in class ‘BaseType’ for functional dependency: ‘k -> l’ Reason: lhs type ‘k’ does not determine rhs type ‘l’ In the instance declaration for ‘BaseType (a (t :: j) :: k) (out :: l)’ }}} While the LHS determines the RHS. The problem is that it seems, that GHC doesn't infer the functional dependency of {{{k ~> l}}} from the dependency {{{j -> k ~> l}}}.. I've used a {{{~>}}} arrow to indicate fundeps. Is this a bug or am I missing something? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10797> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6