> Idempotence is usually used when talking about effectful code. Agreed! The idempotent operation acts on some state; how that state is modeled is an independe

> 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!