[Haskell-cafe] Preventing sharing
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...
> > 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
More information about the Haskell-Cafe