Unwanted eta-expansion

Jan-Willem Maessen jmaessen at alum.mit.edu
Mon Oct 10 03:50:35 CEST 2011

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?


More information about the Glasgow-haskell-users mailing list