Comment by Y_Y
7 years ago
Of course a doubling function is not idempotent!
I think the confusion arises because side-effectful functions can be considered as having type
f :: (RealWorld, OtherArgs) -> (RealWorld, OtherOutputs)
and so for a garage door toggle you have something like
t :: RealWorld -> RealWorld
where the new state is the old one with the door opened/closed as appropriate.
Now the idempotence condition becomes:
t(t(world)) == t(world)
but clearly
t(t(doorOpenWorld)
= t(doorClosedWorld)
= doorOpenWorld
!= t(doorOpenWorld)
= doorclosedWorld
so this is where the notion comes from. If you abuse notation and just say a function of no arguments can be idempotent then you'll get confusion like this.
But `GET(GET(x))` doesn't make sense, in general (and if it did, then you would not expect it to be idempotent), so clearly idempotency in this context is meant to mean side-effect free. They should probably just say side-effect free, though, to avoid the confusion.
It's possible to be idempotent without being side-effect free. If you PUT some record, for example, then that operation _will_ have side effects (modifying the record). If you then PUT that same data again, the result will be the same (it's idempotent).
that’s not a side effect. in common usage, a side effect is an extra action, not the desired action itself. if you PUT some record, and some other record or state changes, that’s a side effect.
2 replies →