<p dir="ltr"><br>
On Nov 11, 2014 6:04 AM, "Simon Peyton Jones" <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>> wrote:<br>
> It’s true that, particularly for fusion, inlining can make a huge difference.  And GHC really does need help… it’s extremely hard for it to make the “right” choice all the time.</p>
<p dir="ltr">The inliner does indeed do amazing things, and list fusion does indeed do lovely things for user code. It's just not the most *reliable* optimization in the compiler. I don't think there's anything wrong with admitting that and trying to avoid relying on it too heavily in *library* code. Kim-Ee was right that expanding out mapM by hand bloated the source. I've since defined `sequence=mapM id` to resolve that problem, and doing so does not hurt the benchmarks—it relies only on inlining id (which is quite reliable) and beta-reducing (which is also quite reliable).</p>
<p dir="ltr">> I strongly agree with Kim-Ee that we should play the game of “optimise by randomly mutating the program and pick the version that (today) happens to run faster”.  But I don’t think David is doing that.   There is, at least a Note: [List comprehensions and inlining].</p>
<p dir="ltr">I've been trying to leave a trail of comments and notes as I go. I may need to go further.</p>