April 2013 - ghc-tickets

[GHC] #7804: Ambiguity check too eager in presence of RankNTypes and TypeFamilies
by GHC 03 Apr '13

03 Apr '13

#7804: Ambiguity check too eager in presence of RankNTypes and TypeFamilies --------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: AmbiguityCheck Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- The following code compiles in 7.6.1 but not in 7.7: {{{ {-# LANGUAGE TypeFamilies, RankNTypes #-} type family F f a type family G f data Proxy a = P sDFMap :: (forall a. Proxy f -> Proxy a -> Proxy (F f a)) -> Proxy (G f) sDFMap _ = P }}} Here is the error message: {{{ Couldn't match type `G f0' with `G f' NB: `G' is a type function, and may not be injective The type variable `f0' is ambiguous Expected type: (forall a. Proxy f -> Proxy a -> Proxy (F f a)) -> Proxy (G f) Actual type: (forall a. Proxy f0 -> Proxy a -> Proxy (F f0 a)) -> Proxy (G f0) In the ambiguity check for: forall f. (forall a. Proxy f -> Proxy a -> Proxy (F f a)) -> Proxy (G f) In the type signature for `sDFMap': sDFMap :: (forall a. Proxy f -> Proxy a -> Proxy (F f a)) -> Proxy (G f) }}} It is true that {{{sDFMap}}} is ''sometimes'' ambiguous, but it is not ''always'' ambiguous. For example, if we have {{{ foo :: Proxy Bool -> Proxy a -> Proxy (F Bool a) foo _ _ = P bar = sDFMap foo }}} the call to {{{sDFMap}}} is well defined, with {{{f ~ Bool}}}. If the type signature for {{{foo}}} did not specify the value of {{{f}}}, the call to {{{sDFMap}}} would indeed be ambiguous and should be rejected. GHC 7.6.1 does catch the error when the type of {{{foo}}} uses a variable instead of {{{Bool}}}. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7804> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7176: Failure to let kind variable remain uninstantiated when not needed
by GHC 03 Apr '13

03 Apr '13

#7176: Failure to let kind variable remain uninstantiated when not needed -------------------------------+-------------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.1-rc1 Resolution: fixed | Keywords: PolyKinds TypeFamilies Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: polykinds/T7176 | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by simonpj@…): commit 1128f1e02ff06fee89b62fb756ac0c28edcf4625 {{{ Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Wed Apr 3 14:37:50 2013 +0100 This changes fixes a bad error in canonicalisation, concerning kind equality We care careful not to construct a canonical equality whose LHS and RHS have incompatible kinds. (This is one of the invariants of a canonical equality.) See Note [Equalities with incompatible kinds]. However, what I had not dealt with is when LHS and RHS *look* as if they have different kinds, but after zonking they become the same. Bad! (This led to an ASSERT failure in the test for Trac #7176.) compiler/typecheck/TcCanonical.lhs | 111 +++++++++++++++++++++--------------- 1 files changed, 65 insertions(+), 46 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7176#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #427: Random.StdGen slowness
by GHC 03 Apr '13

03 Apr '13

#427: Random.StdGen slowness --------------------------------------+------------------------------------- Reporter: remit | Owner: rrnewton Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/random | Version: Resolution: None | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Comment(by joell): This ticket seems to be almost describing two separate issues: the performance of the random package and the "thunk-bomb" problem in `getStdRandom`. While I admit I haven't looked into the performance aspect, I am now well acquainted with the "thunk-bomb" aspect. Turns out a metrics library we were using at my company made a `randomRIO` call that in some cases (all of them in our configuration) wouldn't actually use the generated random value. This led to me spending a few days trying to figure out why our services were consuming and retaining gigabytes of memory. (For those interested in case studies, the discussion with the metrics library folks is here: https://github.com/brendanhay/network-metrics/issues/4 .) So I would like to petition that the change Remi suggested in comment:17 to make `getStdRandom` strict (or something along those lines) be made. To my mind (heavily biased by the experience of the last few days), I wouldn't really consider the "thunk-bomb" aspect a performance problem so much as a stability one. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/427#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5550: GHC infinite loop when compiling vector
by GHC 03 Apr '13

03 Apr '13

#5550: GHC infinite loop when compiling vector ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: merge Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.2.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: simplCore/should_compile/T5550 Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonpj): * testcase: => simplCore/should_compile/T5550 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5550#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #607: Ticky-ticky profiling
by GHC 02 Apr '13

02 Apr '13

#607: Ticky-ticky profiling -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: tim Type: task | Status: closed Priority: normal | Milestone: _|_ Component: Compiler | Version: None Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Difficult (2-5 days) Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: None => fixed -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/607#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0