August 2015 - ghc-tickets

[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

[GHC] #10748: Associated type families regression
by GHC 07 Aug '15

07 Aug '15

#10748: Associated type families regression -------------------------------------+------------------------------------- Reporter: slyfox | 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: | -------------------------------------+------------------------------------- The original code snippet is taken from synthesizer-core-0.7.1 from hackage: http://code.haskell.org/synthesizer/core/src/Synthesizer/Causal/Class.hs Here is the minimal example: {{{#!hs {-# LANGUAGE TypeFamilies #-} module M where class ProcessOf (SignalOf process) ~ process => C process where type SignalOf process :: * -> * type ProcessOf (signal :: * -> *) :: * -> * -> * }}} {{{ $ ghc -c M.hs M.hs:4:1: The associated type ‘ProcessOf’ mentions none of the type or kind variables of the class ‘C process’ In the class declaration for ‘C’ }}} ghc-7.8.4 was able to compile this. Is it a known new restriction of ghc or a regression? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10748> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

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 oerjan): Oh hm, of course, purging that easily only works when the type family isn't imported from a module. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7102#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10609: Make up instances
by GHC 07 Aug '15

07 Aug '15

#10609: Make up instances -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following instances are missing as of now. * Foldable ZipList * Traversable ZipList * Functor Complex * Foldable Complex * Traversable Complex * Applicative Complex * Monad Complex * Monoid a => Monoid (Identity a) Original discussion: https://mail.haskell.org/pipermail/libraries/2015-June/025886.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10609> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

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 oerjan): Since you said not to mind Safe Haskell, I also found a similar unsoundness that uses loading of modules instead. All the modules can be `Safe`, but GHCi itself cannot have the flag set. {{{ {-# LANGUAGE Safe, TypeFamilies #-} module T1 where type family T a b }}} {{{ {-# LANGUAGE Safe, TypeFamilies #-} module T2 where import T1 type instance T a b = a from :: a -> T a b from = id }}} {{{ {-# LANGUAGE Safe, TypeFamilies #-} module T3 where import T1 type instance T a b = b to :: T a b -> b to = id }}} Now in GHCi: {{{ Prelude> :l T2 T3 [1 of 3] Compiling T1 ( T1.hs, interpreted ) [2 of 3] Compiling T3 ( T3.hs, interpreted ) [3 of 3] Compiling T2 ( T2.hs, interpreted ) Ok, modules loaded: T2, T1, T3. *T2> :m +T3 *T2 T3> let uc = to . from *T2 T3> uc 'a' :: Int 97 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7102#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7919: Heap corruption (segfault) from large 'let' expression
by GHC 07 Aug '15

07 Aug '15

#7919: Heap corruption (segfault) from large 'let' expression -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: rts/T7919 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1113 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7919#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0