- ghc-tickets - Haskell.org

Re: [GHC] #1460: Problem with Monoid instance of Data.Map
by GHC 06 Sep '17

06 Sep '17

#1460: Problem with Monoid instance of Data.Map -------------------------------------+------------------------------------- Reporter: ahey@… | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Resolution: fixed | Keywords: Data.Map | Monoid Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by andrewthad): * cc: andrewthad (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1460#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14187: Transpose hangs on infinite by finite lists
by GHC 06 Sep '17

06 Sep '17

#14187: Transpose hangs on infinite by finite lists -------------------------------------+------------------------------------- Reporter: utikeev | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: transpose | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found out that this code {{{#!hs take 5 $ map (take 3) (transpose (repeat [0..1])) }}} isn't equivalent to this one {{{#!hs take 5 $ map (take 3) [[0,0..], [1,1..]] }}} The second piece of code gives expectable output of {{{[[0,0,0],[1,1,1]]}}}, while first one just hangs with outpit {{{[[0,0,0],[1,1,1],}}} also probably screwing up some descriptors after interruption with Ctrl+C (as in 8.2.1, didn't have such problem in 8.0.2. I attach the screenshot of my cmd after interruption and pressing Up and Down buttons randomly for a few times. The history seems to be broken). In my homework I had to make a function zipN, which is actually zipWith but for more than two lists. The solution which dealt with stuck was to write my own transpose and apply {{{takeWhile (not . null)}}} to the remaining part of transposed matrix. P.S.: {{{#!hs [[0,0..],[1,1..]] == transpose (repeat [0..1]) }}} also hangs ghci. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14187> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types
by GHC 06 Sep '17

06 Sep '17

#9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When we see `m >>= (\_ -> n)` with a type that admits an optimized `>>` or `<$`, we should try to take advantage of that. I don't currently know if this applies to any types under "GHC HQ" control. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9797> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10328: Control.Monad exports lead to weird Haddocks
by GHC 06 Sep '17

06 Sep '17

#10328: Control.Monad exports lead to weird Haddocks -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: Documentation Keywords: | bug Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `Control.Monad` exports, and therefore documents, the `Functor` class (but only the `fmap` member) and the `Monad` class. It does not export, and therefore does not document, the `Applicative` class. This is all pretty weird. Since `Functor` is in the prelude (and probably most/all alternate preludes), is there actually a reason to export it from `Control.Monad`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10328> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9756: Warn about unnecessary unsafeCoerce
by GHC 06 Sep '17

06 Sep '17

#9756: Warn about unnecessary unsafeCoerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `unsafeCoerce` has been around a lot longer than `coerce`, so older code tends to use it even if `coerce` could do the job. It would be nice if the type checker could produce a warning when it detected such a situation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13779: Add more signature suppression control for dumps
by GHC 06 Sep '17

06 Sep '17

#13779: Add more signature suppression control for dumps -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tend to find some type signatures essential when reading Core. However, `Generic`-heavy code can produce extremely large signatures. I suspect one or both of the following additional options could help: 1. An option to suppress non-top-level signatures, leaving top-level ones alone. 2. An option to suppress phantom type arguments in signatures. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13182: Rethinking dataToTag#
by GHC 06 Sep '17

06 Sep '17

#13182: Rethinking dataToTag# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We currently use a primop `dataToTag#` that requires some careful handling because it can only be applied to something that has already been evaluated. We (now) mark it `can_fail` to prevent it from floating out, and then add a fix-up pass in CorePrep just in case things went wrong. Could we do something simpler? Suppose we had {{{#!hs -- The real primop, preferably not exported from *anywhere*, but at least documented as never to be used outside GHC. secretDataToTag# :: a -> Int# -- A wired-in safe version dataToTag# :: a -> Int# dataToTag# !a = secretDataToTag# a {-# NOINLINE dataToTag# #-} }}} Then `dataToTag#` could be inlined in CorePrep, just like `runRW#`. === Questions === How would this interact with float out? It should be perfectly safe to float out when its argument is known to be forced, but it seems likely we'll run into let/app invariant failures. What RULES do we (or should we) have for `dataToTag#`? How will this change affect them? My vague recollection is that we don't have any, but it would be pretty nice to apply something equivalent to case-of-known- constructor. Whenever `dataToTag#` is applied to a known constructor, we should be able to evaluate it. The earlier we do this the better it will inform simplification. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14131: Difference between newtype and newtype instance
by GHC 05 Sep '17

05 Sep '17

