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

ID | Project | Category | View Status | Date Submitted | Last Update
0007493 | Part 01: TTCN-3 Core Language | New Feature | public | 16-08-2016 16:32 | 12-12-2016 20:22

Reporter | Jacob Wieland - Spirent |
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.5, 6.3.2.4, A.1.5.0
Source (company - Author) | Spirent - Jacob Wieland

Summary | 0007493: Add Wrapper-Union capability to the standard
Description | CR 7421 can be resolved if a special union modifier is introduced which adds type compatibility between union types and the type of one of their alternatives which is declared with this modifier.
Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0007421 | closed | Gyorgy Rethy | Part 09: Using XML with TTCN-3 | How to achieve full backward compatibility in case of element- and/or type-substitution

Attached Files

CR7493.docx (172,624) 17-08-2016 10:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3467&type=bug
CR7493v2.docx (175,366) 19-08-2016 11:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3497&type=bug
CR7493v3.docx (178,269) 11-09-2016 17:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=3509&type=bug
CR7493v4.docx (178,732) 19-10-2016 14:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=3512&type=bug
CR7493v5.docx (178,706) 15-11-2016 10:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=3517&type=bug
CR7493v6.docx (207,265) 15-11-2016 15:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=3524&type=bug

Issue History
Date Modified | Username | Field | Change
16-08-2016 16:32 | Jacob Wieland - Spirent | New Issue |
16-08-2016 16:32 | Jacob Wieland - Spirent | Relationship added | related to 0007421
16-08-2016 16:33 | Jacob Wieland - Spirent | Assigned To | => Jacob Wieland - Spirent
16-08-2016 16:33 | Jacob Wieland - Spirent | Status | new => assigned
17-08-2016 10:01 | Jacob Wieland - Spirent | File Added: CR7493.docx |
17-08-2016 10:02 | Jacob Wieland - Spirent | Note Added: 0014122 |
17-08-2016 10:02 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban
17-08-2016 10:02 | Jacob Wieland - Spirent | Status | assigned => confirmed
17-08-2016 10:47 | Tomas Urban | Note Added: 0014127 |
17-08-2016 10:47 | Tomas Urban | Status | confirmed => closed
17-08-2016 10:47 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
17-08-2016 10:47 | Tomas Urban | Resolution | open => fixed
17-08-2016 10:47 | Tomas Urban | Assigned To | Gyorgy Rethy => Tomas Urban
17-08-2016 10:47 | Tomas Urban | Status | closed => feedback
17-08-2016 10:47 | Tomas Urban | Resolution | fixed => reopened
17-08-2016 10:48 | Tomas Urban | Status | feedback => resolved
17-08-2016 10:48 | Tomas Urban | Resolution | reopened => fixed
17-08-2016 10:48 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
17-08-2016 11:10 | Jacob Wieland - Spirent | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:11 | Jacob Wieland - Spirent | Status | resolved => feedback
17-08-2016 11:11 | Jacob Wieland - Spirent | Resolution | fixed => reopened
17-08-2016 11:11 | Jacob Wieland - Spirent | Target Version | => v4.9.1 (published 2017-05)
17-08-2016 11:11 | Jacob Wieland - Spirent | Status | feedback => resolved
17-08-2016 11:11 | Jacob Wieland - Spirent | Fixed in Version | => v4.9.1 (published 2017-05)
17-08-2016 11:11 | Jacob Wieland - Spirent | Resolution | reopened => fixed
19-08-2016 08:31 | Gyorgy Rethy | Note Added: 0014163 |
19-08-2016 08:32 | Gyorgy Rethy | Status | resolved => feedback
19-08-2016 08:32 | Gyorgy Rethy | Resolution | fixed => reopened
19-08-2016 08:32 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
19-08-2016 08:32 | Gyorgy Rethy | Status | feedback => assigned
19-08-2016 08:32 | Gyorgy Rethy | Assigned To | Tomas Urban => Jacob Wieland - Spirent
19-08-2016 08:33 | Gyorgy Rethy | Note Edited: 0014163 | bug_revision_view_page.php?bugnote_id=14163#r317
19-08-2016 08:34 | Gyorgy Rethy | Note Edited: 0014163 | bug_revision_view_page.php?bugnote_id=14163#r318
19-08-2016 08:43 | Gyorgy Rethy | Note Edited: 0014163 | bug_revision_view_page.php?bugnote_id=14163#r319
19-08-2016 11:35 | Jacob Wieland - Spirent | File Added: CR7493v2.docx |
19-08-2016 11:38 | Jacob Wieland - Spirent | Note Added: 0014176 |
19-08-2016 11:38 | Jacob Wieland - Spirent | Status | assigned => resolved
19-08-2016 11:38 | Jacob Wieland - Spirent | Resolution | reopened => fixed
19-08-2016 11:38 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
06-09-2016 07:37 | KristÃ³f Szabados | Note Added: 0014200 |
10-09-2016 16:30 | KristÃ³f Szabados | Assigned To | Gyorgy Rethy => KristÃ³f Szabados
10-09-2016 16:30 | KristÃ³f Szabados | Note Added: 0014204 |
10-09-2016 16:30 | KristÃ³f Szabados | Status | resolved => feedback
10-09-2016 16:30 | KristÃ³f Szabados | Resolution | fixed => reopened
11-09-2016 17:13 | KristÃ³f Szabados | File Added: CR7493v3.docx |
11-09-2016 17:13 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Jacob Wieland - Spirent
11-09-2016 17:13 | KristÃ³f Szabados | Status | feedback => assigned
12-09-2016 10:49 | Jacob Wieland - Spirent | Note Added: 0014205 |
12-09-2016 10:49 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => KristÃ³f Szabados
12-09-2016 10:50 | Jacob Wieland - Spirent | Note Added: 0014206 |
15-09-2016 07:24 | KristÃ³f Szabados | Note Added: 0014207 |
15-09-2016 09:28 | Jacob Wieland - Spirent | Note Added: 0014208 |
25-09-2016 17:19 | KristÃ³f Szabados | Note Added: 0014210 |
26-09-2016 09:24 | Jacob Wieland - Spirent | Note Added: 0014211 |
26-09-2016 09:44 | Jacob Wieland - Spirent | Note Added: 0014214 |
28-09-2016 13:52 | KristÃ³f Szabados | Note Added: 0014215 |
29-09-2016 08:38 | Jacob Wieland - Spirent | Note Added: 0014216 |
19-10-2016 14:47 | KristÃ³f Szabados | File Added: CR7493v4.docx |
19-10-2016 14:49 | KristÃ³f Szabados | Note Added: 0014220 |
14-11-2016 12:50 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Jacob Wieland - Spirent
14-11-2016 12:50 | KristÃ³f Szabados | Note Added: 0014227 |
15-11-2016 10:03 | Jacob Wieland - Spirent | File Added: CR7493v5.docx |
15-11-2016 10:04 | Jacob Wieland - Spirent | Note Added: 0014239 |
15-11-2016 10:04 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban
15-11-2016 10:04 | Jacob Wieland - Spirent | Status | assigned => confirmed
15-11-2016 15:15 | Tomas Urban | File Added: CR7493v6.docx |
15-11-2016 15:27 | Tomas Urban | Note Added: 0014252 |
15-11-2016 15:27 | Tomas Urban | Status | confirmed => resolved
15-11-2016 15:27 | Tomas Urban | Resolution | reopened => fixed
15-11-2016 15:27 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
12-12-2016 19:58 | Gyorgy Rethy | Note Added: 0014396 |
12-12-2016 20:12 | Gyorgy Rethy | Note Added: 0014397 |
12-12-2016 20:12 | Gyorgy Rethy | Status | resolved => closed
12-12-2016 20:22 | Gyorgy Rethy | Note Edited: 0014396 | bug_revision_view_page.php?bugnote_id=14396#r342
12-12-2016 20:22 | Gyorgy Rethy | Note Deleted: 0014397 |

Notes

(0014122)
Jacob Wieland - Spirent
17-08-2016 10:02

please review

(0014127)
Tomas Urban
17-08-2016 10:47

The proposed solution resolves the CR and it is ready to be included into the next version of the core language specification.

(0014163)
Gyorgy Rethy
19-08-2016 08:31 (edited on: 19-08-2016 08:43)

While the solution technically is fine, its explanation is not aligned with the definitin how union is defined in TTCN-3; we define union as a set of possible choices, and thus the meaning of the sentence "declared as wrapped by using the @wrapped modifier..." doesn't sound obvious. I would prefer "declared as the default choice when no altetnative is explicitly identified by using the @default modifier...".
As you note in the example,
v_age := 34; shall automatically select the choice "number" and thus is the same as writing v_age := { number := 34 };
The meaning of @default is also more intuitive when seen in a union type declaration.

(0014176)
Jacob Wieland - Spirent
19-08-2016 11:38

STF discussion: accept Gyorgy's proposal using @default instead of @wrapped. I recoined the termini 'wrapped alternative' to 'default alternative' and 'wrapped union' to 'union with default alternative' and reformulated the text accordingly. Hopefully, this is now clearer.

(0014200)
KristÃ³f Szabados
06-09-2016 07:37

Am I correct that this also applies to expressions?
Like:
type union U1 {@default integer i};
type union U2 {@default integer j, boolean b};
var U1 v_var1 := 1;
var U2 v_var2 := 2;
var integer v_var3 := v_var1 + v_var2; // this should be correct since we are adding 2 integers (after the automatic unboxing).
var bitstring v_var4 := v_var1 + "something"; // this should be an error since an integer can not be added to a characterstring (v_var1 is an integer after unboxing)

(0014204)
KristÃ³f Szabados
10-09-2016 16:30

Reopening: we should add some more examples for the interesting cases.

(0014205)
Jacob Wieland - Spirent
12-09-2016 10:49

I take issue with two of the additional examples:
1)
log(v_u4); // results in “true” instead of “{ b:=true}” logged,
// resolving to the long notation happens before parameter passing.
It should be the other way around. v_u4 *is* equal to { b := true } and therefore, that is what is being logged. The shorthand was only used in the assignment.
2)
log(v_u32); // test case error as “v_u32” would be treated as v_u32.i,
// which is not the selected alternative
This is in my opinion plainly wrong. v_u32 is a union and therefore, whatever alternative is chosen in the union, that one will be reflected when using it as rhs-expression or logging it. The implicit unwrapping only happens when necessary,i.e. when the demanded type is only compatible with the default alternative but not with the union. The log-statement has no such restrictions.
This example could be changed to:
log(integer:v_u32)
There, the demanded type becomes integer and thus forces unwrapping. If the default alternative is not chosen, that would then lead to an error. If it is chosen, then only the unwrapped value would be logged, not the whole union.
That means, this statement is equivalent to:
log(integer:v_u32.i)

(0014206)
Jacob Wieland - Spirent
12-09-2016 10:50

also, there is a v_u5 in the comment which should probably v_u4, i.e. a typo

(0014207)
KristÃ³f Szabados
15-09-2016 07:24

Could go that way too.
We just need to clarify, what happens when.
Log is just a good example as it is a notoriously hard situation for it does not provide a context.
Raising the question: is this really a short hand, or not, or just in some cases and not in others.
Do we want the to apply the short-hand resolution before the expression is evaluated, or not.
for example:
- log(v_u32 + v_u32 + v_u32) is an integer because v_u32 is a shorthand for an integer (and if the other branch is selected this results in testcase error).
- log(v_u32 + v_u32) ... still logs an integer as v_u32 is a shorthand for an integer ...
- log (v_u32) ... is a union ... inspite of being an integer everywhere else?
- log((v_u32)) ... is an integer because of the brackets?
I believe we need to specify exactly when it is a shorthand and when it is not, otherwise it leaves too much room for interpretation ... and users will also not like if the code will work with unexpected types.

(0014208)
Jacob Wieland - Spirent
15-09-2016 09:28

I would say that in an operand-position which implies the type (or possible types) of the operand, it is a shorthand notation.
In a context-less position, it is never a shorthand notation.
Basically, it is only a shorthand notation whenever it cannot be used as the long value, i.e. either there is no context, then the long value is applicable, or there is a type-context that demands the union type itself, then it is the long version, otherwise, it is the unwrapped/short version in case that is compatible with the demanded type context.
Since simple parantheses don't supply any additional type context, the statements log(x) and log((x)) are semantically the same and will both log the long version of x.
Interesting are the comparison operators where you could get in very complex situations. Here, it is imperative to first check for compatible long-versions and, if they are not compatible, you need to check whether there is an unambiguous interpretation of a combination of long/short, short/long or short/short interpretations of the operands so that they can actually be compared, i.e. have a compatible root type.
All this is implicitly already described by the type-compatibility rules and the operators that require them.

(0014210)
KristÃ³f Szabados
25-09-2016 17:19

