#10711: Defining mapM_ in terms of traverse_ causes substantial blow-up in ByteCodeAsm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: ghcirun004 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Of course, one might expect the compiler to derive the good implementation from the bad. It would be valid, assuming the monad laws hold (which we generally do not do): {{{#!hs a1 *> a2 == (id <$ a1) <*> a2 -- inline *> == fmap (const id) a1 <*> a2 -- inline <$ == liftM (const id) a1 <*> a2 -- inline fmap == (a1 >>= (\x1 -> return (const id x1))) <*> a2 -- liftM == (a1 >>= (\_ -> return id)) <*> a2 -- inline const == (a1 >>= (\_ -> return id)) >>= (\x2 -> a2 >>= (\x3 -> return (x2 x3))) -- inline <*> and ap == a1 >>= (\_ -> return id >>= (\x2 -> a2 >>= (\x3 -> return (x2 x3)))) -- assoc monad law == a1 >>= (\_ -> a2 >>= (\x3 -> return (id x3))) -- first monad law == a1 >>= (\_ -> a2 >>= return) -- inline id, eta-contract == a1 >>= (\_ -> a2) -- second monad law }}} Maybe a bit out of reach for our current simplification infrastructure, where for example the methods `>>=` and `return` will quickly be replaced by their concrete implementations -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10711#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler