GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=!closed&keywords=~laziness&order=priority
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=!closed&keywords=~laziness&order=priority
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/5262
http://ghc.haskell.org/trac/ghc/ticket/5262#5262: Compiling with -O makes some expressions too lazy and causes space leaksThu, 16 Jun 2011 12:43:54 GMTmichal.palka<p>
Here are some expressions that are executed in a too lazy way when optimisation is turned on in GHC. GHC is known to make some expressions too lazy when full laziness is turned on (as in <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/917" title="bug: -O introduces space leak (new)">#917</a>), and indeed some of these expressions execute correctly when you add -fno-full-laziness. However, some of them are compiled too lazy even if -fno-full-laziness is present.
</p>
<p>
Here are terms that get compiled too lazy with -O only when full strictness is on:
</p>
<pre class="wiki">seq (id (\a -> seq a (\b -> (undefined::Int))) (undefined::Bool))
\a -> seq (seq a (\b -> seq b null) (undefined::([] ([] Int)) -> [] Int)) (\b -> ([]::[] Int)) length
\a -> seq (id (\b -> seq b (\c -> seq)) (length a)) ([]::[] Int)
</pre><p>
Here are terms which are compiled too lazy with -O regardless of full strictness:
</p>
<pre class="wiki">seq (seq (odd (undefined::Int)) (\a -> (undefined::[] (Int -> Bool))))
foldr (\a -> seq) id ((:) True (undefined::[] Bool))
\a -> foldr (\b -> \c -> seq c (\d -> ([]::[] Int))) (undefined::Bool -> [] Int) a False
\a -> (\b -> map (seq b id) (seq b ([]::[] Int))) (seq a (\b -> (undefined::([] Bool))))
map (seq (seq (seq 0 (undefined::Bool)) (\a -> \b -> (undefined::Bool)) (undefined::Int)))
map (seq (seq (id (\a -> (undefined::Int)) ([]::[] Int)) (\a -> undefined::Bool)))
\a -> (\b -> (:) (seq b 2) (b (undefined::Int) 0)) (seq a (\b -> (undefined::Int -> [] Int)))
</pre><p>
To discover the differences, just run the terms (whose types are [Int] -> [Int]) on some partially or fully-defined small lists.
</p>
<p>
It is possible to construct programs which exhibit space leaks only when optimisation is turned on using some of these terms (examples attached).
</p>
<p>
All programs have been tested with a pre-built GHC 7.1.20110606 on linux x86-64.
</p>
<p>
Is this a bug? Well, full laziness comes with a disclaimer that some expressions will get too lazy, but this happens even when we turn off full laziness, so it might be a legitimate bug.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5262#changelog