strictness of unused arguments

Max Bolingbroke batterseapower at
Fri Mar 12 08:38:41 EST 2010

On 12 March 2010 13:13, Roman Beslik <beroal at> wrote:
> Thanks for the answer. Sorry, I can not follow all of your thoughts because
> my knowledge of strictness analysis and GHC optimizations are very basic. :(
> I looked into GHC code once several years ago. BTW there are a lot of papers
> about strictness analysis, but I do not know which is relevant for GHC. Can
> you suggest something?

There is nothing *published* (Simon has a half-written one lying
around though), but the general approach is similar to that shown in
"Projections for strictness analysis" at
Unfortunately the weird behaviour you are seeing is due to the "demand
transformer" technology of GHC, which is one of the unpublished

> So GHC records strictness information for lambda-abstractions, not for
> function types? Eta-expansion changes strictness because it adds
> lambda-abstractions.

It records strictness info on *binders*, and it only records
strictness info about lambdas that are syntactically manifest at the
binder. So you get:

let f = \z. bar e_1
    g = foo e_2 e_3
in e_3 (\y. baz e_4)

Then f gets strictness info about one argument, g about no arguments
and the (\y. baz e_4) just doesn't stand a chance of getting improved
at all.

Eta expansion moves lambdas towards the binders, so it makes this
approximation more effective, as you say.

>> 2) GHC does not seem to be eta-expanding as much as it could get away
>> with. Generally eta expansion has the following effects
> I think it is better to go without eta-expansion. Eta-expansion (if not
> optimized when compiled) do absolutely useless job. I discovered its effect
> by an accident.

Eta-expansion happens quite a bit in GHC right now, though I'm not
sure how important it is pragmatically. Probably quite important
though - you might want to look up the "state hack" for a situation
where it seems to be quite necessary.

Sorry that I don't have an easy answer to your problem except
"eta-expand by hand"!


More information about the Glasgow-haskell-users mailing list