- ghc-tickets - Haskell.org

[GHC] #9853: Stateful transformation causes non-termination in Hoopl analysis.
by GHC 08 Aug '15

08 Aug '15

#9853: Stateful transformation causes non-termination in Hoopl analysis. -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/hoopl | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It seems that Hoopl's analyses may apply rewrites to nodes multiple times without invoking the `restart` function between applications. This causes havoc for code transformations that have side-effects, for example a transformation that introduces a new variable to hold some intermediate result. In such an analysis, a transformation may introduce a new variable, which leads to a changed fact. Later the transformation may be run again, leading to a new fact, and so on (when there is a loop in the control flow. The attached example illustrates this problem. This example modifies the constant propagation pass provided in the testing directory of the hoopl library. The example added a new instruction called "Funny" that gets rewritten to an unconditional branch instruction and introduces a new variable. The main program P1 performs the analysis on a particular program that has a loop in the control flow graph and causes the hoopl analysis to run forever. Is this a bug in Hoopl? Ie. should analyses that have side-effects involving checkpointed state be supported? If not, could it be changed to support these analyses? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10540: Showing type synonym isn't exported by Hoopl
by GHC 08 Aug '15

08 Aug '15

#10540: Showing type synonym isn't exported by Hoopl -------------------------------------+------------------------------------- Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 libraries/hoopl | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: | warning at compile-time Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hoopl exports {{{#!hs showGraph :: Showing n -> Graph n e x -> String }}} But it doesn't export `Showing`. This doesn't make sense, as it's a user- supplied function. So to know what I should pass to `showGraph` I can only look at the source. `:i Showing` doesn't work. Below is a patch to export the innocent type synonym: {{{#!patch diff --git a/src/Compiler/Hoopl/Show.hs b/src/Compiler/Hoopl/Show.hs index 8a8b35f..66172b0 100644 --- a/src/Compiler/Hoopl/Show.hs +++ b/src/Compiler/Hoopl/Show.hs @@ -4,7 +4,7 @@ #endif module Compiler.Hoopl.Show - ( showGraph, showFactBase + ( showGraph, showFactBase, Showing ) where }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10540> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10757: ghci panic: floatExpr tick break<1062>()
by GHC 08 Aug '15

08 Aug '15

#10757: ghci panic: floatExpr tick break<1062>() -------------------------------------+------------------------------------- Reporter: kjslag | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: panic ghci | Operating System: Unknown/Multiple optimisation | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Loading a file with {-# OPTIONS -O #-} in ghci causes a panic. See details below. $ cat panic.hs {-# OPTIONS -O #-} main :: IO () main = return () $ ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> :load panic.hs [1 of 1] Compiling Main ( panic.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): floatExpr tick break<0>() Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10757> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5296: Add explicit type applications
by GHC 07 Aug '15

07 Aug '15

#5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: Related Tickets: | Differential Revisions: Phab:D1138 -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:18 simonpj]: > Can I tell, in GHCi, whether a particular function (perhaps in scope by being imported) is amenably to VTA? Perhaps `:info f` tells me? No. But there should be. `:info` would be easy to modify. But I think `:type` should indicate this as well somehow. > > For (2) I suggest just saying `(3 :: Int)`. There are more exciting things to do than allow "@" in place of "::". Yes, I suppose that's true. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5296#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5296: Add explicit type applications
by GHC 07 Aug '15

07 Aug '15

#5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: Related Tickets: | Differential Revisions: Phab:D1138 -------------------------------------+------------------------------------- Comment (by simonpj): Can I tell, in GHCi, whether a particular function (perhaps in scope by being imported) is amenably to VTA? Perhaps `:info f` tells me? For (2) I suggest just saying `(3 :: Int)`. There are more exciting things to do than allow "@" in place of "::". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5296#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10067: The Read Integer instance is too slow
by GHC 07 Aug '15

07 Aug '15

#10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: Runtime Keywords: | performance bug Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The current implementation of the Read Integer instance has quadratic complexity and thus performs badly on large inputs. On my system, it takes 65 seconds to perform the following: {{{#!hs read (take 1000000 $ cycle "1234567890") :: Integer }}} Note that we already provide an ad-hoc instance for Show Integer, so maybe we can do the same for Read Integer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10067> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

Re: [GHC] #5296: Add explicit type applications
by GHC 07 Aug '15

07 Aug '15

