|
Notes |
|
|
|
I disagree, the parameters should be evaluated in the order of their appearance. If an actual parameter with a corresponding formal parameter with a default is not filled, the default is evaluated in its place.
Basically, writing down a parameter list with left-out actual parameters which have defaults should be semantically the same as the replacement of the missing actual parameters with their defaults. |
|
|
|
|
|
I have no problem with this proposal. It still solves the original issue. |
|
|
|
|
|
STF discussion 03-08-2015: Check if current restrictions excludes side effects or not. |
|
|
|
|
(1) The current restrictions for default values do not exclude side effects. I.e., expressions defining default values need not to adhere to Clause 16.1.4. There are some restrictions for avoiding side effects, e.g., "The expression shall not refer to elements of the component type of the optional runs on clause. The expression shall not refer to other parameters of the same parameter list. The expression shall not contain the invocation of functions with a runs on clause." and for module parameters: "The constant expression for the default value of a module parameter shall respect the limitations given in clause 16.1.4."
(2) The rule referred to by Tomas is:
"When a formal parameter has been defined with a default value or template, respectively, then it is not necessary to provide an actual parameter. The actual parameters are evaluated in the order of their appearance. If for some formal parameters, no actual parameter has been provided, their default values are taken and evaluated in the order of the formal parameter list."
I interprete this differently than Tomas due to the word "some" which includes the case where both actual and default parameters are present in a single parameterized statement. In this case my interpretation follows Jacobs understanding that "he parameters should be evaluated in the order of their appearance". However, different interpretations have only effect in case of side effects. A rewording is needed.
(3) We may think of restricting default values, by applying the rules in 16.1.4. As this may have consequences for backwards compatability, I propose to add at least a recommendation that expressions used for the initialization of default values should adhere to 16.1.4 (like the recommendation for constant definitions).
(The issue will be discussed in the STF again.) |
|
|
|
|
|
Resolution proposal according to my interpretatation uploaded. Assigned for Proofreading to Jacob. |
|
|
|
|
The proposed resolution is unfortunately not backwards compatible. Let's consider the following code:
type component C {
var integer vc_counter := 0;
}
function f_inc() runs on C return integer {
vc_counter := vc_counter + 1;
return vc_counter;
}
function f_test() runs on C {
log(p_val1 / p_val2);
}
testcase TC() runs on C {
f_test(p_val2 := f_inc(), p_val1 := f_inc());
}
Using the current rules (parameters resolved in the order of the actual parameter list), the code logs 2, but using the proposed rules (order of the formal parameter list), the code logs 0. |
|
|
|
|
I am sorry, I submitted the previous note too fast. The function f_test didn't declare the parameters. The correct definition should be:
function f_test(integer p_val1, integer p_val2) runs on C {
...
} |
|
|
|
|
I always interpreted the assignment-notation as just syntactic sugar to the list-notation. I am almost sure that the sentence about the evaluation of actual parameters was already in the text before the assignment notation was introduced, i.e. only the list notation existed where the order of formal parameters is the same as the order of actual parameters.
Therefore, the actual parameters would always be evaluated in the order of the formal parameters and the order of appearance in the list-notation would have no impact on that.
I think we have to decide what the intended interpretation of the evaluation order for assignment-notation was and whether this now generates a backward-compatibility problem or not. |
|
|
|
|
|
In essence, in my view, it is ambiguous for a mapping-notation to talk about order. It can always mean two things: order by key or order by list. Normally, mappings are ordered by keys and the keys here are the parameter names of the formal parameter list. Therefore, with this interpretation, the evaluation order for the assignment-notation would still be the same as for the list-notation, i.e. f(a:=x,b:=y) =^= f(b:=y,a:=x) |
|
|
|
|
|
solve in tandem with 7124 |
|
|
|
|
Assignment notation is used in C# and uses the actual order of parameters and not the order of formal parameters. Why should TTCN-3 behave differently? There should be really a strong reason to deviate from the rules used by standard programming languages.
Besides, normally are statements interpretted in textual order, unless operator priority is involved. I doesn't seem logical that in statement "f_test(p_val2 := f_eval(), p_val1 := f_eval())" "p_val1 := f_eval()" is resolved before "p_val2 := f_eval()". |
|
|
|
|
Sorry, just because a feature introduced into C# in 2011 does it differently (and in my opinion wrongly) than a similar feature in TTCN-3 which, I think, was even introduced earlier doesn't mean much.
For TTCN-3, the assignment notation was always intended as a syntactical shorthand-notation (especially for use with templates with lots of parameters with defaults) where it makes much more sense to first normalize the expression to list-notation (i.e. order parameters, fill holes with defaults) and then evaluate the result. |
|
|
|
|
Anyway, since it is a very obscure case if someone switches the order of the parameters anyway, we could also change it in the way of the textual order. However, this would be backward compatible for the other tools, so there is no perfect solution.
Also, the evaluation then becomes a more difficult procedure:
- evaluate the arguments of the given parameter-assignments.
- convert the assignment-list into a non-assignment-list, by putting in the order of the formal parameters the evaluated named parameter or the evaluated default value of the parameter, if the parameter was not assigned in the parameter list
It's basically the question: evaluate-convert-evaluate or just convert-evaluate |
|
|
|
|
I would like to repeat that the current rules exactly say which order should be used: "The actual parameters are evaluated in the order of their appearance."
I have discussed the matter with my coleagues and the official position of Elvior is that the rule shouldn't be changed for the three reasons I already mentioned:
1. Backwards incompatibility
2. Different behaviour compared to programming and scripting languages (its not just C# and VB; Python works in the same way)
3. Execution in different than textual order doesn't follow the natural order for processing TTCN-3 syntax.
According to the existing rules, assignment notation is not a syntax sugar and it behaves differently than the list notation in some cases as I demonstrated above. The sentence describing the evaluation order was introduced in 4.1.1 i.e. in the same version as the assignment notation itself. The intensions of the STF that introduced the feature might be interesting from a historical point of view, but they are quite irrelevant now. It is the written rules what matter.
The mapping process is an implementation-specific issue. Neither the core language specification nor operational semantics use this term and I cannot see a reason why it should be of any importance when discussing this CR. Besides, I don't think that the assignment list should be converted to the list notation at all. Why can't the TE write the actual values directly to formal parameters when their names are known (as defined in operational semantics in 9.24: In the second step the values of the actual parameter are calculated and assigned to the corresponding field in the call record)? |
|
|
|
|
The deciding factor here is actually section 7.11. in the Operational Semantics:
"If assignment notation has been used for the actual
parameter list, then the default values are appended to the actual parameters, the order among the default values
corresponds to their order in the formal parameter list."
From that, you are right and the transformation-before-evaluation interpretation was wrong. |
|
|
|
|
|
So, in essence, your CR is invalid, as the standard already defines everything clearly, after all ;-) |
|
|
|
|
|
Great that you found this rule. I hope it is not a big deal to mention it in the core language specification too. |
|
|
|
|
|
Jacob: Is the attached resolution ok? |
|
|
|
|
|
no, the actual parameter resolution is wrong, as according to the operational semantics, given parameters are evaluated as appearing in their textual order and all non-given parameters with default values are evaluated in the formal parameter list order. |
|
|
|
|
|
New proposal uploaded, please check. |
|
|
|
|
|
made small grammatical correction, otherwise fine, please review and resolve |
|
|
|
|
|
STF discussion: no problem to define order of default parameter evaluation after evaluating the actual parameters |
|
|
|
|
|
CR-7117-150805-V1.docx (72,696) 05-08-2015 10:06