Yes, I meant "producer" there. On Fri, Aug 22, 2014 at 9:36 AM, GHC 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