November 2014 - ghc-tickets

[GHC] #9633: PolyKinds in 7.8.2 vs 7.8.3
by GHC 03 Nov '14

03 Nov '14

#9633: PolyKinds in 7.8.2 vs 7.8.3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: PolyKinds | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code '''compiles''' with GHC 7.8.2. This code has been distilled down from a larger example where I needed `-XPolyKinds` in Bar.hs but not in Foo.hs. In addition, the `modify` function is supposed to modify a mutable `Data.Vector`, hence the inner `go` function has the intended type of `Int -> m ()`, though strictly speaking it could return any value since everything is discarded by the `forM_`. {{{ -- {-# LANGUAGE PolyKinds #-} module Foo where import Control.Monad (forM_) import Control.Monad.Primitive import Bar -- Vector signatures unsafeRead :: (PrimMonad m) => v (PrimState m) a -> Int -> m a unsafeRead = error "type only" unsafeWrite :: (PrimMonad m) => v (PrimState m) a -> Int -> a -> m () unsafeWrite = error "type only" modify :: Int -> Bar v r modify p = Bar (p-1) $ \y -> do let go i = do a <- unsafeRead y i unsafeWrite y i a --return a forM_ [0..(p-1)] go }}} {{{ {-# LANGUAGE RankNTypes, PolyKinds #-} module Bar where import Control.Monad.Primitive data Bar v r = Bar Int (forall s . (PrimMonad s) => v (PrimState s) r -> s ()) }}} In 7.8.3, this above code results in the error (with `-fprint-explicit- kinds`) {{{ Foo.hs:19:23: Couldn't match type ‘a0’ with ‘r’ ‘a0’ is untouchable inside the constraints (PrimMonad m, (~) * (PrimState m) (PrimState s)) bound by the inferred type of go :: (PrimMonad m, (~) * (PrimState m) (PrimState s)) => Int -> m () at Foo.hs:(18,7)-(20,23) ‘r’ is a rigid type variable bound by the type signature for modify :: Int -> Bar * v r at Foo.hs:16:11 Expected type: v0 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ‘unsafeRead’, namely ‘y’ In a stmt of a 'do' block: a <- unsafeRead y i Foo.hs:20:19: Couldn't match type ‘v1’ with ‘v’ ‘v1’ is untouchable inside the constraints (PrimMonad m, (~) * (PrimState m) (PrimState s)) bound by the inferred type of go :: (PrimMonad m, (~) * (PrimState m) (PrimState s)) => Int -> m () at Foo.hs:(18,7)-(20,23) ‘v’ is a rigid type variable bound by the type signature for modify :: Int -> Bar * v r at Foo.hs:16:11 Expected type: v1 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ‘unsafeWrite’, namely ‘y’ ... Failed, modules loaded: Bar. }}} After much digging, I found that enabling `-XPolyKinds` in Foo.hs gives a more meaningful error: {{{ Foo.hs:19:23: Could not deduce ((~) (* -> k -> *) v v0) ... Expected type: v0 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ‘unsafeRead’, namely ‘y’ In a stmt of a 'do' block: a <- unsafeRead y i Foo.hs:20:19: Could not deduce ((~) (* -> k -> *) v v1) ... Expected type: v1 (PrimState m) a0 Actual type: v (PrimState s) r ... In the first argument of ‘unsafeWrite’, namely ‘y’ In a stmt of a 'do' block: unsafeWrite y i a Failed, modules loaded: Bar. }}} Adding `PolyKinds` to Foo.hs ''and'' uncommenting `return a` results in the error: {{{ Foo.hs:17:12: Couldn't match kind ‘k’ with ‘k1’ because type variable ‘k1’ would escape its scope This (rigid, skolem) type variable is bound by the type signature for modify :: Int -> Bar k1 v r at Foo.hs:16:11-24 Expected type: Bar k1 v r Actual type: Bar k v0 r0 ... In the expression: Bar (p - 1) $ \ y -> do { let ...; forM_ [0 .. (p - 1)] go } ... Foo.hs:18:7: Kind incompatibility when matching types: v0 :: * -> k -> * v1 :: * -> * -> * ... When checking that ‘go’ has the inferred type ‘forall (k :: BOX) (m :: * -> *) b (v :: * -> * -> *) (v1 :: * -> * -> *). ((~) (* -> k -> *) v0 v, (~) k r0 b, (~) (* -> k -> *) v0 v1, PrimMonad m, (~) * (PrimState m) (PrimState s)) => Int -> m b’ Probable cause: the inferred type is ambiguous In the expression: do { let go i = ...; forM_ [0 .. (p - 1)] go } ... Failed, modules loaded: Bar. }}} These errors can be resolved by modifying the original code above in any of the following ways: 1. Remove `-XPolyKinds` from Bar.hs 2. Add an explicit kind signature to the `v :: * -> * -> *` parameter of type `Bar` 3. With `PolyKinds` in Bar but *not* Foo, uncommenting `return a` make GHC 7.8.3. compile What I'm trying to understand is 1. Why there is different behavior from 7.8.2 to 7.8.3. There doesn't seem to be anything addressing `PolyKinds` in the [http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/release-7-8-3.html release notes vs 7.8.2] . 2. In the event the above code should not compile with 7.8.3, there error message could be much clearer. The first error message above didn't help me understand that `PolyKinds` was to blame, while the second error did a better job, and the third was very clearly a `PolyKinds` issue (i.e. `kind mismatch`) 3. For the third resolution option above, I can't see any reason that adding `return a` to the inner `go` function should make the code compile while leaving it out makes the code somehow ambiguous. This, if nothing else, seems like a bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9633> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9433: Partially applied type family allowed but unusable
by GHC 03 Nov '14