#5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: Related Tickets: | Differential Revisions: Phab:D1138 -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire * differential: => Phab:D1138 * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple Comment: Patch available now, at Phab:D1138 and at branch `wip/type-app`. There are implementation notes in Phab. Here are some design notes: * There is no explicit ''kind'' instantiation. It just won't parse! This will be fixed along with Phab:D808. * The new extension `TypeApplications` implies `AllowAmbiguousTypes`. This makes sense, because in the presence of visible type application, there is really no such thing as an ambiguous type. * Suppose there is no `Eq` instance for `T` and `a,b :: T`. The expression `a == b` is clearly ill-typed. Previously, the error was reported on the `==`. Now it's reported on the whole expression. I think this makes sense. I have two open design questions: 1. What to do with `:type` in GHCi? Suppose we have `pair :: forall a. a -> forall b. b -> (a,b)`. I ask `:type pair 3`. The real type of this expression is `forall b. b -> (a0, b)`, where `a0` is the type of the overloaded `3`. The problem is that this type loses the fact that we need `Num a0`. We could say `forall b. Num a0 => b -> (a0, b)`, which is a little closer. Would we report that without `-fprint-explicit-foralls`? It would be wrong to say `forall a b. Num a => b -> (a, b)` (as is done today, even with this patch) because we can't instantiate `a` with a further visible type application. 2. It would be nice to be able to say `3 @Int` instead of `(3 :: Int)`. But this doesn't work out. Writing `3` in code really means `fromInteger $3` (where `$3` is the internal representation for the `Integer` 3). `fromInteger` comes from the `Num` class; it has type `forall a. Num a => Integer -> a`. So, we would want `3 @Int` to really become `fromInteger @Int $3`. But this is hard to arrange for. Alternatively, we could change `fromInteger` to have type `Integer -> forall a. Num a => a`, which would work swimmingly. But we can't do this, because class methods always have their class variables quantified first. Making this change would mean writing a wrapper around `fromInteger`: {{{ fromIntegerVta :: Integer -> forall a. Num a => a fromIntegerVta = fromInteger }}} Interpreting overloaded numbers in Haskell source would then use `fromIntegerVta`. But this is all a little painful. Is it worth it to have `3 @Int`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5296#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10753: Type checker fails to recognize equality
by GHC 07 Aug '15

07 Aug '15

#10753: Type checker fails to recognize equality -------------------------------------+------------------------------------- Reporter: ljli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE KindSignatures #-} module Test where import qualified Control.Monad.State as S class HasConns (m :: * -> *) where type Conn m foo :: (HasConns m, Monad m) => S.StateT (Conn m) m () foo = do _ <- S.get return () }}} This fails to compile with GHC 7.10.2: {{{ Could not deduce (S.MonadState (Conn m) (S.StateT (Conn m) m)) arising from a use of ‘S.get’ from the context (HasConns m, Monad m) bound by the type signature for foo :: (HasConns m, Monad m) => S.StateT (Conn m) m () }}} It compiles with GHC 7.8.4, though. Adding "Conn m ~ Conn m" to the type context of foo lets it compile again. This seems not right to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10753> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10340: Type inference regression with Any
by GHC 07 Aug '15

07 Aug '15

#10340: Type inference regression with Any -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following module typechecks with GHC 7.8.3, but GHC 7.10.1 gives an error: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} module Foo where import GHC.Exts (Any) class MonadState s m where get :: m s newtype State s a = State (s -> (s, a)) instance MonadState s (State s) where get = State $ \s -> (s, s) foo :: State Any Any foo = get }}} {{{ [1 of 1] Compiling Foo ( any.hs, any.o ) any.hs:15:7: No instance for (MonadState Any (State Any)) arising from a use of ‘get’ In the expression: get In an equation for ‘foo’: foo = get }}} If I replace the uses of `Any` with `Int`, the problem goes away. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10340> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7102: Type family instance overlap accepted in ghci
by GHC 07 Aug '15

07 Aug '15

#7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Eek. Of course GHCi should do an eager instance-overlap check when loading modules, just as GHC does. That is a serious bug. Again, nothign to do with Safe Haskell; your example works just as well without `{-# LANGUAGE Safe #-}`. Would anyone like to look at it? The code is all there, since it is used for dealing with imports in GHC. > I suspect the purging in (2) can already be achieved by just redeclaring the type family, after which new instances would refer to the new entity. Ah yes, that is true. Clever. So this is what would happen {{{ Prelude> type family T a b Prelude> type instance T a b = a Prelude> let uc :: a -> T a b; uc = id Prelude> type instance T a b = b ERROR: instance overlap -- User thinks: darn! Re-declare T Prelude> type family T a b -- This is a brand-new T, unrelated to the old one Prelude> uc 'a' :: Int <interactive>:6:1: error: Couldn't match type ‘Char’ with ‘Int’ Expected type: Int Actual type: Ghci1.T Char b0 }}} So, no need to add a new facility for purging. What we need is to reject overlap. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7102#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0