[Haskell-cafe] Re: Laziness leaks

[apfelmus]

Ronald Guida wrote:
> So I just thought of something.  If laziness leads to laziness leaks,
> then is there such a thing as a strictness leak?  I realized that the
> answer is yes.
> 
> A lazy leak is a situation where I'm wasting resources to delay a
> sequence of calculations instead of just doing them now.  But in a
> strict language, I might waste resources to compute things that I'll
> never need.  I would call that a strictness leak.
> 
> Now I could ask the dual question, "How do I detect strictness leaks,"
> and I would probably get the same answers: profiling, looking at
> object code, and being explicit about the evaluation strategy.
> 
> Both types of leaks share a lot in common.  In both cases, I'm wasting
> resources.  If I have a real-time system, then either type of leak can
> cause me to a miss a deadline.

I haven't heard the terms "laziness leak" and "strictness leak" before, 
imho they sound a bit spooky because it's not clear to me what the 
situation without leak would be. (Time vs Space? Is an O(n) algorithm a 
strictness leak compared to an O(log n) algorithm?)


Note that lazy evaluation never wastes time; evaluating a term with lazy 
evaluation will always take less reduction steps than doing so eagerly 
or partly eagerly. But it can waste space (-> "space leak"), for 
instance by accumulating a big expression like

   (..) -> ((..)+1) -> (((..) + 1) + 1) -> etc.

instead of evaluating  x+1  immediately

    5   -> 6        -> 7                -> etc.

However, this would be wasted time in case the whole expression will not 
be evaluated but just thrown away. So, it's a trade-off.

The effect you have in mind only appears in real-time systems, where 
lazy evaluation procrastinates everything by default. So, trying to 
implement a real-time system in a lazy language is more or less a 
paradox :) as Okasaki already points out in his book.


Eager evaluation may "waste" both time and space compared to alternative 
course of reduction.


Regards,
apfelmus

PS: The reduction strategies we compare to don't evaluate under lambdas.