[GHC] #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build

[GHC]

#9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible
replacement for foldr/build
-------------------------------------+-------------------------------------
              Reporter:  dfeuer      |            Owner:
                  Type:  task        |           Status:  closed
              Priority:  normal      |        Milestone:
             Component:              |          Version:  7.9
  libraries/base                     |         Keywords:
            Resolution:  wontfix     |     Architecture:  Unknown/Multiple
      Operating System:              |       Difficulty:  Project (more
  Unknown/Multiple                   |  than a week)
       Type of failure:              |       Blocked By:
  None/Unknown                       |  Related Tickets:
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------
Changes (by dfeuer):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 Challenges seem to be piling up. The biggest problem is that no one has
 been able to find local criteria to ensure correctness. The interesting
 wrappers don't generally satisfy the trivial `wrap . unwrap = id`
 correctness condition; rather, they rely on more complex interactions with
 the loop bodies they're embedded in. To ensure correctness, we would need
 two things:

 1. Rules about how a producer can/must use the wrapper, cons, and nil it
 receives, and

 2. Rules about what properties the wrapper, cons, and nil a consumer uses
 must have to ensure correct behavior when used by a sufficiently well-
 behaved producer. In essence, these three things have to travel and
 transform ''together'' in a correct fashion as they travel from a consumer
 through transformers to a producer.

 Takano Akio did not write any such things down, and Joachim was unable to
 make contact. Joachim and Dan couldn't think of anything. Edward K. said
 this whole thing looked frightening. It may be that one of the wizards out
 there can come up with a way to make this work, but until then, I think
 it's probably best to set it aside. Joachim has some other ideas for
 addressing the underlying issues; hopefully one of them will work out.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9545#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler