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

ID | Project | Category | View Status | Date Submitted | Last Update
0007471 | Part 01: TTCN-3 Core Language | Editorial | public | 08-08-2016 14:00 | 09-12-2016 15:43

Reporter | KristÃ³f Szabados |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.9.1 (published 2017-05) | Fixed in Version | v4.9.1 (published 2017-05) |
Clause Reference(s) | 6.2.1, 19.1
Source (company - Author) | L. M. Ericsson

Summary | 0007471: editorial: inconsistency in the standard regarding partially initialized values

Description

In his feedback Martin Hauch pointed out an inconsistency in the core standard.
"
Another point regarding assignments of structured types which is related and should also be clarified:
Chapter 19.1 :
A structured value on the right-hand side of the assignment shall be assigned completely to the variable on the left-hand side of the assignment, If a partially initialized value is assigned to a completely initialized variable, fields uninitialized at the right-hand side of the assignment shall also become uninitialized at the left-hand side.
But in Chapter 6.2.1 "Record type and values" there are many examples that contradict this statement e.g. EXAMPLE 5
var MyRecordType MyVariable :=
{
field1 := '111'B,
field2 := false,
field3 := -
}
MyVariable :=
{
field2 := true
}
// after this, MyVariable contains:
// { '111'B /* unchanged */, true, <undefined> /* unchanged */ }
In my opinion (regarding chapter 19.1) fields field1 and field3 are not assigned and so must be unitialized after the assignment. If I only want to change the second field of the variable, it should be written:
MyVariable.field2 := true;
In case of more complex situations, the usage of modified templates is semantically a better solution to change complex values, when some special fields should be assigned to a new value. The concept of "modified templates" is a clear semantic, how templates can be defined using base template definitions. This also would make the use of the "-" in assignments unnecessary.
I think the sentence in 19.1 is more clear and intuitive, than the long description in chapter 6.2.1 Record type and values. In 6.2.1, fields on the left hand side are kept unchanged implicitly, which can lead to side effects and is completely against the way assignments should work in my opinion.
"

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

Relationships

related to | 0007473 | closed | Gyorgy Rethy | Chapter 6.2.1 inconsitencies in optionial attribute "explicit omit"

Attached Files |

Issue History
Date Modified | Username | Field | Change
08-08-2016 14:00 | KristÃ³f Szabados | New Issue |
08-08-2016 15:49 | Jacob Wieland - Spirent | Note Added: 0014046 |
09-08-2016 10:43 | Martin Hauch | Note Added: 0014047 |
09-08-2016 15:48 | Jacob Wieland - Spirent | Note Edited: 0014046 | bug_revision_view_page.php?bugnote_id=14046#r314
09-08-2016 15:51 | Jacob Wieland - Spirent | Note Edited: 0014046 | bug_revision_view_page.php?bugnote_id=14046#r315
09-08-2016 15:55 | Jacob Wieland - Spirent | Note Added: 0014048 |
10-08-2016 13:08 | Martin Hauch | Note Added: 0014049 |
10-08-2016 15:11 | Jacob Wieland - Spirent | Note Added: 0014050 |
15-08-2016 10:31 | Jens Grabowski | Assigned To | => KristÃ³f Szabados
15-08-2016 10:31 | Jens Grabowski | Status | new => assigned
15-08-2016 10:37 | Jens Grabowski | Relationship added | related to 0007473
17-08-2016 11:49 | Jacob Wieland - Spirent | Target Version | => v4.9.1 (published 2017-05)
14-11-2016 16:32 | Jens Grabowski | Note Added: 0014233 |
15-11-2016 16:54 | KristÃ³f Szabados | Note Added: 0014256 |
15-11-2016 16:54 | KristÃ³f Szabados | Status | assigned => resolved
15-11-2016 16:54 | KristÃ³f Szabados | Fixed in Version | => v4.10.1 (published 2018-05)
15-11-2016 16:54 | KristÃ³f Szabados | Resolution | open => fixed
17-11-2016 14:21 | KristÃ³f Szabados | Note Added: 0014311 |
17-11-2016 14:21 | KristÃ³f Szabados | Status | resolved => feedback
17-11-2016 14:21 | KristÃ³f Szabados | Resolution | fixed => reopened
17-11-2016 14:22 | KristÃ³f Szabados | Status | feedback => resolved
17-11-2016 14:22 | KristÃ³f Szabados | Fixed in Version | v4.10.1 (published 2018-05) => v4.9.1 (published 2017-05)
17-11-2016 14:22 | KristÃ³f Szabados | Resolution | reopened => fixed
17-11-2016 14:22 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Gyorgy Rethy
09-12-2016 15:43 | Gyorgy Rethy | Note Added: 0014368 |
09-12-2016 15:43 | Gyorgy Rethy | Status | resolved => closed

