From the patch fragment at

https://phabricator.haskell.org/D455?id=1311#inline-3123

What's the justification for expanding out the definition of mapM from "sequence . map f" into do-notation and duplicated code?

Observe how mapM now duplicates code from sequence.

The absence of benchmarks is bad enough. What's worse is that the given excuse boils down to "Pity the poor compiler! Let's take over its work instead. Like, just in case, you know."

This optimization work needs to take place at a higher level, with deep understanding of existing compiler transformations. Otherwise, it's all a code-muddying crapshoot in the dark.

-- Kim-Ee

On Tue, Nov 11, 2014 at 2:22 PM, GHC <ghc-devs@haskell.org> wrote:
#9781: Make list monad operations fuse
-------------------------------------+-------------------------------------
              Reporter:  dfeuer      |            Owner:  dfeuer
                  Type:  task        |           Status:  patch
              Priority:  normal      |        Milestone:  7.10.1
             Component:  Core        |          Version:  7.9
  Libraries                          |         Keywords:
            Resolution:              |     Architecture:  Unknown/Multiple
      Operating System:              |       Difficulty:  Unknown
  Unknown/Multiple                   |       Blocked By:
       Type of failure:  Runtime     |  Related Tickets:
  performance bug                    |
             Test Case:              |
              Blocking:              |
Differential Revisions:  Phab:D455   |
-------------------------------------+-------------------------------------

Comment (by Herbert Valerio Riedel <hvr@…>):

 In [changeset:"4923cea56345060faaf77e4c475eac6aa3c77506/ghc"]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="4923cea56345060faaf77e4c475eac6aa3c77506"
 Define list monad operations using comprehensions

 Define list monad operations using list comprehensions. Code using monad
 operations with lists did not fuse fully. Writing list code with `do`
 notation or `(>>=)` and `(>>)` operations could allocate more than
 equivalent code using list comprehensions.

 Define `mapM` directly, instead of using `sequence` and `map`. This
 leads to substantially less allocation in `cryptarithm2`.

 Addresses #9781

 Reviewed By: ekmett, nomeata

 Differential Revision: https://phabricator.haskell.org/D455
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9781#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
ghc-tickets mailing list
ghc-tickets@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-tickets