3 ms·

Assuming you don't count side effects like running out of memory, assignment is definitely idempotent. It is, of course, not immutable. Now, it is completely

Assuming you don't count side effects like running out of memory, assignment is definitely idempotent. It is, of course, not immutable. Now, it is completely possible to implement a non-idempotent assignment if you want. For example, if you wrote an assignment function that returned true if the value changed when you assigned it, or false if it didn't, then that would not be idempotent. And, of course, you could be nit-picky about side effects. For example, a language might implement assignment such that the first time you assign a value, it allocates the memory and the second time it simply overwrites the memory. That's obviously not idempotent. However, you could make similar arguments for a lot of compiler optimisations: they can take an idempotent function and make it not idempotent when viewed from outside the context of the source code. While there is some value in considering those issues, it's a bit self-defeating as well. You take a useful abstraction and throw it away. I think it makes sense to have conversations like: is this idempotent from the context of the source code? Running out of memory when you assign to a variable that's allocated on the stack is not something anyone normally prepares for (and if you do, then God help you ;-) ). The concept still provides value to the conversation, which is the reason for having words in the first place. You may prefer a different word, but if it's going to be used in every single case I would question the utility of the redefinition.

heavenlyblue 8y ago
Assignment is not idempotent if you include ordering in the system. These two operations have different results: 1. A=5 2. A=6 vs 1. A=6 2. A=5 In such scenarios, whenever an operation is performed, the assignment operator is no longer binary. You also need to include the ordering information (e.g. randomly generated) in the transaction, such as: ASSIGN(0, A, 6) ASSIGN(1, A, 5) Then operations are performed in the order depending on the first value in the tuple. As you can see, idempotency of assignment is only true if it's ordering value is the same.

heavenlyblue 8y ago

Assignment is not idempotent if you include ordering in the system. These two operations have different results: 1. A=5 2. A=6 vs 1. A=6 2. A=5 In such scenarios, whenever an operation is performed, the assignment operator is no longer binary. You also need to include the ordering information (e.g. randomly generated) in the transaction, such as: ASSIGN(0, A, 6) ASSIGN(1, A, 5) Then operations are performed in the order depending on the first value in the tuple. As you can see, idempotency of assignment is only true if it's ordering value is the same.