Yes, I meant "producer" there.
On Fri, Aug 22, 2014 at 9:36 AM, GHC <ghc-devs@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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs