ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0007117 | Part 01: TTCN-3 Core Language | Technical | public | 30-07-2015 14:21 | 14-12-2015 13:34

Reporter | Tomas Urban |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.7.1 (published 2015-06) |
Target Version | v4.8.1 (published 2016-07) | Fixed in Version | v4.8.1 (published 2016-07) |
Clause Reference(s) | 5.4.2
Source (company - Author) | STF 487

Summary | 0007117: The order of evaluation of actual and default parameters is not completely set

Description

The current specification describes the order of evaluation of actual parameters (order of their appearance) and default parameters (order of the formal parameter list). However, there's no rule specifying the order of evaluation when both actual and default parameters are present in a single parameterized statement.
Proposal: Add the following rule:
The default parameters are evaluated after all actual parameters have been evaluated.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0007124 | closed | Gyorgy Rethy | Semantics of Actual Parameter Assignment Notation ambiguous.

Attached Files | CR-7117-150805-V1.docx (72,696) 05-08-2015 10:06 http://oldforge.etsi.org/mantis/file_download.php?file_id=3233&type=bug CR-7117-150924-V2.docx (73,021) 24-09-2015 09:49 http://oldforge.etsi.org/mantis/file_download.php?file_id=3276&type=bug CR-7117-150924-V3.docx (92,962) 24-09-2015 10:40 http://oldforge.etsi.org/mantis/file_download.php?file_id=3278&type=bug

Issue History
Date Modified | Username | Field | Change
30-07-2015 14:21 | Tomas Urban | New Issue |
30-07-2015 14:54 | Jacob Wieland - Spirent | Note Added: 0013011 |
30-07-2015 14:59 | Tomas Urban | Note Added: 0013012 |
03-08-2015 10:39 | Gyorgy Rethy | Note Added: 0013018 |
03-08-2015 10:40 | Gyorgy Rethy | Assigned To | => Jens Grabowski
03-08-2015 10:40 | Gyorgy Rethy | Status | new => assigned
04-08-2015 11:15 | Jens Grabowski | Note Added: 0013053 |
05-08-2015 10:05 | Jens Grabowski | Note Added: 0013075 |
05-08-2015 10:06 | Jens Grabowski | File Added: CR-7117-150805-V1.docx |
05-08-2015 10:06 | Jens Grabowski | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
05-08-2015 10:15 | Tomas Urban | Note Added: 0013076 |
05-08-2015 10:18 | Tomas Urban | Note Added: 0013077 |
05-08-2015 10:32 | Jacob Wieland - Spirent | Note Added: 0013078 |
05-08-2015 10:34 | Jacob Wieland - Spirent | Note Added: 0013079 |
05-08-2015 12:03 | Jacob Wieland - Spirent | Relationship added | related to 0007124
05-08-2015 12:04 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Jens Grabowski
05-08-2015 12:04 | Jacob Wieland - Spirent | Note Added: 0013084 |
05-08-2015 12:26 | Tomas Urban | Note Added: 0013085 |
05-08-2015 14:32 | Jacob Wieland - Spirent | Note Added: 0013086 |
05-08-2015 14:56 | Jacob Wieland - Spirent | Note Added: 0013088 |
05-08-2015 21:06 | Tomas Urban | Note Added: 0013092 |
06-08-2015 07:29 | Jacob Wieland - Spirent | Note Added: 0013093 |
06-08-2015 07:30 | Jacob Wieland - Spirent | Note Added: 0013094 |
06-08-2015 07:40 | Tomas Urban | Note Added: 0013095 |
23-09-2015 13:29 | Jens Grabowski | Note Added: 0013267 |
23-09-2015 13:30 | Jens Grabowski | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
23-09-2015 15:09 | Jacob Wieland - Spirent | Note Added: 0013272 |
23-09-2015 15:12 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Jens Grabowski
24-09-2015 09:49 | Jens Grabowski | File Added: CR-7117-150924-V2.docx |
24-09-2015 09:50 | Jens Grabowski | Note Added: 0013283 |
24-09-2015 09:50 | Jens Grabowski | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
24-09-2015 10:40 | Jacob Wieland - Spirent | File Added: CR-7117-150924-V3.docx |
24-09-2015 10:41 | Jacob Wieland - Spirent | Note Added: 0013285 |
24-09-2015 10:41 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
24-09-2015 10:41 | Jacob Wieland - Spirent | Status | assigned => confirmed
24-09-2015 16:41 | Gyorgy Rethy | Target Version | => v4.8.1 (published 2016-07)
14-10-2015 12:43 | Gyorgy Rethy | Note Added: 0013384 |
03-11-2015 09:27 | Gyorgy Rethy | Status | confirmed => resolved
03-11-2015 09:27 | Gyorgy Rethy | Fixed in Version | => v4.8.1 (published 2016-07)
03-11-2015 09:27 | Gyorgy Rethy | Resolution | open => fixed
14-12-2015 13:34 | Gyorgy Rethy | Note Added: 0013618 |
14-12-2015 13:34 | Gyorgy Rethy | Status | resolved => closed

Notes

(0013011)
Jacob Wieland - Spirent
30-07-2015 14:54

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.

(0013012)
Tomas Urban
30-07-2015 14:59

I have no problem with this proposal. It still solves the original issue.

(0013018)
Gyorgy Rethy
03-08-2015 10:39

STF discussion 03-08-2015: Check if current restrictions excludes side effects or not.

(0013053)
Jens Grabowski
04-08-2015 11:15

(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.)

(0013075)
Jens Grabowski
05-08-2015 10:05

Resolution proposal according to my interpretatation uploaded. Assigned for Proofreading to Jacob.

(0013076)
Tomas Urban
05-08-2015 10:15

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.

(0013077)
Tomas Urban
05-08-2015 10:18

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 { ... }

(0013078)
Jacob Wieland - Spirent
05-08-2015 10:32

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.

(0013079)
Jacob Wieland - Spirent
05-08-2015 10:34

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)

(0013084)
Jacob Wieland - Spirent
05-08-2015 12:04

solve in tandem with 7124

(0013085)
Tomas Urban
05-08-2015 12:26

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()".

(0013086)
Jacob Wieland - Spirent
05-08-2015 14:32

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.

(0013088)
Jacob Wieland - Spirent
05-08-2015 14:56

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

(0013092)
Tomas Urban
05-08-2015 21:06

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)?

(0013093)
Jacob Wieland - Spirent
06-08-2015 07:29

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.

(0013094)
Jacob Wieland - Spirent
06-08-2015 07:30

So, in essence, your CR is invalid, as the standard already defines everything clearly, after all ;-)

(0013095)
Tomas Urban
06-08-2015 07:40

Great that you found this rule. I hope it is not a big deal to mention it in the core language specification too.

(0013267)
Jens Grabowski
23-09-2015 13:29

Jacob: Is the attached resolution ok?

(0013272)
Jacob Wieland - Spirent
23-09-2015 15:09

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.

(0013283)
Jens Grabowski
24-09-2015 09:50

New proposal uploaded, please check.

(0013285)
Jacob Wieland - Spirent
24-09-2015 10:41

made small grammatical correction, otherwise fine, please review and resolve

(0013384)
Gyorgy Rethy
14-10-2015 12:43

STF discussion: no problem to define order of default parameter evaluation after evaluating the actual parameters

(0013618)
Gyorgy Rethy
14-12-2015 13:34

Added to draft V4.7.4