03 Nov '14

#9433: Partially applied type family allowed but unusable -------------------------------------+------------------------------------- Reporter: hesselink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | accepts invalid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I was playing around with the following code, which tries to map a type family over a type (something I thought would not be allowed): {{{#!hs {-# LANGUAGE TypeFamilies , KindSignatures #-} type family Id x :: * type instance Id a = a type family Map (f :: * -> *) x :: * type instance Map f [a] = [f a] x :: Map Id [Bool] x = [] }}} Both GHC 7.8.3 and the current HEAD (7.9.20140811) accept this program! However, changing the definition of `x` to `[True]` gives an error: {{{ Couldn't match type ‘Id Bool’ with ‘Bool’ Expected type: Map Id [Bool] Actual type: [Bool] In the expression: [True] In an equation for ‘x’: x = [True] }}} If I define `y :: Id Bool` with value `True` (which works fine) and define `x = [y]`, I even get this error: {{{ Couldn't match type ‘Bool’ with ‘Id Bool’ Expected type: Id Bool Actual type: Id Bool In the expression: y In the expression: [y] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9433> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2
by GHC 03 Nov '14

03 Nov '14

#8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 -----------------------------------+--------------------------------------- Reporter: MichalGajda | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: cabal install hPDB Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- GHC 7.8 rc2 exhausts all memory on `Bio.PDB.EventParser.PDBEventParser` module in -O3 mode, but not in -O2 mode. The tail of ''-v3'' input seems to indicate that it dies during SpecConstr phase. The module successfully compiled with below 2GB RAM since GHC 6.12, so I wonder why the memory use exploded with the most recent version. *** SpecConstr: ==================== SpecConstr ==================== Result size of SpecConstr STEPS TO REPRODUCE: 1. `cabal install hPDB` RESULT EXPECTED: Successful compilation and installation CURRENT RESULT: Exhausts available memory and crashes when compiling `Bio.PDB.EventParser.PDBEventParser`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8960> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9658: Prettyprint constraints in type signatures can omit necessary parentheses
by GHC 03 Nov '14

03 Nov '14

#9658: Prettyprint constraints in type signatures can omit necessary parentheses -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: Type: bug | Status: new Priority: low | Milestone: 7.8.4 Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Other hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- GHCi prettyprinting can omit parentheses around constraints, even when they are necessary for the signature to be syntactically valid. This breaks the workflow where one uses type inference to generate type annotations to add to the program. Admittedly, this is nitpicking, but it'd be nice to fix. The example I'm running into is the following (in the context of https://github.com/Blaisorblade/learning- syntactic/blob/e198381e07103d436f4ade24f36d344682dbe5b1/src/Syntactic.hs): {{{#!hs num = inj . Num > :t num num :: NUM :<: sup => Int -> sup (Full Int) }}} Adding the type annotation in gives: {{{ src/Syntactic.hs:115:20: parse error on input `=>' }}} To fix the parse error, I need to add parentheses around the constraint: {{{#!hs num :: (NUM :<: sup) => Int -> sup (Full Int) }}} (Here this happens to be the wrong type signature, but that's orthogonal). I imagine that's just because the constraint uses an operator (probably only possible with TypeOperators). This happens whether I explicitly supply the signature or not, and it also happens on GHC 7.6.3. Misc: I selected milestone, difficulty, priority because it's possible and because fixing this sounds easy; sorry if I shouldn't have. I also didn't check whether this affects HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9658> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8819: Testsuite failures in 7.8 RC1
by GHC 03 Nov '14

03 Nov '14

#8819: Testsuite failures in 7.8 RC1 ------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- With the recent patches applied to RC1 I managed to bootstrap an unregisterised ghc. Running the testsuite I get the following failures on Linux x86_64: {{{ Unexpected failures: ../../libraries/base/tests fixed [bad stdout] (normal) ../../libraries/base/tests/Numeric num010 [bad stdout] (normal) ../../libraries/process/tests process007 [bad exit code] (normal) codeGen/should_compile T7574 [stderr mismatch] (normal) codeGen/should_gen_asm memcpy [asm mismatch] (normal) codeGen/should_gen_asm memcpy-unroll [asm mismatch] (normal) codeGen/should_gen_asm memcpy-unroll-conprop [asm mismatch] (normal) codeGen/should_run T2838 [bad stdout] (normal) lib/integer integerBits [bad stdout] (normal) lib/integer integerConversions [bad stdout] (normal) numeric/should_run T8726 [bad exit code] (normal) numeric/should_run arith002 [bad stdout] (normal) numeric/should_run arith003 [bad stdout] (normal) numeric/should_run arith004 [bad stdout] (normal) numeric/should_run arith005 [bad stdout] (normal) numeric/should_run arith011 [bad stdout] (normal) numeric/should_run arith012 [bad stdout] (normal) numeric/should_run arith014 [bad stdout] (normal) parser/should_run readRun002 [bad stdout] (normal) perf/compiler T1969 [stat too good] (normal) perf/compiler T3064 [stat too good] (normal) perf/compiler T783 [stat too good] (normal) perf/should_run T3736 [bad stderr] (normal) rts T5423 [bad stderr] (normal) rts T7815 [bad exit code] (threaded1) safeHaskell/check/pkg01 safePkg01 [bad stderr] (normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8819> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8849: Unregisterised compiler: arithmetic failure
by GHC 03 Nov '14

03 Nov '14

#8849: Unregisterised compiler: arithmetic failure --------------------------+------------------------------------------------ Reporter: | Owner: trommler | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.1-rc2 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect result at runtime Keywords: | Test Case: arith005 Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: #8819 | --------------------------+------------------------------------------------ Compiling the following with RC2 on powerpc 64 downloaded from haskell.org: {{{ main = putStr $ show (-1.0000000001 :: Double) }}} Setting {{{-O}}} yields: {{{ 0.0 }}} Without optimization the correct result is displayed. I prepared an unregisterised compiler on amd64 and see the same issue and more arithmetic tests fail in testsuite. In fact I took the above from arith005. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8849> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9345: Data.List.inits is extremely slow
by GHC 03 Nov '14

03 Nov '14

#9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Difficulty: Easy (less Test Case: | than 1 hour) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- As discussed on libraries(a)haskell.org, `Data.List.inits` is extremely slow (try running `print $ length $ inits [1..100000]` if you don't believe me). As discussed, there are at least two reasonable fixes. One of them (named `initsR` in the attached) is a one-liner and gives very good performance in general, but poor performance in certain cases that may or may not appear in real code. The other (named `initsQ` in the attached) is slightly more complex and slightly slower in general, but its performance appears to be robust. I would personally lean toward `initsQ` for `Data.List`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9345> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34

Re: [GHC] #110: Cygwin binaries
by GHC 03 Nov '14

03 Nov '14

#110: Cygwin binaries -------------------------------------+------------------------------------- Reporter: fizzgig | Owner: Type: feature | Status: closed request | Milestone: ⊥ Priority: lowest | Version: None Component: None | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: None => wontfix -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/110#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #110: Cygwin binaries
by GHC 03 Nov '14

03 Nov '14

#110: Cygwin binaries -------------------------------------+------------------------------------- Reporter: fizzgig | Owner: Type: feature | Status: new request | Milestone: ⊥ Priority: lowest | Version: None Component: None | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * priority: normal => lowest -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/110#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9754: Fix Applicative instances in the wake of AMP
by GHC 03 Nov '14

03 Nov '14

#9754: Fix Applicative instances in the wake of AMP -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.8.3 Keywords: AMP | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I haven't tracked down all the problems yet, but several experiments leading to validation failures strongly suggest that some `Applicative` instances in the GHC tree fail to interact properly with their associated `Monad` instances. That is, `ap ≠ (<*>)` and/or `(>>) ≠ (*>)`. We should be able to fix these up by fleshing out the appropriate instance declarations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9754> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1