February 2018 - ghc-tickets

Re: [GHC] #2893: Implement "Quantified constraints" proposal
by GHC 23 Feb '18

23 Feb '18

#2893: Implement "Quantified constraints" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5927 | Differential Rev(s): Phab:D4353 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #5927 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2893#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5927: A type-level "implies" constraint on Constraints
by GHC 23 Feb '18

23 Feb '18

#5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Keywords: Resolution: duplicate | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #2893 Comment: The "`Implies`" in {{{(c `Implies` Show)}}} is the `=>` in the quantified constraint `(c => Show)`. Quantified constraints also allow you to write `forall a. Monoid a`. Or, to put things another way, this is a duplicate of #2893, which tracks the implementation of `QuantifiedConstraints`. I'll close this ticket in favor of that one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5927#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14748: Infer context for Data instance of (data Foo f = Foo (f Bool) (f Int))
by GHC 23 Feb '18

23 Feb '18

#14748: Infer context for Data instance of (data Foo f = Foo (f Bool) (f Int)) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (based on WIP [https://phabricator.haskell.org/D4353 -XQuantifiedConstraints]) Could GHC infer the context for deriving `Data (Foo f)` (#12245)? {{{#!hs data Foo f = Foo (f Bool) (f Int) deriving stock Data {- Generates: instance (Typeable f, (forall xx. Data xx => Data (f xx))) => Data (Foo f) -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14748> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #855: Improvements to SpecConstr
by GHC 23 Feb '18

23 Feb '18

#855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * blocking: => 915 Comment: Sorry, didn't mean to remove that Blocking thing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/855#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #855: Improvements to SpecConstr
by GHC 23 Feb '18

23 Feb '18

#855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * blocking: 915 => Comment: Re: Specialising on lambdas. To have a concrete example to work on, I here is [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-hs stream-fusion.hs], which contains a minimal stream fusion harness using just `singletonS`, `enumFromToS`, `sumS`, `mapS` and `concatMapS`. There are three example functions `ex{1,2,3}` with increasing nesting of `concatMapS` that should all reduce to the same function `goal`. More examples can follow when we get these running. Currently, GHC HEAD (8.5, `8529fbba309cd692bbbb0386321515d05a6ed256`) produces [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-head-simpl-L436 this infamous piece of Core] ([https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-head-spec-L1387 -ddump-spec]) for `ex1`. The goal is to specialise `go` for the call-pattern including a lambda [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-head-simpl-L466-L470 here]. Before I found this ticket, I basically re-implemented part of what simonpj did, results in [https://github.com/sgraf812/ghc/commit/c6c9fbe1eb5ad117b5bd23e943c82ca7bc23… this commit]. I basically tracked `CallOcc`urrences similarly to `ScrutOcc`s. With this specialisation for lambdas, things currently look like [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-lam-simpl-L435 this]. The function has been specialised alright, but the free variables of [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-head-simpl-L466-L470 said lambda], which includes the constant `Step`, are passed to [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-lam-simpl-L453-L457 the specialisation as arguments]. We want to specialise for this new `Call` pattern! However, without `-fspec-constr-keen`, !SpecConstr will only fire when it finds a matching `ScrutOcc`. Looking at the output of [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-lam-spec-L1495-L1499 -ddump-spec] the corresponding `ScrutOcc` will only become visible in the specialised RHS, but we currently only specialise the original RHS. Even then, I imagine that in the general case we need a simplifier run in-between to reliably detect that we scrutinize the new parameter. But that's not actually a problem, because we can use `GHC.Types.SPEC` to tell the compiler to specialise without seeing an `ArgOcc`. Still, GHC needs to see a `Call` pattern with that constant argument, which will emerge [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-lam-spec-L1503-L1517 here], but only after the corresponding RULEs fired. Here are some ideas: 1. We can query the `exprFreeVarsList` [https://github.com/sgraf812/ghc/commit/c6c9fbe1eb5ad117b5bd23e943c82ca7bc23… #diff-992f9a53caac96c0e6303669d68a20e1R2163 here] and see which free variables of the lambda have known constant value and include these in the specialisation. This was somehow fruitless so far for this case, as the free var for the `Yield ...` wasn't included in the `ValueEnv`. Not sure if this is even enough to reach the fixed point in all cases. 2. Specialise specialisations (and fix anything non-terminating) (+ mini simplifier passes) + mini RULE engine. I'm uncomfortable with that much code duplication. 3. Include call-pattern specialisation in the Simplifier, for a radical change. On an abstract level, this seems reasonable: Specialisation is a more modest form of inlining with code size in mind, one that even works for recursive functions. It could chew on stuff the inliner gave up on because of code size requirements (even non-recursive functions). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/855#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3831: SpecConstr should exploit cases where there is exactly one call pattern
by GHC 23 Feb '18

23 Feb '18

#3831: SpecConstr should exploit cases where there is exactly one call pattern -------------------------------------+------------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.13 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | simplCore/should_compile/T3831 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Huh. Indeed those join points have more than one call pattern. (And are non-rec to boot.) It looks as if something must have changed since I wrote that. Short of reverting to that version of GHC and trying it, I'm not sure what to suggest. Mysterious, but not actually a problem, I guess. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3831#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #915: Implement list fusion using streams instead of foldr/build
by GHC 23 Feb '18

23 Feb '18

#915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: 855 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by spl): * cc: leather@… (removed) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/915#comment:54> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #915: Implement list fusion using streams instead of foldr/build
by GHC 23 Feb '18

23 Feb '18

#915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: 855 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * blockedby: => 855 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/915#comment:53> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14842: Layout extensions missing from documentation
by GHC 22 Feb '18

22 Feb '18

#14842: Layout extensions missing from documentation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.2 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: -------------------------------------+------------------------------------- Picking up this issue from https://mail.haskell.org/pipermail/ghc-devs/2018-February/015373.html > seems like none of the extensions that alter or relax layout are documented currently. (AlternativeLayoutRule, AlternativeLayoutRuleTransitional, DoAndIfThenElse, NondecreasingIndentation, RelaxedLayout) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14842> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14826: Flatten data types extending other data types in STG
by GHC 22 Feb '18

22 Feb '18

#14826: Flatten data types extending other data types in STG -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.5 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 idea was triggered by https://mail.haskell.org/pipermail/haskell- cafe/2018-February/128570.html although it does not solve that particular case. Hence I don’t know if there is any practical use for it, but I wanted to jot it down. Consider a data type {{{ data Result = Ok !Foo | NotOK Error }}} where `Foo` is a concrete algebraic data type with $n$ constructors. Then the following transformation should be safe: * Do not generate an info table for `Ok` * Give the `NotOK` the constructor number $n+1$. * Replace calls to `Ok` with `id` * Replace {{{ case r as b of Of f -> E[b,f] | NotOk e -> E[b,e] }}} with {{{ case r as b of DEFAULT -> E[b,b] | NotOk e -> E[b,e] }}} This effectively makes every constructor or `Foo` a constructor of `Ok`, and eliminates the pointer indirection introduced by `Foo`. Checking if a `Result` is `Ok` is now a simple check of the pointer tag (if `Foo` and `Result` do not have too many constructors). Note that `Result` could have additional constructors, but only one can be eliminated. This one constructor needs to * have one argument * be strict in that argument * that argument must be an algebraic data type (even after this flattening) does not have `NotOk` as a constructor. We currently cannot do this in `Core`, but we could if our safe coercions were directed. Do you think you have a case where this could give a performance boost? Maybe some parser library? You can try this now using pattern synonyms and `unsafeCoerce`. If you think there is something to be gained here, then we can consider implementing this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14826> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7