[Haskell-cafe] Preventing sharing

Tom Ellis tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk
Mon Dec 21 12:33:48 UTC 2015


On Mon, Dec 21, 2015 at 08:55:05PM +0900, Oleg wrote:
> > -fno-full-laziness fixes the space leak issue in your iterative deepening
> > example.
> Yes, and I think it has been mentioned that the flag is a blunt weapon
> as it affects the whole module...

Agreed.

> > This isn't a problem with laziness.  It's a problem with performing a time
> > optimization which is a space pessimization.  In the absence of the
> > "optimization" there is no problem.
> 
> How come it isn't the problem with laziness?! Recall, that pure
> call-by-name calculus is observationally undistinguishable from the
> call-by-need (i.e., lazy) calculus. The only reason to have laziness
> is to avoid recomputations of argument computations should an argument
> be used more than once -- at the cost of taking memory to store the
> result of the first evaluation. Thus "performing a time optimization
> which is a space pessimization" is exactly what laziness is all about
> -- as the article mentioned earlier argued. Laziness isn't an absolute
> good -- it is a time-space trade-off, which is not always beneficial.

I don't agree at all.  To my mind you are assigning blame to the wrong
thing.  The operational semantics of

    f () = let x = <a large lazy structure> in ...

are perfectly clear.  x is reallocated each time, and is free to be released
between calls to f.  It's only when an "optimization" rewrites this to

    x = <a large lazy structure>

    f () = ...

that there is a space leak.  Exactly the same applies if the language is
strict.

Tom


More information about the Haskell-Cafe mailing list