September 2017 - ghc-tickets

[GHC] #14195: Generalize makeStableName#
by GHC 07 Sep '17

07 Sep '17

#14195: Generalize makeStableName# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: low | 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: -------------------------------------+------------------------------------- The function `makeStableName#` has the following type: {{{ makeStableName# :: a -> State# RealWorld -> (#State# RealWorld, StableName# a#) }}} I believe that it could safely be changed to: {{{ makeStableName# :: a -> State# s -> (#State# s, StableName# a#) }}} Currently, I have some code that looks like this: {{{ {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module Example ( Stable , stabilize , destabilize ) where import GHC.Prim import GHC.ST data Stable s a = Stable (StableName# a) a stabilize :: a -> ST s (Stable s a) stabilize a = ST $ \ s -> case makeStableName# a (unsafeCoerce# s) of (# s', sn #) -> (# unsafeCoerce# s', Stable sn a #) destabilize :: Stable s a -> a destabilize (Stable _ a) = a instance Eq a => Eq (Stable s a) where Stable sn1 a1 == Stable sn2 a2 = case eqStableName# sn1 sn2 of 0# -> a1 == a2 _ -> True }}} I want to be working in `ST`, not in `IO`, and I believe that this use of `unsafeCoerce#` is safe. However, it would be nice to not have to use it at all. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14195> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14194: ghci 8.0.2 panics
by GHC 07 Sep '17

07 Sep '17

#14194: ghci 8.0.2 panics -------------------------------------+------------------------------------- Reporter: jakubdaniel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I know it is rather hard to replicate but (I currently cannot check whether it still occurs in 8.0.2+): git clone https://github.com/jakubdaniel/expressions git clone https://github.com/jakubdaniel/expressions-z3 hg clone https://bitbucket.org/jd823592/z3-haskell cd expressions-z3 cabal sandbox init cabal sandbox add-source ../expression cabal sandbox add-source ../z3-haskell cabal install && cabal exec ghci λ> -- forget to :set -XTypeInType λ> :m Z3.Monad Data.Expression λ> -- forget to :m Data.Expression.Z3 λ> evalZ3 $ astToString =<< toZ3 (forall [var "x" :: Var 'IntegralSort] (exists [var "y" :: Var 'IntegralSort] (var "x" .+. var "y" .=. cnst 0)) :: Lia 'BooleanSort) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] toZ3_a4CL :: t_a4CK[tau:1] (CHoleCan: toZ3) [W] toZ3_a4Dx :: t_a4Dw[tau:1] (CHoleCan: toZ3)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14194> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10365: Make Semigroup as a superclass of Monoid
by GHC 07 Sep '17

07 Sep '17

#10365: Make Semigroup as a superclass of Monoid -------------------------------------+------------------------------------- Reporter: gidyn | 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: | -------------------------------------+------------------------------------- See http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a -superclass-of-Monoid-td5767835.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10365> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45

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 05 Sep '17

05 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 05 Sep '17

05 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 05 Sep '17

05 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 05 Sep '17

05 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 05 Sep '17

05 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