GHC lazy eval optimization bug

[Chris Kuklewicz]

Thanks Don.  That is the issue.  I just added this comment/request to trac #1168:

> This just came up on the mailing list again.  The program was slow unless
> (-fno-state-hack) was used.
> 
> Is it possible to have GHC emit a warning (as part of -Wall) to let the use
> know that GHC is applying a potentially risky simplification?

I had tried -Wall before you told me about -fno-state-hack.  If -Wall had warned 
me about the hack then I could have understood the problem without a frequently 
asked question to the list.

Cheers,
   Chris

Don Stewart wrote:
> haskell:
>> I can confirm this performance bug with GHC version 6.6.1 on OS X PCC (G4) 
>> Leopard.
>>
>> It performs correctly, lazily keeping 'primes' for all 4 repetitions, when 
>> using "ghc -Onot" but the the doSlow fails to retain 'primes' when 
>> compiling with "ghc -O" and "ghc -O2"
> 
> Sounds like the known issue of the simplifier eta-expanding `State#`
> lambdas on purpose, which is good for IO, but risks re-computation. The
> 'calendar' nofib program exhibits this, iirc.
> 
> See,
>     http://hackage.haskell.org/trac/ghc/ticket/1168
>     http://hackage.haskell.org/trac/ghc/ticket/1957
> 
> Try compiling with:
> 
>     -fno-state-hack
> 
> -- Don