#14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This works {{{#!hs {-# Language RankNTypes, PolyKinds, GADTs #-} newtype Nat :: (k -> *) -> (k -> *) -> * where Nat :: (forall xx. f xx -> g xx) -> Nat f g }}} but this {{{#!hs {-# Language RankNTypes, PolyKinds, GADTs, TypeFamilies #-} data family Nat :: k -> k -> * newtype instance Nat :: (k -> *) -> (k -> *) -> * where Nat :: (forall xx. f xx -> g xx) -> Nat f g }}} fails on GHC 8.3.20170815, and requires a `forall k.` to work {{{ $ ./ghc-stage2 -ignore-dot-ghci --interactive /tmp/kind.hs GHCi, version 8.3.20170815: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/kind.hs, interpreted ) /tmp/kind.hs:5:26: error: Not in scope: type variable ‘k’ | 5 | newtype instance Nat :: (k -> *) -> (k -> *) -> * where | ^ /tmp/kind.hs:5:38: error: Not in scope: type variable ‘k’ | 5 | newtype instance Nat :: (k -> *) -> (k -> *) -> * where | ^ Failed, 0 modules loaded. }}} Related to #12369? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #13985: GHC 8.0 regression: ‘k’ is not in scope during type checking, but it passed the renamer
by GHC 05 Sep '17

05 Sep '17

#13985: GHC 8.0 regression: ‘k’ is not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #13738 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Proxy data family Fam data instance Fam = MkFam (forall (a :: k). Proxy a) }}} On GHC 8.0.1, 8.0.2, 8.2.1, and HEAD, this fails with a GHC internal error: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:9:41: error: • GHC internal error: ‘k’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r1vy :-> APromotionErr FamDataConPE] • In the kind ‘k’ In the type ‘(forall (a :: k). Proxy a)’ In the definition of data constructor ‘MkFam’ | 9 | data instance Fam = MkFam (forall (a :: k). Proxy a) | ^ }}} This is a regression, since on GHC 7.10.3, it did not crash: {{{ $ /opt/ghc/7.10.3/bin/ghci Bug.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:9:21: Data constructor ‘MkFam’ has existential type variables, a context, or a specialised result type MkFam :: forall (k :: BOX). (forall (k :: BOX) (a :: k). Proxy a) -> Fam (Use ExistentialQuantification or GADTs to allow this) In the definition of data constructor ‘MkFam’ In the data instance declaration for ‘Fam’ }}} This smells like #13738, but no `TypeApplications` are involved here, so I decided to open a separate ticket to be safe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13985> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9574: GHC Panic: No Skolem Info
by GHC 05 Sep '17

05 Sep '17

#9574: GHC Panic: No Skolem Info -------------------------------------+------------------------------------- Reporter: ian_mi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- GHC 7.8.3 and from git both panic with Couldn't match kind ‘o1’ with ‘(,) o o’ ‘o1’ is untouchable inside the constraints (Object (c :><: c) a) bound by a type expected by the context: Object (c :><: c) a => Tagged a (c (FMap (ProductF c) a) (FMap (Proj2 c c) a)) at Product.hs:35:9-15ghc: panic! (the 'impossible' happened) (GHC version 7.9.20140908 for x86_64-unknown-linux): No skolem info: o1_a6XS I have not yet attempted to reduce the problem at all. The offending code is the use of fmap here: {{{#!hs proj2 :: forall (c :: o -> o -> *). ProductCategory c => NatTr (c :><: c) c (ProductF c) (Proj2 c c) proj2 = NatTr t where NatTr t = fmap (CompF Proj2 IdentityF) e e :: NatTr (c :><: c) (c :><: c) (Comp ('KProxy :: KProxy o) (Diag c) (ProductF c)) (IdentityF (c :><: c)) e = counit }}} fmap is defined as {{{#!hs fmap :: forall f (a :: o1) (b :: o1). Functor f ('KProxy :: KProxy (o1 -> o2)) => f -> Domain f a b -> Codomain f (FMap f a :: o2) (FMap f b :: o2) fmap _ = proxy morphMap (Proxy :: Proxy f) }}} while CompF is defined by {{{#!hs data CompF f g (k :: KProxy (o3 -> o4, o1 -> o2)) where CompF :: (Functor f ('KProxy :: KProxy (o3 -> o4)), Functor g ('KProxy :: KProxy (o1 -> o2))) => f -> g -> CompF f g ('KProxy :: KProxy (o3 -> o4, o1 -> o2)) }}} This makes some sense because there is a functional dependency between the functor and the kind proxy. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9