Unwanted eta-expansion

[Jan-Willem Maessen]

On Sun, Oct 9, 2011 at 10:54 AM, Roman Cheplyaka <roma at ro-che.info> wrote:
> * Jan-Willem Maessen <jmaessen at alum.mit.edu> [2011-10-08 12:32:18-0400]
>> It seems to be a common misconception that eta-abstracting your
>> functions in this way will speed up or otherwise improve your code.
>>
>> Simon PJ has already provided a good explanation of why GHC eta
>> expands.  Let me take another tack and describe why the code you wrote
>> without eta expansion probably doesn't provide you with any actual
>> benefit.  Roughly speaking, you're creating a chain of closures whose
>> contents exactly describe the contents of your list (ie you've created
>> something that's isomorphic to your original list structure), and so
>> you should expect no benefit at all.
>
> Thanks for the analysis.
>
> I used myFoldl as a minimal example to ask the question.
>
> Here's an example of real code where this does make a difference:
> https://github.com/feuerbach/regex-applicative/tree/03ca9c852f06bf9a9d51505640b8b72f07291c7d

Ah, now things get more complicated!  :-)  I suspect here you're
actually entering the regexp closures, and compiling it down is
actually saving you a teensy bit of interpretive overhead.

> ...
> What's even more interesting (and puzzling!), if remove
> -fno-do-lambda-eta-expansion for Text/Regex/Applicative/Types.hs,
> the benchmark takes 2.82 seconds.

That *Is* odd.  The only obvious code generated here would be the
newtype instances, for which this should surely be irrelevant?  Can
someone at GHC HQ explain this one?

-Jan