Wouldn't it be more "KISS" compatible to simply say that it is everywhere a shorthand notation, also noting that actual implementation might optimize the unboxing-boxing when they can?
That way:
- the rules would be much simpler and general. The meaning of a reference (for example v_u32) would be the same irrespective of what happens to be the context, what happens to be the type of the formal parameter, etc...
- there would be no need for new type compatibility. Since consistent unboxing-boxing does not need it (yet allows such implementation if that is safe and better performing).
- implementation itself would also be simpler, since there is no complex logic needed to be checked based on context, types and type compatibilities.
- when the time comes for debugging/maintenance, this would be one thing less to worry about: the same thing happens everywhere, while otherwise one would also need to check the context, usage and in case it is used in calling a function there would be no need to manually check the formal parameter list of the function (in the current for we have to mix and match the formal and actual parameters to understand where will the boxing/unboxing happen).
Admittedly this would mean that resolving the shorthand notation comes first, before passing to the log statement, to make it work consistently everywhere.

(0014211)
Jacob Wieland - Spirent
26-09-2016 09:24

On the meta-level, I have no idea what "KISS"-compatibility means.
Also, I'm sorry, but I don't understand what you are proposing here, so please read what I am writing next with that in mind.
If a right-hand-side reference to a union variable v with a default alternative a is ALWAYS expanded to its long form v.a, then how am I supposed to access v.b? Same argument applies to the left-hand-side. If it is always first expanded, then how am I supposed to set a different alternative than a? If I wanted something that is always just the type of a, I would use that type instead of the union with default alternative.
Also, it would be weird that a variable behaves differently in regard to wrapping, depending on what alternative is chosen. Logging a union variable should not fail if a non-default alternative is chosen in it.
So, while your proposal might make the life of the implementer simpler (though I don't see yet, how), it will definitely make the life of the user very much harder as these unions cannot be used in the normal way that they are used to anymore, but behave totally differently.
As the proposal is today, resolving where the short form is to be expanded can be done statically from type-information at compile-time, so the compiler will probably already replace all short-forms with their respective long-forms before generating code and no additional runtime-effort is needed at all.

(0014214)
Jacob Wieland - Spirent
26-09-2016 09:44

Now I have found out what the KISS-principle means and I think my proposal is very much on par with it.
Basically, the rule is pretty straightforward and simple:
A union with a default alternative behaves like every other union except in those places where the usage of that union would be a semantic error (under normal union rules), so these previous error-cases get a semantic meaning.
And in those cases, the usage is only allowed if the usage of the default alternative would not be an error and then it is interpreted as a short-form of the unwrapped default alternative.
The first part of this is to adhere to the "principle of least surprise". If a thing is defined as a union, that semantics should come first.
The next is semantic robustness: code that worked with a union type without a default alternative will work the same way if one of the alternatives is later changed to be default.

(0014215)
KristÃ³f Szabados
28-09-2016 13:52

in the case of using variable v with a default alternative I meant that "v.a" and "v.b" would still be possible, but when there is only "v" as the whole reference it could be treated as "v.a". So it would always be possible to reach other alternatives and read/assign value to them.

(0014216)
Jacob Wieland - Spirent
29-09-2016 08:38

But that does not work in those cases where v is used in its capacity as a union value (i.e. assigned to a union variable, used as actual union parameter, compared with another union variable/constant, matched against union template, etc.).
So, all these currently normal cases would suddenly become the exceptional cases while the few instances (log, receive, send statements) where no type is required would behave differently.
Also, it would be weird that log(v) works differently in case that v.a is chosen than when v.b is chosen. If you replace the v with v.a at compile time, it would be an error, if actually b is chosen in v at runtime. Otherwise, you obviously have to not replace it at compile-time and do runtime-checking instead. The same applies for all other untyped places. I really don't see the simplicity in that.

(0014220)
KristÃ³f Szabados
19-10-2016 14:49

Yes, we could have some special treatment for this in log statements, when it is not used in an expression (that would force the unwrapping).

(0014227)
KristÃ³f Szabados
14-11-2016 12:50

please review

(0014239)
Jacob Wieland - Spirent
15-11-2016 10:04

changed 'shall' in NOTE 3 to 'will'. Otherwise, ok, please review and resolve.

(0014252)
Tomas Urban
15-11-2016 15:27

I reviewed the proposal an made one cosmetic correction. The proposal contains reasonable changes and can be added to the next version of the core language standard.

(0014396)
Gyorgy Rethy
12-12-2016 19:58 (edited on: 12-12-2016 20:22)

Added to V4.8.2. Note 2 of 6.3.2.4 is extracted to a mandatory text, as in fact it specifies a requirement (order of using the rules for compatibility checking).