[Haskell-cafe] Laziness leaks

[Ronald Guida]

Don Stewart wrote:
>> 2. Is there any way to systematically search for or detect laziness
>>    leaks?
>
> Profiling, and looking at the Core. Being explicit about the
> evaluation strategy you want is a fine idea though.

Albert Y. C. Lai wrote
> A true cause of laziness is in accumulating a chain of tail's and
> snocs without intermediate forcing, as observed.

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.

With a strict evaluation strategy, I might miss a nearby deadline
because I'm busy calculating things that I don't need until the
distant future.

With a lazy evaluation strategy, I might miss a distant deadline
because I'm lazily putting off a calculation now.

If I were a college student, then this would be a laziness leak:

  Professor X assigns a report, due in a month.  Two days before the
  report is due, I'll head to the drugstore, load up on caffeine, and
  work for 48 hours straight to get it done.

And this would be a strictness leak:

  Professor X assigns a report, due in a month.  As soon as I leave
  the classroom, I'll head to the drugstore, load up on caffeine, and
  work for 48 hours straight to get it done.

And this would be an effective solution:

  Professor X assigns a report, due in a month.  I'll select 15 days,
  spaced out over the next month, and allocate four hours per day to
  work on the report.

By default, a lazy language will procrastinate.  By default, a strict
language will "anticrastinate".  Either way, I can waste resources by
blindly accepting the default time management plan.

So the real question is "How do I avoid laziness leaks or strictness
leaks" and apparently, the real answers are (1) learn how to
recognize when the default plan will waste resources, and (2) learn
how to express reasonable evaluation strategies in code.

I would ask, "how do I examine the evaluation order of my code", but
the answer is already available: use a debugger.  Haskell already has
debugging tools that do exactly what I need.
(http://www.haskell.org/haskellwiki/Debugging)

In particular, HOOD looks extremely interesting.