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
0007139Part 01: TTCN-3 Core LanguageClarificationpublic13-08-2015 08:2811-12-2015 14:29
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityhave 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) 
Summary0007139: Unnecessary rule on uniqueness of enumerated values
DescriptionThe section 6.2.4 states that: "The identifiers of enumerated values shall only be reused within other structured type definitions and shall not be used for identifiers of local or global visibility at the same or a lower level of the same branch of the scope hierarchy (see scope hierarchy in clause 5.2)."

The scope of the enumerated values is the enumerated type itself. Thus, there can never be a conflict with an identifier that has a global visibility. And the rule forbidding reusing of identifiers inside the same enumerated type (i.e. at the same and lower scope) is already defined: "The identifiers of enumerated values shall be unique within the enumerated type (but do not have to be globally unique) and are consequently visible in the context of the given type only."

For these reasons I find the above mentioned rule on global and local visibility superfluous and suggest that it should be dropped.
TagsNo tags attached.
Clause Reference(s)6.2.4
Source (company - Author)STF 487
Attached Filesdocx file icon CR7139.docx [^] (381,538 bytes) 04-11-2015 13:44
docx file icon CR7139_resolution_v2.docx [^] (76,038 bytes) 04-11-2015 15:02

- Relationships

-  Notes
(0013153)
Tomas Urban (reporter)
13-08-2015 09:45

 The problem seems to be more complex. There is one place suggesting that the identifiers of enumerated values cannot be reused. The section 5.2.2 (uniqueness on identifiers) says that enumerated value identifiers can be reused only in other enumerated types: "Identifiers for fields of structured types, enumerated values and groups do not have to be globally unique, however in the case of enumerated values the identifiers shall only be reused for enumerated values within other enumerated types."

However the code in the example 1 of 6.2.4 violates this rule completely and provides reasonable description suggesting a completely different behaviour which is inline with complex-specific resolution of enumerate value identifiers.

In my opinion, the example is right and the rule on uniqueness should be removed. There has been a shift to context-specific interpretation of enumerated values in previous TTCN-3 specifications and I think that the uniqueness rule was just left unnoticed. Nevertheless, if I am mistaken, something has to be done with the example 1.

There's also one additional rule that is affected by this issue: "When a TTCN-3 module parameter, formal parameter, constant, variable, non-parameterized template or parameterized template with all formal parameters having default values of an imported enumerated type is defined, the name of that definition shall not be the same as any of the enumerated values of that type."

In case the uniqueness rule is dropped, then it is possible to create local definitions of an enumerated type reusing one of the enumerated value identifiers:

module Module1 {
  type enumerated Days { Monday, Tuesday, Wednesday }
  control {
    var Days v_day := Monday, Monday := Tuesday;
    if (v_day == Monday) {...} //comparing v_day with an enumerated value
    // but how to compare v_day and Monday variables?
  }
}

The easy fix for this issue would be to remove the word "imported" from the above mentioned rule.
(0013154)
Tomas Urban (reporter)
13-08-2015 09:56

 In case of dropping the uniqueness rule, one more issue has to be addressed: the enumerated value identifiers have to take precedence over definitions. There's a rule for imported enumerations covering this issue in 8.2.3.1: "when in the context of an enumerated type (see clause 6.2.4), an enumerated value is clashing with the name of a definition in the importing module, the enumerated value shall take precedence and the definition in the importing module shall be referenced by using its qualified name (see example 4 below in this clause)."

This rule should be valid to local definitions as well.
(0013155)
Jacob Wieland - Spirent (reporter)
13-08-2015 13:57

 Since it is a definite source of a possible error to define a thing of an enum type E with the same name as one of E's values, I would still forbid this, even if there is some rule that semantically defines this.

imagine an enumeration E which does not have name V.

I then declare

var E V and subsequently use V.

Later on, someone else changes E and adds V. Suddenly, my code means something completely different in all places where I use V in the context of E.

This should be avoided and lead to an error, i.e. forcing me to rename (or forcing the other person to choose a different name)
(0013156)
Tomas Urban (reporter)
13-08-2015 14:26

 Jacob, I completely agree and I don't want to change this. My point is that the current TTCN-3 rules provide three different interpretations for reuse of identifiers:

According to 5.2.2 the enumerated value identifier cannot be reused even in other structured types in the same module.

6.2.4 allows the reuse in structured type, but it probably (because the text is not very comprehensive) doesn't allow the reuse e.g. as a name of a type which should be completely harmless.

And there is also the importing rule - variables etc. of imported enum types cannot have the same name as one of the enumerated values. The rule is brilliant, the only problem is that it should be valid for all enumerations and not only for imported ones.

My proposal is to drop the restrictions to a minimum: enumerated value identifiers can be reused anywhere with the exception of the enum type scope and values of the defining enumerated type.
(0013157)
Jacob Wieland - Spirent (reporter)
13-08-2015 14:37

 If I just understood what that means, I could agree. Alas, I don't.

In my opinion, enum value-names could be re-used for anything except other value-names in the same enumerated type definition and all entities declared with the enumerated type as their type.

Also, imagine the following situation:

enumerated E1 { a }
enumerated E2 { b }

const E1 b := a;
const E2 a := b;

What does the expression (a == b) mean?
(0013158)
Tomas Urban (reporter)
13-08-2015 20:49

 > In my opinion, enum value-names could be re-used for anything except other value-names in the same enumerated type definition and all entities declared with the enumerated type as their type.

Thumbs up for that. But compare it with the two problematic rules quoted above:

"The identifiers of enumerated values shall only be reused within other structured type definitions and shall not be used for identifiers of local or global visibility at the same or a lower level of the same branch of the scope hierarchy (see scope hierarchy in clause 5.2)."

"Identifiers for fields of structured types, enumerated values and groups do not have to be globally unique, however in the case of enumerated values the identifiers shall only be reused for enumerated values within other enumerated types."

Do these rule support your interpretation? I don't think so. And I don't even think they are compatible. That's why I propose to remove them (and eventually replace with something better).

Your example is indeed quite tricky. Because statements are typically processed in the textual order, I would expect "a" to be interpreted first as the constant "a" (for no enumeration context is known at that point - we just started processing) and "b" to be interpreted as the enumerated value "b" of the type E2 (as we can establish an implicit reference to the type E2 through the constant "a" at this point). The expression would then yield true.
(0013159)
Jacob Wieland - Spirent (reporter)
14-08-2015 07:56

 I totally disagree. Expressions are first evaluated for their syntactic and semantic properties and then evaluated.

Otherwise, you could never write something like <enumValue> == <enumVariable> because enumValue has no enum context when processing from left to right.

But, since a == b should always be equivalent to b == a for expressions a and b without side-effects, your approach would violate this rule.

Sure, we already have that situation at the moment if two enums share the same values and then two values from that intersection are to be compared (as then the enum-context also cannot be determined) but in that situation at least only enum-values are involved and no additional potential clash with local items is possible.

Basically, the rules as they are now do the following:

They disallow the situation that I have described (as a and b would be disallowed in the same module to be redefined as constants) and they always allow to resolve nameclashes by prefixing. If an enum-value can shadow a local variable of the same type that is no longer the case, so that definitely needs to stay forbidden).
(0013160)
Tomas Urban (reporter)
14-08-2015 09:18

 > Otherwise, you could never write something like <enumValue> == <enumVariable> because enumValue has no enum context when processing from left to right.

I don't agree with that statement. Processing from left to right only takes precedence. If it is not possible to use it, right to left is used as the second option and resolves the symbols without any problem.

Your example is currently a valid code in TTCN-3, in case the enumeration types are imported to the module where constants "a" and "b" are defined. So how do you resolve it in this case, especially if constants are locally defined and cannot be prefixed?
(0013161)
Jacob Wieland - Spirent (reporter)
14-08-2015 12:34

 I disagree, at the moment it is invalid code because it is ambiguous. There is no rule that says that the left argument takes precedence over the right argument when determining enumeration context.

In the case of local definitions, I would always give precedence to the local definition (as do all languages normally) and if it is a global definition, I can prefix the constant and therby establish unambiguity. (a must be defined in a different module than enum value a, same with b, so the module prefix determines which it is).
(0013162)
Tomas Urban (reporter)
14-08-2015 13:20

 > I disagree, at the moment it is invalid code because it is ambiguous.
Please refer to the TTCN-3 rules which are violated in the example below.

module Module1 {
  type enumerated E1 { a }
  type enumerated E2 { b }
}

module Module2 {
  imports from Module1 all;
  control {
    const E1 b := a;
    const E2 a := b;
    log(a == b);
  }
}

> In the case of local definitions, I would always give precedence to the local definition (as do all languages normally) and if it is a global definition, I can prefix the constant and therby establish unambiguity. (a must be defined in a different module than enum value a, same with b, so the module prefix determines which it is).

Unfortunately, TTCN-3 does NOT behave this way. The rules of 8.2.3.1 (which I already mentioned here) describe quite unambiguously this situation: "There is one exception to this rule: when in the context of an enumerated type (see clause 6.2.4), an enumerated value is clashing with the name of a definition in the importing module, the enumerated value shall take precedence and the definition in the importing module shall be referenced by using its qualified name (see example 4 below in this clause)." Please open the specification and take a look at the example.

But before you do that, just take a look at the discussion here. I actually don't try to defend any kind of interpretation. I would be fine with any as long as there's just one. My point is that the current rules just don't offer that. They are contradictory and contain blank spots.
(0013165)
Tomas Urban (reporter)
14-08-2015 13:49
edited on: 14-08-2015 13:51

 Maybe there's a simple solution for this situation:

1. Enumerated value identifiers shall be unique just within the enumerated type
2. Enumerated value identifiers can be reused for other definitions (in the module where the enumeration is defined, in importing modules and even for constant/variables/templates of the defining enumerated type)
3. When resolving identifiers, global and local references are ALWAYS resolved first (i.e. if there's an enumerated value and a variable of the same name, it is always resolved as a variable even if it means type mismatch)
4. In order to resolve name clashes, a new concept of extended enumerated value reference will be introduced: EnumeratedTypeReference.EnumeratedValue.

What do you think?
(0013168)
Jacob Wieland - Spirent (reporter)
17-08-2015 08:41

 In principle, in a language where there is no other overloading, I like this approach much better than what we have now, but I'm sure that this change is not backward-compatible. (In pathological cases, of course. At the moment, it is allowed to have an integer-variable i and an enum-value i).

type enumerated E { i }

function(integer i, E e) {
  if (e == i) { // enum interpretation of i
  }
  if (3 == i) { // integer interpretation of i
  }
}

function g() {
  var integer i := 3;
  f(i, i); // first i is the integer variable, second i is the enum value
}

So, to preserve this (unambiguous) behavior, I would suggest that only in type-ambiguous cases of name-clashing identifiers (where the enum-context cannot be unambiguously established), local definitions shall have precedence before the enum value (and then the clash can be resolved towards the enum-value by prefixing with the enum type - which at the moment I always do with valueof(E:v) ;-)).

So, the a == b example in this case would then cause an error as it would resolve both a and b to the constants and their types are not compatible. The user would have to add an enum-type-prefix either before a or b or add a module-prefix before a or b (if they are global) to establish an unambiguous enum-context.
(0013169)
Tomas Urban (reporter)
17-08-2015 09:32

 I have no problem with this solution. It might require more rules to describe, but backwards compatibility is important and the compiler might always issue a warning in the cases where prefixing would make code more readable. I am looking forward for the proposal draft.
(0013218)
Gyorgy Rethy (reporter)
21-09-2015 15:38

 STF discussion: CR is low priority, because the restriction does not cause a problem.
(0013476)
Gyorgy Rethy (reporter)
03-11-2015 15:03

 STF discussion: analyse if the other enumerated rules restricting enumeration value names are covering all possible name clashing scenarios.
(0013486)
Jacob Wieland - Spirent (reporter)
04-11-2015 13:51

 aligned the description in 5.2 with the one in 6.2.4, i.e. enum values in a module can be used as other enum values or as fields of structured types but nothing else.

The reasoning is that the existing restrictions align the feature with the rest of the language:
- no shadowing/overloading in the same module (re-using constant name as type name is also not allowed, but would in principle not be a problem) - except for enumerated values
- name-clashes between local variable and imported value can always be resolved by module-prefixing (no new enumtype-prefixing context needed)
(0013487)
Jacob Wieland - Spirent (reporter)
04-11-2015 13:53

 please review and resolve
(0013491)
Gyorgy Rethy (reporter)
04-11-2015 15:06

 CR7139_resolution_v2.docx: the addition to clause 6.2.4 is true within a module only. In other modules, importing the enumerated type, enumeration names can be used as names of non-enumerated definitions. This is the whole "context business" about.

Please review.
(0013494)
Jacob Wieland - Spirent (reporter)
04-11-2015 17:21

 I think the addition is redundant as the scope of the whole paragraph is talking about the uniqueness inside one module scope. But, it doesn't hurt, either, so we can leave it as is.
(0013590)
Gyorgy Rethy (reporter)
11-12-2015 14:29

 Added to draft V4.7.4

- Issue History
Date Modified Username Field Change
13-08-2015 08:28 Tomas Urban New Issue
13-08-2015 09:45 Tomas Urban Note Added: 0013153
13-08-2015 09:56 Tomas Urban Note Added: 0013154
13-08-2015 13:57 Jacob Wieland - Spirent Note Added: 0013155
13-08-2015 14:26 Tomas Urban Note Added: 0013156
13-08-2015 14:37 Jacob Wieland - Spirent Note Added: 0013157
13-08-2015 20:49 Tomas Urban Note Added: 0013158
14-08-2015 07:56 Jacob Wieland - Spirent Note Added: 0013159
14-08-2015 09:18 Tomas Urban Note Added: 0013160
14-08-2015 12:34 Jacob Wieland - Spirent Note Added: 0013161
14-08-2015 13:20 Tomas Urban Note Added: 0013162
14-08-2015 13:49 Tomas Urban Note Added: 0013165
14-08-2015 13:51 Tomas Urban Note Edited: 0013165 View Revisions
14-08-2015 13:51 Tomas Urban Note Edited: 0013165 View Revisions
17-08-2015 08:41 Jacob Wieland - Spirent Note Added: 0013168
17-08-2015 09:32 Tomas Urban Note Added: 0013169
21-09-2015 10:27 Gyorgy Rethy Target Version => v4.8.1 (published 2016-07)
21-09-2015 15:38 Gyorgy Rethy Note Added: 0013218
21-09-2015 15:39 Gyorgy Rethy Priority normal => low
03-11-2015 15:03 Gyorgy Rethy Note Added: 0013476
03-11-2015 15:03 Gyorgy Rethy Assigned To => Jacob Wieland - Spirent
03-11-2015 15:03 Gyorgy Rethy Status new => assigned
04-11-2015 13:44 Jacob Wieland - Spirent File Added: CR7139.docx
04-11-2015 13:51 Jacob Wieland - Spirent Note Added: 0013486
04-11-2015 13:53 Jacob Wieland - Spirent Note Added: 0013487
04-11-2015 13:53 Jacob Wieland - Spirent Assigned To Jacob Wieland - Spirent => Jens Grabowski
04-11-2015 13:53 Jacob Wieland - Spirent Status assigned => confirmed
04-11-2015 14:52 Gyorgy Rethy File Added: CR7139_resolution_v2.docx
04-11-2015 14:59 Gyorgy Rethy File Deleted: CR7139_resolution_v2.docx
04-11-2015 15:02 Gyorgy Rethy File Added: CR7139_resolution_v2.docx
04-11-2015 15:06 Gyorgy Rethy Note Added: 0013491
04-11-2015 15:06 Gyorgy Rethy Assigned To Jens Grabowski => Jacob Wieland - Spirent
04-11-2015 15:06 Gyorgy Rethy Status confirmed => assigned
04-11-2015 17:21 Jacob Wieland - Spirent Note Added: 0013494
04-11-2015 17:21 Jacob Wieland - Spirent Status assigned => resolved
04-11-2015 17:21 Jacob Wieland - Spirent Fixed in Version => v4.8.1 (published 2016-07)
04-11-2015 17:21 Jacob Wieland - Spirent Resolution open => fixed
04-11-2015 17:21 Jacob Wieland - Spirent Assigned To Jacob Wieland - Spirent => Gyorgy Rethy
11-12-2015 14:29 Gyorgy Rethy Note Added: 0013590
11-12-2015 14:29 Gyorgy Rethy Status resolved => closed

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