Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007117Part 01: TTCN-3 Core LanguageTechnicalpublic30-07-2015 14:2114-12-2015 13:34
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Summary0007117: The order of evaluation of actual and default parameters is not completely set
DescriptionThe 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.
TagsNo tags attached.
Clause Reference(s)5.4.2
Source (company - Author)STF 487
Attached Filesdocx file icon CR-7117-150805-V1.docx [^] (72,696 bytes) 05-08-2015 10:06
docx file icon CR-7117-150924-V2.docx [^] (73,021 bytes) 24-09-2015 09:49
docx file icon CR-7117-150924-V3.docx [^] (92,962 bytes) 24-09-2015 10:40

- Relationships
related to 0007124closedGyorgy Rethy Semantics of Actual Parameter Assignment Notation ambiguous. 

-  Notes
(0013011)
Jacob Wieland - Spirent (reporter)
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 (reporter)
30-07-2015 14:59

 I have no problem with this proposal. It still solves the original issue.
(0013018)
Gyorgy Rethy (reporter)
03-08-2015 10:39

 STF discussion 03-08-2015: Check if current restrictions excludes side effects or not.
(0013053)
Jens Grabowski (manager)
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 (manager)
05-08-2015 10:05

 Resolution proposal according to my interpretatation uploaded. Assigned for Proofreading to Jacob.
(0013076)
Tomas Urban (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
05-08-2015 12:04

 solve in tandem with 7124
(0013085)
Tomas Urban (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
06-08-2015 07:30

 So, in essence, your CR is invalid, as the standard already defines everything clearly, after all ;-)
(0013095)
Tomas Urban (reporter)
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 (manager)
23-09-2015 13:29

 Jacob: Is the attached resolution ok?
(0013272)
Jacob Wieland - Spirent (reporter)
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 (manager)
24-09-2015 09:50

 New proposal uploaded, please check.
(0013285)
Jacob Wieland - Spirent (reporter)
24-09-2015 10:41

 made small grammatical correction, otherwise fine, please review and resolve
(0013384)
Gyorgy Rethy (reporter)
14-10-2015 12:43

 STF discussion: no problem to define order of default parameter evaluation after evaluating the actual parameters
(0013618)
Gyorgy Rethy (reporter)
14-12-2015 13:34

 Added to draft V4.7.4

- 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

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker