From Programming Languages: Principles and Paradigms, by Maurizio Gabbrielli, Simone Martini
void fiefoo (valueresult int x, valueresult int y) { x = x+1; y = 1; } ... int i = 1; int[] A = new int[5]; A[1]=4; fiefoo(i,A[i]);we are to execute
fiefoowith parameters passed by value-result. On termination, we will haveA[1]with value1andiwith value2, while the rest of the arrayAhas not been touched.
Why is it A[1] instead of A[2] whose value is 1?
My thought is that when returning from the function fiefoo, x's value 2 is assigned to i, so A[i] is evaluated to be A[2], and y's value 1 is assigned to A[i].
My thought is according to what the book says
It should be clear that, as in call by value, the following questions about evaluation order in call by return must be answered. If there is more than one result parameter, in which order (for example, from left to right) should the corresponding "backward assignment" from the actual to formal be performed?
Finally, when is the actual parameter’s l-value determined? It is reasonable to determine it both when the function is called and when it terminates. We can construct an example which gives different results if the l-value of the actual is determined at call time or when the procedure terminates.
Thanks.
-
$\begingroup$ There is nice explanation how call by value-result vs by reference differs $\endgroup$Evil– Evil2016年09月12日 05:12:57 +00:00Commented Sep 12, 2016 at 5:12
1 Answer 1
This example is to get readers to think about the consequences of how A[i] is resolved in a call by value-result setting- should it be before or after the function call to fiefoo?
The example assumes that A[i] is resolved before the call, and hence i and A[1] are assigned values 1 and 2 respectively. It has the nice property that fiefoo can only modify those variables.
On the other hand, you can imagine a programming language designer who chooses to resolve the value of A[i] after fiefoo returns, but there's two possible outcomes depending on the order in which the value-results are assigned: 1) A[old i] = y, i = x; and 2) i = x, A[updated i]. Case #2 being what you proposed.
When the designer is faced with these design decisions, she would likely opt to resolve before the call to fiefoo to avoid the possible ambiguity associated with resolving after the call to fiefoo.