GHC lazy eval optimization bug

[Adam P Jenkins]

Thank you for the explanation.  Inlining does explain the behavior I  
was seeing, and -fno-state-hack does make the program behave the way  
I'd expect.

I would like to humbly submit that perhaps this optimization should be  
off by default.  It seems to me that any compiler optimization which  
can potentially increase your program's runtime by an order of  
complexity is dangerous.  Also, while the Haskell Report doesn't seem  
to specify anything about lazy evaluation behavior, it seems to me  
that in order to program in Haskell, assuming that a computation  
assigned to a variable won't be recomputed multiple times is almost as  
necessary an assumption as assuming that the compiler will optimize  
away tail recursion.  For instance GHC FAQ entry 7.2 implicitly  
assumes this is true:

http://haskell.org/haskellwiki/GHC:FAQ#Does_GHC_do_common_subexpression_elimination.3F

In my real program where I ran into this problem it took me quite a  
while to figure out why my program's performance wasn't making any  
sense, and why seemingly irrelevant changes to my code made the  
performance problem go away.

Thank you,

Adam

On Feb 3, 2008, at 3:18 PM, Stefan O'Rear wrote:

> On Sun, Feb 03, 2008 at 02:37:42PM -0500, Adam P Jenkins wrote:
>> The haskell program below demonstrates an optimization bug with the
>> GHC compiler.  I have tried this with ghc 6.8.1 on my MacBook Pro and
>> on a Linux i686 machine.  This email should build as a literate  
>> haskell
>> program.  Build the program as
>
> While this may be unfortunate, it is a consequence of document
> behavior; thus I would not consider it a bug per-se.  Try with
> -fno-state-hack; the documentation for this option, I believe, should
> explain what is going on.  (Hint: IO a ~ State# -> (State#, a))
>
> Stefan