Comment by Dylan16807
4 months ago
Even without laziness, you can get similar problems if f creates a closure or returns something that includes the parameter object.
4 months ago
Even without laziness, you can get similar problems if f creates a closure or returns something that includes the parameter object.
Ok, the Wikipedia definition of pure function is more strict and than what I was saying and I think it covers the issues you mentioned:
https://en.wikipedia.org/wiki/Pure_function
Yeah, this is a common source of confusion with closures in Python. Example on Stack Overflow:
https://stackoverflow.com/questions/233673/how-do-lexical-cl...
Doesn't that example also show a kind of laziness?
I say this because the second solution to that question offers the solution of using `i` as a default argument when defining the function. That forces its evaluation and fixes the problem.
It's just a name shadowing.
Copying the code they wrote:
That could also be written "def func(x, foo=i): return x * foo". It's just copying i's value to another variable. In the next line, i's value is still 1, 2, or 3, so when the function is called during the next line of the body of the loop, the value held by i is bound to foo.
It's not evaluating a thunk representing i, which is how lazy variables are evaluated in Haskell.
1 reply →