[GHC] #10711: Defining mapM_ in terms of traverse_ causes substantial blow-up in ByteCodeAsm

[GHC]

#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