4 ms·
Idempotence is usually used when talking about effectful code. Modeling the state as part of the input/output seems to run counter to that purpose, because that
by lmkg 5y ago
Idempotence is usually used when talking about effectful code. Modeling the state as part of the input/output seems to run counter to that purpose, because that's how you create a pure model of an effectful program. It's useful to talk about idempotence when running the function zero times is different than running it once, which is hard to do in that framing. As you say, "on the same input" is difficult to reconcile if the state is part of the input.
If we consider the state to be part of the input, then it's easier to say that when f(x) = y, then f(y) = y as well. In other words, f(f(x)) = f(x). Which, as it just so happens, is literally the mathematical definition of idempotence which the programming concept is based on.
In any case, this still gets to the same overall conclusion: the point is to arrive at a specific destination, not to move towards it. That shift of perspective is helpful in framing problems towards an idempotent solution.
- Twisol 5y ago> Idempotence is usually used when talking about effectful code. Agreed! The idempotent operation acts on some state; how that state is modeled is an independent concern. > In other words, f(f(x)) = f(x). Which, as it just so happens, is literally the mathematical definition of idempotence which the programming concept is based on. That's the one I like the most, because I try to concentrate impurity to a small region of the overall program. In a language like Haskell, in some ways your hand is forced! But, as you say, it's biased toward a particular way of modeling state and effects. My point is, if a program is said to be idempotent if running it multiple times on the same input produces the same output, then you exclude the Haskell approach to idempotence. Half the point of `f(f(x)) = f(x)` is that the input f(x) is typically not the same input as x itself!