August 2017 - ghc-tickets

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

25 Aug '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: | -------------------------------------+------------------------------------- Comment (by bgamari): I agree that a monoidal-combining `Map` is much nicer than our current `Map` (and usually what I find I need); I have been a proponent of this change in the past and even maintain the `monoidal-containers` library wrapping `containers` with these semantics. However, my impression is that argument (1) mentioned in comment:8 alone is enough to sink this proposal in many people's minds. In fact, with a few years of experience behind me since last looking at this, I may even agree. I don't think it is realistic to expect that we will be able to easily discern broken packages in a large scale study; breakage due to semantic changes like this can be very hard to spot. In the best case you have a use-site where the value type has no `Semigroup` instance, in which case the change will elicit a compile-time error. However, in the case where you do have an instance on-hand you will see silent breakage, which may or may not be evident in the runtime behavior of the program or test failures. Moreover, with the ubiquity of packages with lax handling of upper bounds will likely make managing such a change challenging, even if breakage can be readily identified; even a super-major version bump will have no effect on a package that has no bounds at all. Unfortunately, I suspect the only way we can make this change happen is via the introduction of new interfaces and not changing those that we already have. This may be via continuing to use `monoidal-containers` and others (e.g. `reducers`), although I admit that this isn't a terribly great option. Perhaps we could discuss merging a wrapper like `monoidal- containers` into `containers` (and, perhaps, `unordered-containers`). The good news is that with Backpack we are now slightly better equipped to provide such parallel interfaces; unfortunately it will likely be several years before we can rely on Backpack for a critical package like `containers`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1460#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14137: Do more inlining into non-recursive join points
by GHC 25 Aug '17

25 Aug '17

#14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- In pursuing #14068, [https://phabricator.haskell.org/D3811#107745 Joahim says] found this code: {{{ let { ds5 :: [[Int]] ds5 = case ==# x1 ww1 of { __DEFAULT -> go1 (+# x1 1#); 1# -> n } } in join { lvl6 :: [[Int]] lvl6 = (ds4 : y) : ds5} in joinrec { safe :: Int -> Int -> [Int] -> [[Int]] safe (x2 :: Int) (d :: Int) (ds6 :: [Int]) = case ds6 of { [] -> jump lvl6; : q l -> case x2 of wild6 { I# x3 -> case q of { I# y1 -> case /=# x3 y1 of { __DEFAULT -> ds5; 1# -> case d of { I# y2 -> case /=# x3 (+# y1 y2) of { __DEFAULT -> ds5; 1# -> case /=# x3 (-# y1 y2) of { __DEFAULT -> ds5; 1# -> jump safe wild6 (I# (+# y2 1#)) l }}}}}} }; } in jump safe ds4 lvl y; } in ... }}} This is terrible! `lvl6` is a join point, but `ds5` is not. And it's easy to fix: we should simply float `ds5` into `lvl6`'s rhs. **Backgound**. In general, if GHC sees this {{{ -- Version A x = f x : g y }}} it'll float out the `(f x)` and `(g y)` parts thus (B): {{{ -- Version B a1 = f x a2 = g y x = a1 : a2 }}} Reasons: 1. In the scope of this binding we might have `case x of (a:b) -> rhs`, and the new form allows us to eliminate the case. 2. Version A builds a thunk (which, when eval'd) builds thunks for `(f x)` and `(g y)` and returns a cons; whereas Version B builds the two thunks ahead of time and allocates a cons directly. If `x` gets evaluated this is a win, by avoiding an extra thunk. We measured this in our let- floating paper, and B is much better on average. But if `x` is a join point, all this is wrong wrong wrong: 1. A join point is never scrutinised by a nested case, so there is no benefit in floating. 2. A join point is not implemented by a thunk, so there is no thunk alloc/update to avoid. In fact, for join points we want to turn Version B into Version A! Specifically: * In `Simplify`, do not call `prepareRhs` on join RHSs; nor do floating (see `tick LetFloatFromLet`) from the RHS of a join. In fact this seems to be already the case. * In `OccurAnal`, do not use `rhsCtxt` for the RHS of a non-recursive join point (see `occAnalNonRecRhs`). Setting this context makes `a1` and `a2` get "inside-lam" occurrences (see `occAnalApp`), and that in turn stops `a1` and `a2` getting inlined straight back into `x`'s RHS in Version B. But for join points we **want** them to be inlined, to get back to Version A. For a recursive join point we probably do not want to inline `a1` and `a2` because then they'd be allocated each time round the loop. But in fact we can't have a recursive join point whose RHS is just a cons, so it doesn't really arise. The point is: we only need to take care with `rhsCtxt` for non-recursive join points. Bottom line: just that one fix to `OccurAnal` should do the job. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14137> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

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

25 Aug '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: | -------------------------------------+------------------------------------- Comment (by andrewthad): What I'm trying to argue is that the two possible `Monoid` instances for `Map` aren't really equal in terms of how much they buy you. Let's look at merging nested `Map`s again. The question here is "how much code do I have to write to merge these?" Both for a deep merge and for a shallow merge. {{{ type M = Map Int (Map Char (Map PersonId (Map ItemId (Set Foo)))) -- Assuming the current Monoid instance of Map deep,shallow :: M -> M -> M deep = unionWith (unionWith (unionWith (unionWith (<>)))) shallow = (<>) -- Assuming the value-combining Monoid instance of Map deep,shallow :: M -> M -> M deep = (<>) shallow = union }}} My point is that the value-combining instance helps us more than the left- biased instance. Since the instances chain together, it's just one type we're getting a better `Monoid` instance for. It's any arbitrary nesting of them. Let's look at a situation where the left-biased instance fares a little better. What about the situations where you want a left-biased merge at the bottom of a nesting of `Monoid`s? So, not a nesting of `Map`s, but a nesting of other `Monoid`s with a `Map` at the bottom: {{{ type K = Int -> Char -> IO ([ParseError],Map PersonId Person) }}} The left-biased instance has the desirable behavior here. If, after have concatenated a bunch of expressions of type `K`, we try to parse two people with the same id, we silently discard the second one. But, we can easily recover this same behavior with the value-combining `Monoid` instance with: {{{ foo :: Int -> Char -> IO ([ParseError],Map PersonId (First Person)) }}} If you don't actually want that `First` newtype in your final result, it can be `coerce`d away safely as a noop. So, since the value-combining instance can express the left-biased instance, even in the worst cases, the semantics of the left-biased instance can be recovered by clever use of `coerce`. However, the reverse is not true. The left-biased instance cannot express the value-combining union, so currently when we want this, we have to step outside the realm of `Monoid` instances entirely and manually do the lifting. Just to emphasize the asymmetry in the amount and kind of code the end user must write: {{{ type J = Bar -> Baz -> IO ([Log], Map Pokemon (Set Attack)) type V = Bar -> Baz -> IO ([Log], Map Identifier Name) leftBiased :: V -> V -> V valueMerging :: J -> J -> J -- with the left-biased Monoid instance leftBiased = (<>) valueMerging v1 v2 a b = liftA2 (\(x1,y1) (x2,y2) -> (x1 <> x2, unionWith (<>) y1 y2)) (v1 a b) (v2 a b) -- with the value-merging Monoid instance type V' = Bar -> Baz -> IO ([Log], Map Identifier (First Name)) leftBiased a b = coerce ((coerce a) <> (coerce b :: V')) valueMerging = (<>) }}} I know using `coerce` isn't the prettiest thing, but notice that with the value-merging `Monoid` instance, we are able to leverage the automatic lifting of `Monoid` instances to give us a desired behavior. With the left-biased instance, we're stuck doing this by hand. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1460#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13860: TODO: SMALL_MUT_ARR_PTRS in Compact.cmm
by GHC 24 Aug '17

24 Aug '17

#13860: TODO: SMALL_MUT_ARR_PTRS in Compact.cmm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- While looking at `Compact.cmm` I noticed that the small mutable array compaction cases are currently TODOs. Presumably this should be addressed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13860> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

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

24 Aug '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: | -------------------------------------+------------------------------------- Comment (by andrewthad): I'd like to bring this up again. Especially since `Semigroup`, in the next two years, is going to end up as a superclass of `Monoid`. The even better instance would be: {{{ instance (Ord k, Semigroup v) => Monoid (Map k v) }}} In the mailing list that Joachim linked to, this kind of change seemed to attract pretty broad support. I think the only reasonable way to make this change without introducing silent breakage would be to release a `containers-0.6` in which `Map` has no `Monoid` instance. Then, in `containers-0.7`, the new instance would be introduced. This is precisely what Henning proposed in https://mail.haskell.org/pipermail/libraries/2012-April/017749.html, and I think it's the best option available for switching out this instance. These two release would need to be at least a year apart. We would probably like for their to be a stackage lts between them that had `containers-0.6`. And we would probably want to wait for `Semigroup` to actually become a superclass of `Monoid` in `base` before releasing `semigroups-0.7`, just because it's really annoying when you end up with a `(Semigroup v, Monoid v)` constraint sometimes. I would like to draw attention to the two arguments against making this change: 1. It would break a lot of other packages 2. The behavior value-combining `Monoid` instance is easily recovered by using `unionWith`. This reasoning roughly motivates this post: https://mail.haskell.org/pipermail/libraries/2012-April/017745.html Concerning argument (1), I offer no rebuttal. I'll only point out that, with stackage, we now have a somewhat convenient way to attempt to measure the breakage. But, no one has ever done this, and it might be worth looking into. Argument (2) I would like to challenge. In http://www.haskellforall.com/2014/07/equational-reasoning-at-scale.html, Gabriel Gonzalez uses, in a practical way, the behavior of data types that can lift monoidal value into another monoid. Things like: {{{ instance Monoid a => Monoid (IO a) instance (Monoid a, Monoid b) => Monoid (a,b) instance Monoid b => Monoid (a -> b) }}} These are useful because they give us `Monoid` instances for types like: {{{ Int -> Bool -> Char -> IO ([Text],Ordering) }}} The value-combining `Monoid` instance for `Map` is in this same spirit. It would allow us to trivially combine nested map with types like this: {{{ type M = Map Int (Map Char (Map PersonId (Map ItemId [Text]))) mappend :: M -> M -> M }}} This behavior can be recovered by `unionWith`, but it's a length explicit lifting: {{{ deepAppend :: M -> M -> M deepAppend = unionWith (unionWith (unionWith (unionWith (<>)))) }}} I plan on continuing this tomorrow. I have a little more to say. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1460#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14151: Invisible kind variable referenced in typeclass instance error message
by GHC 24 Aug '17

24 Aug '17

#14151: Invisible kind variable referenced in typeclass instance error message -------------------------------------+------------------------------------- Reporter: andrewthad | 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: -------------------------------------+------------------------------------- Here is a minimal example: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} newtype HFix h a = HFix (h (HFix h) a) class EqForall f where eqForall :: f a -> f a -> Bool class EqHetero h where eqHetero :: (forall x. f x -> f x -> Bool) -> h f a -> h f a -> Bool instance EqHetero h => EqForall (HFix h) where eqForall (HFix a) (HFix b) = eqHetero eqForall a b instance EqHetero h => Eq (HFix h a) where (==) = eqForall }}} When we build this with GHC 8.2.1, we get the following error message: {{{ instance_head.hs:18:10: error: • Variable ‘k’ occurs more often in the constraint ‘EqHetero h’ than in the instance head (Use UndecidableInstances to permit this) • In the instance declaration for ‘Eq (HFix h a)’ | 18 | instance EqHetero h => Eq (HFix h a) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} The error message is bad, although most people trying to do this kind of thing can probably reason that there is an invisible `k` and that `h :: (k -> Type) -> k -> Type` and that `a :: k`. I don't really see a way to improve it, but I thought I would bring it up. Also, should the typechecker even reject this? I don't have a great understanding of how GHC's restrictions for keep things decidable work, but a repeated invisible variable seems like it's a somewhat different thing than a repeated visible variable. I'm likely wrong about this, but I just wanted to raise the question. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14151> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14132: Report an error for a missing class instance before an error for type family instances of an associated type.
by GHC 24 Aug '17

24 Aug '17

#14132: Report an error for a missing class instance before an error for type family instances of an associated type. -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | 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 following code {{{ {-# LANGUAGE FlexibleContexts, TypeFamilies, DataKinds #-} import GHC.Generics import GHC.TypeLits type family RepHasNoInstance (f :: * -> *) :: * -- edit 1 -- type instance RepHasNoInstance f = Int -- edit 2 -- class RepHasNoInstanceC (f :: * -> *) -- foo :: (Generic a, RepHasNoInstanceC (Rep a)) => a -> Int -- foo = const 1 foo :: (Generic a, RepHasNoInstance (Rep a) ~ Int) => a -> Int foo = const 1 data NotGeneric = NotGeneric bar :: NotGeneric -> Int bar = foo main :: IO () main = return () }}} gives an error like {{{ associated-type-families-test.hs:21:7: error: • Couldn't match type ‘RepHasNoInstance (Rep NotGeneric)’ with ‘Int’ arising from a use of ‘foo’ • In the expression: foo In an equation for ‘bar’: bar = foo | 21 | bar = foo | ^^^ }}} in ghcs: 8.0.2, 8.2.1, master(a few days old). The error message is for ambiguous types in 7.10.3 Uncommenting edit 1, the error changes to: {{{ associated-type-families-test.hs:16:7: error: • No instance for (Generic NotGeneric) arising from a use of ‘foo’ • In the expression: foo In an equation for ‘bar’: bar = foo | 16 | bar = foo | }}} I think this is a much better error message, since there is no hope for the associated type to have an instance for anything unless there is an instance (Generic NotGeneric). Uncommenting edit 2, (and commenting the existing foo) gives the "No instance for (Generic NotGeneric)" message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14132> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 24 Aug '17

24 Aug '17

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10577, #13117 | Differential Rev(s): Phab:D978 Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Now a github proposal https://github.com/ghc-proposals/ghc- proposals/pull/63, see discussion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:51> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8025: -fno-code and Template Haskell are incompatible
by GHC 23 Aug '17

23 Aug '17

#8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3441 Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I agree that having the ability to override the current behaviour would be useful, but I don't think that overloading -fobject-code to do it is right. I would suggest that we need an "-fno-code-auto" flag. Currently, when we are deciding which modules to codegen in GhcMake.enableCodegenForTH, we take all transitive dependencies of modules that use -XTemplateHaskell. We could instead take all transitive dependencies (where those dependencies don't disable -fno-code-auto) of modules that use -XTemplateHaskell. I think it would make sense to disable -fno-code-auto by default if we improved the error message to suggest it be enabled. One could just add {-# OPTIONS_GHC -fno-code-auto #-} to the modules that need to be codegenned. Separately, a flag -fno-code-target={default,interpreted,asm(?),llvm(?)} should perhaps be added to determine the method of codegen. This would enable us to use interpreted by default, again provided that errors from, for example, unboxed tuples, suggested the user change it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 23 Aug '17

23 Aug '17

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10577, #13117 | Differential Rev(s): Phab:D978 Wiki Page: | -------------------------------------+------------------------------------- Changes (by enolan): * cc: enolan (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:50> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0