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