3 ms·

Is assignment even truly idempotent? Maybe for mathy systems, but not necessarily for programming languages. It would depend on the implementation of the langua

Is assignment even truly idempotent? Maybe for mathy systems, but not necessarily for programming languages. It would depend on the implementation of the language, and could, for example, introduce global side effects. It kind of depends on what you consider the "value" of the operation. The return value? The global state? Even a classic GET request on a REST api, is only idempotent if you ignore the fact that the data changes over time. I guess what I'm saying is, outside of formal systems, I think it's all deduplication.

mikekchar 8y ago
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.
rswail 8y ago
GET is only idempotent in terms of the effect of the client calling the server. The server is free to change the state of a resource at any time without informing the client. What a compliant server cannot do is change the state of a resource as a result of receiving the GET request from the client.

mikekchar 8y ago

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.

rswail 8y ago

GET is only idempotent in terms of the effect of the client calling the server. The server is free to change the state of a resource at any time without informing the client. What a compliant server cannot do is change the state of a resource as a result of receiving the GET request from the client.