Comment by elbear
14 days ago
It seems you only focused on one of the conditions I mentioned.
You have to follow both rules: the one about inputs and the one about outputs.
This is like a contract. If you enforce it throughout your program, you gain some guarantees about your program as a whole.
I was looking at both rules, and specifically I was using the long version where you said "it doesn't assign them to some other global variable that you have to track down". If you pass in a mutable object then that's not "some other global variable".
If I interpret "It only outputs its results" in a very strict way, that still allows having output and in/out parameters. The latter of which can break purity.
Though you can break purity with just inputs:
If you meant to describe pure functions then that's fine, that's why I addressed pure functions too, but I don't think your original description was a description of pure functions.
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:
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...
> 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.
10 replies →