3 ms·
So, another definition of a pure function is that, for a particular input it will always return the same output. Your example respects the rule: f({x=1})
by elbear 2y ago
So, another definition of a pure function is that, for a particular input it will always return the same output.
Your example respects the rule:
f({x=1}) == 1
f({x=2}) == 2
But it's true that the two rules I gave are not enough to make a function pure. Because I didn't say anything about I/O. So, a function that follows the rules about inputs and outputs, could still do I/O and change its outputs based on that.
Starting from the question that gave birth to this whole thread: "What's the benefit of learning a PURE functional programming language..."
The other benefit is that such a language forces you to be explicit about I/O. It does it in such a way that even functions that do I/O are pure. The good part is that, if you use it long enough, it can teach you the discipline to be explicit about I/O and you can use this discipline in other languages.
For example, this is how I see this principles being used in Python:
https://elbear.com/functional-programming-principles-you-can-use-in-python https://elbear.com/functional-programming-principles-you-can...
- Dylan16807 2y ago> Your example respects the rule: Every definition of purity I can find that talks about objects/references says that if you pass in the same object/reference with different contents then that's not pure. Your version differs from mine on that aspect. It passes two unrelated objects. > Starting from the question that gave birth to this whole thread: "What's the benefit of learning a PURE functional programming language..." I interpret saying a language is "purely functional" as being more about whether you're allowed to write anything that isn't functional. I can talk about BASIC being a "purely iterative" language or about "pure assembly" programs, without any implication of chunks of code being pure.
- simiones 2y agoPurely functional language is pretty universally taken to mean that the language enforces function purity for all functions [perhaps with some minor escape hatches like Haskell's unsafePerformIO].
- elbear 2y agoI gave it some more thought. I now believe that learning a language like Haskell (or Elm or PureScript) forces you to see your program as pipes that you fuse together. It's not just functions. Haskell has only expressions and declarations. That means, for example, that you are forced to provide an `else`, when you use `if`. The idea is that you have to keep the data flowing. If a function doesn't provide a meaningful value (so it returns nil, None), you have to handle that explicitly. And, btw > Your version differs from mine on that aspect. It passes two unrelated objects. Those two objects are not unrelated. They have the exact same structure (an attribute named "x"). So they could be considered two values of the same type.
- Dylan16807 2y agoI 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
- elbear 2y agoOk, 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.
- Dylan16807 2y agoEven without laziness, you can get similar problems if f creates a closure or returns something that includes the parameter object.