Notes

(0014046)
Jacob Wieland - Spirent
08-08-2016 15:49 (edited on: 09-08-2016 15:51)

Here, the commenter confused the assignment syntax with the value-syntax. On the right-hand-side of an assignment, a structured expression is currently seen only as a short-hand notation for a lot of sub-structure assignments (i.e. only those fields that are written down, except those with the dash on the right-hand-side) are actually overwritten, everything else remains unchanged.
I also think this is a weird interpretation of the syntax, as the same syntax used in a different context, e.g. as an actual parameter, has a different meaning than on the right-hand side of an assignment.
The problem mainly here is the dash symbol which only has meaning on the right-hand-side of an assignment. It cannot be interpreted as 'uninitialized' as then the assignment would overwrite an already initialized field with 'uninitialized' unless the semantics is changed that this is always the case for assigning uninitialized.
It is also weird that the expression that can be used on the right-hand-side (using dash) cannot be used as an actual parameter and then when the corresponding formal parameter is assigned does not have the same semantics as in a direct assignment.

(0014047)
Martin Hauch
09-08-2016 10:43

From example above (initialized value {field1 := '111'B,field2 := false,
field3 := -}
The right-hand-side of the assignment
MyVariable :=
{
field2 := true
}
contains a partial value. So as defined in chapter 19.1 the value after assignment is {field1 <unitialized>, field2 true, field3 <unitialized>}. The definition in 19.1 contradicts to chapter 6.2.1 which (implicitly) introduces the short hand notation you mention. Either chapter 6.2.1 must be changed or the sentence in 19.1, which defines the assignment-semantic, must be changed!
I think it would be clearer to say 19.1 is correct! Use modified templates or syntax MyVariable.field1:='001'B, if only parts of a structure should be reassigned. The syntax and semantic of
MyVariable.field1:='001'B,
is much clearer than
MyVariable :={field2 := true}
where complicate descriptions have to be analysed to understand, what the assignment is exactly doing (depends on value-list-notation, assignment-notation,with "optional explicit omit", with "optional implicit omit").

(0014048)
Jacob Wieland - Spirent
09-08-2016 15:55

No, { field2 := true } on the right-hand-side of an assignment is not a value, but just syntax for several assignments rolled into one, which is why it is not in conflict with 19.1.
The result of the assignment (if MyVariable has uninitialized fields other than field2 before the assignment) that is stored in MyVariable is then an partially initialized value. Using that (i.e. MyVariable) on the right-hand-side of an assignment would then invoke the rules in 19.1, i.e. the uninitialized fields would be treated differently than the left-out fields in the syntax above.
The standard in 6.2.1. is very clear about this:
I quote:
When the assignment notation is used in a scope, where the optional attribute is implicitly or explicitly set to
"explicit omit", fields, not explicitly referred to in the notation, shall remain unchanged.
and also:
When the assignment notation is used in a scope, where the optional attribute is set to "implicit omit",
optional fields, not directly referred to in the notation, shall implicitly be set to omit, while mandatory fields shall
remain unchanged (see also clause 27.7).

(0014049)
Martin Hauch
10-08-2016 13:08

Question 1:
What are variable MyVariable2,MyVariable4 representing in the following example (btw. the type MyRecordType seems to be not the type that is used vor the defined variables in EXAMPLE 5 in chapter 6.2.1 of the core language):
{
type record MyRecordType{
integer field1,
boolean field2 optional,
charstring field3
}
var MyRecordType MyVariable:={field1:=1,field2:=false,field3:="hallo"};
var MyRecordType MyVariable2:={field1:=1,field2:=false,field3:="hallo"};
var MyRecordType MyVariable3,MyVariable4,;
MyVariable:={field2:=True}; //MARK1 completely assigned variable
MyVariable3:={field2:=True};//MARK2 partially assigned variable
MyVariable2:=MyVariable3; //MARK3 partially or complete assigned variable??
MyVariable4:=MyVariable3; //MARK4 partially assigned variable
}
From an intuitive view I would first expect that MyVariable and MyVariable3 are the same (because of the same rhs in MARK1 and MARK2) and MyVariable2 and MyVariable4 represent the same, i.e. ALL variables are identical. But respecting the definitions in 6.2.1 this is not the case. The content of MyVariable2 (MARK3) is not clear to me. Does the variable assignment overwrite initialized values with 'unitialized'? It is very unintuitive that you have to know the "history" of assignments to a variable to interpret the resulting value of obviously identical assignments like MARK1 and MARK2 correctly.
Question 2:
What is the complete notation for this shorthand notation:
// MyVariable is uninitialized here
MyVariable :={field2 := true}
?
I can only think of
MyVariable:={field1:=MyVariable.field1,
field2:=true,
field3:=MyVariable.field3}
because according to 19.1.a the rhs has to be type compatible with the lhs. But then, MyVariable.field1 and MyVariable.field3 are unbound and the assignment is invalid. The type compatibility according to 19.1.a is the main point for my concerns. In chapter 19.1 EXAMPLE 3 shows, how a variable could be partially assigned.
So my conclusion from above definitions in 19.1 is:
The assignment
MyVariable :={field2 := true}
is only allowed, if MyVariable has still assigned 'values' or 'omit to optional fields' "field1" and "field3". Otherwise it is an error.
If this is correct, the examples above from question 1 are not allowed, because a variable could not be initialized partially this way!
We have to be careful not to confuse/mix this with the optional omit attribute, because this is not allowed for variables yet (or at least it is unclear), and the described shorthand notation can also be used for variables with only mandatory fields.

(0014050)
Jacob Wieland - Spirent
10-08-2016 15:11

Answer to question 1:
MARK1: {1,true,"hallo"} (field1/field3 remain unchanged)
MARK2: {<undefined>,true,<undefined>} (field1/field3 remain unchanged, i.e. undefined)
MARK3: {<undefined>,true,<undefined>} (all of MyVariable3 overwrites MyVariable2)
MARK4: {<undefined>,true,<undefined>} (all of MyVariable3 overwrites MyVariable4)
You have the same problem when assigning fields with individual assignment statements, you have to know the history of the whole variable to know the end-result. Again, the field-assignment notation is just a shorthand for a set of field assignments of the mentioned fields in the notation.
In principle, I agree with your intuition, coming from other computer languages where such a notation would simply denote a (partial) value and would then be treated as such whereever it occurs, not differently just because it is on the rhs of an assignment. In that way, the language is inconsistent with other languages and the intuition they convey.
Answer to question 2:
The complete notation is
MyVariable := {
field1 := - /* explicit unchanged */,
field2 := true,
field3 := -
}
which is again shorthand for:
MyVariable.field1 := -;
MyVariable.field2 := true;
MyVariable.field3 := -;
where, of course, the assignments with - (unchanged symbol) on the right-hand-side are NOPs.
The 'shorthand' gain comes off only once you have larger structures with deep paths, that you have to repeat in each assignment statement over and over again otherwise.

(0014233)
Jens Grabowski
14-11-2016 16:32

Same as CR 0007473.

(0014256)
KristÃ³f Szabados
15-11-2016 16:54

Resolved in CR 7473

(0014311)
KristÃ³f Szabados
17-11-2016 14:21

incorrectly assigned at resolve

(0014368)
Gyorgy Rethy
09-12-2016 15:43

Resolution see in CR 7473