[GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_

[GHC]

#10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM,
replicateM_
-------------------------------------+-------------------------------------
        Reporter:  strake888         |                Owner:
            Type:  bug               |               Status:  closed
        Priority:  normal            |            Milestone:  8.0.1
       Component:  Core Libraries    |              Version:  7.10.1-rc1
      Resolution:  fixed             |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D1324
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by ekmett):

 > I doubt too many things offer a Wasserman special like that replicateA.

 Consumption of the result with a Writer, Const, Reader, update monads, all
 benefit rather disproportionally. The Const case in particular is relevant
 as it basically shows how we'd foldMap and it and the writer case bring in
 every Monoid as something that can be folded over optimally. In general
 the idea of randomly inducing a bias here ensure that nothing smart _can_
 be done by the consumer. You enforce worst-case asymptotic behavior by
 losing sharing.

 One option to compromise might be to look at a way that RULES can try out
 the biased association and then write back if it doesn't fuse away?

 Or even simpler, add RULES to rewrite the IO / ST cases into the biased
 form. We provably get no benefit from the tree for that style of effect
 and can't observe the difference in associativity for these concrete
 cases.

 As you note basically any transformer is going to have enough overhead to
 swamp this concern, so it is really only those sorts of things that are
 problematic.

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