[GHC] #9496: Simplify primitives for short cut fusion

[David Feuer]

Yes, I meant "producer" there.

On Fri, Aug 22, 2014 at 9:36 AM, GHC <ghc-devs at haskell.org> wrote:
> #9496: Simplify primitives for short cut fusion
> -------------------------------------+-------------------------------------
>               Reporter:  dfeuer      |            Owner:  dfeuer
>                   Type:  task        |           Status:  new
>               Priority:  normal      |        Milestone:
>              Component:              |          Version:  7.8.3
>   libraries/base                     |         Keywords:  fusion
>             Resolution:              |     Architecture:  Unknown/Multiple
>       Operating System:              |       Difficulty:  Unknown
>   Unknown/Multiple                   |       Blocked By:
>        Type of failure:  Other       |  Related Tickets:
>              Test Case:              |
>               Blocking:              |
> Differential Revisions:              |
> -------------------------------------+-------------------------------------
>
> Comment (by dfeuer):
>
>  Replying to [comment:2 simonpj]:
>  > I believe that there are good reasons for distinguishing build and
>  augment.  [http://research.microsoft.com/en-us/um/people/simonpj/papers
>  /andy-thesis.ps.gz Andy Gill's thesis] would be a good place to look.
>  But perhaps one could do everything in terms of augment; I'm not sure.
>  Worth a try.
>  >
>  > I think there is really only one primitive consumer, foldr.  I thought
>  we rewrote into foldr and then back.  If that is not done for or, any,
>  etc, I'm not sure why.  Again, perhaps worth investigation.
>  >
>  > Certainly the original goal of the foldr/build paper was to say "ONE
>  rule, not n*m rules".
>  >
>  > Simon
>
>  An aside: Just last night I saw a bit of the work Takano Akio has done on
>  incorporating a worker/wrapper transformation into the framework (although
>  I don't quite understand how it works yet). It doesn't seem to be quite
>  ready for prime time (there were apparently some issues with one NoFib
>  benchmark), but we might want to keep it in mind.
>
>  I think the one rule concept is great. If that can be made to really work,
>  that would be ''ideal''. Unfortunately, the need to wrangle the inliner as
>  it currently works turns the one rule concept into an n*m-rule concept,
>  where m is certainly at least 1, but currently 2 (the rewrite back rule
>  clearly seems necessary for now—I don't yet understand things deeply
>  enough to know for sure if the rewrite to rule is strictly necessary in
>  all cases). I would speculate that the and/or/any/head/... rules came
>  about because someone thought to themselves "There's only one [sic]
>  consumer, `build`, so we can skip this difficult and invasive rewrite
>  to/from process and just fuse with `build`. That's easy!" Well, they were
>  a little wrong, but I'm not sure they were very wrong.
>
>  I haven't had a chance to read the thesis yet, but from a purely practical
>  perspective, I don't see any difference between `build g` and `augment g
>  []`. I don't ''think'' anyone's tossing around partially applied
>  `augment`s or anything.
>
> --
> Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9496#comment:3>
> GHC <http://www.haskell.org/ghc/>
> The Glasgow Haskell Compiler