Lift an unnecessary assumption in the demand analyser (fix Trac #8329)
authorSimon Peyton Jones <simonpj@microsoft.com>
Tue, 1 Oct 2013 08:27:53 +0000 (09:27 +0100)
committerSimon Peyton Jones <simonpj@microsoft.com>
Tue, 1 Oct 2013 11:07:37 +0000 (12:07 +0100)
commit9bd366642f495fe26db261317dd416de1ff854bc
tree5299c3534e00fce6726297ac1a9d715e06173f9c
parent3c9aa40f1cb3f228a86b359466ac8f058583e157
Lift an unnecessary assumption in the demand analyser (fix Trac #8329)

Here's the Note about the (simple) fix.  Apparently #8329 prevented all
23 packages of the Snap framework from compiling.

Note [Demand transformer for a ditionary selector]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If we evaluate (op dict-expr) under demand 'd', then we can push the demand 'd'
into the appropriate field of the dictionary. What *is* the appropriate field?
We just look at the strictness signature of the class op, which will be
something like: U(AAASAAAAA).  Then replace the 'S' by the demand 'd'.

For single-method classes, which are represented by newtypes the signature
of 'op' won't look like U(...), so the splitProdDmd_maybe will fail.
That's fine: if we are doing strictness analysis we are also doing inling,
so we'll have inlined 'op' into a cast.  So we can bale out in a conservative
way, returning topDmdType.

It is (just.. Trac #8329) possible to be running strictness analysis *without*
having inlined class ops from single-method classes.  Suppose you are using
ghc --make; and the first module has a local -O0 flag.  So you may load a class
without interface pragmas, ie (currently) without an unfolding for the class
ops.   Now if a subsequent module in the --make sweep has a local -O flag
you might do strictness analysis, but there is no inlining for the class op.
This is wierd so I'm not worried about whether this optimises brilliantly; but
it should not fall over.
compiler/basicTypes/Demand.lhs