#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