Comment by Dylan16807
15 days ago
I mean that the identity is unrelated. Yes, you can say they're the same type. But I'm actually passing the same object in. If f evaluated lazily, it could return 2 from both calls. Something like:
define f(o): return o.x
let a = {x=1}
n = f(a) // n is not evaluated yet
a.x = 2
m = f(a)
return n + m // returns 4
Ok, you're probably proving the point that purity also requires immutability. I'm not sure, as I haven't considered all the implications of Haskell's design.
My two rules about inputs and outputs are more like heuristics. They can improve code organisation and probably also decrease the likelihood of some errors, but they don't guarantee correctness, as you're pointing out. They're shortcuts, so they're not perfect.
Edit: If I remember right, it's laziness that requires immutability. I think I read something about this in the Haskell subreddit as an explanation for Haskell's design.
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...
3 replies →