Hello all,

The TTCN-3 standard says, that 'named identifiers shall be unique within
the enumerated tpye (but do not have to be globally unique)', section
6.3.3.

Therefore, in the example below, the type declarations of A and B are
correct TTCN-3 code. The situation becomes more complicated, when the
named identifiers shall be used. E.g. what is the correct semantics of
the function f below: Is it incorrect TTCN-3 because it is not correctly
typed, is its return value true or is its return value false. Any
decision for true or false would be an arbitrary one.

As far as I can see the notation A:a, which is possible for templates,
cannot be used for named identifiers. Is there any chance to determine
whether a and b in the function f belong to type A or B?

As soon as one of a and b is changed to a constant or variable of type A
or B, resp., then type inference can be used to determine of which type
a and b should be.

module tc {
type enumerated A
{
a, b
}

type enumerated B
{
b, a
}

function f () return boolean
{
return ( a < b );
}

}

Any opinions out there on how this TTCN-3 code should be handled? Thanks
for your help.

Best regards

Thomas

---

| Thomas Deiß, Nokia Research Center Street address: |
| P.O. Box 101823 Meesmannstraße 103 |
| D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
| Phone: +49 234 984 2217 (int. 8272217) |
| Fax: +49 234 984 3491 (int. 8273491) |
| E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

On Mon, 3 Dec 2001, Thomas Deiß wrote:

> Hello all,
>
> The TTCN-3 standard says, that 'named identifiers shall be unique within
> the enumerated tpye (but do not have to be globally unique)', section
> 6.3.3.

Actually, this is contradictory to the statement that all
identifiers known in one scope have to be unique.

This would mean that two enumeration types which are known in the
same scope must map the same identifier to the same value to
make the 'meaning' of that identifier 'unique' in that scope.

Otherwise, if you really want to have such an exception to
the general rule, I see no solution to the problem you stated
else from making sure that at least the order of the
enumerated values must be the same over all enumerations.

Then, it must be statically checked if all enumerated values
can be ordered topologically (i.e. without any cycles).

type enumerated A {
a, b
}

type enumerated B {
b, c
}

type enumerated C {
c, a
}

would have to result in a compiler error.

However, this less restricted approach is very error-prone as a
compiler would probably then have to assign arbitrary numbers to
enumerated values where no explicit values are given, and, if you
want to use such enumerated values as indices of an array (if that
is possible in TTCN-3), this could - of course - result in
runtime-errors.

I would stick to the rule of identifier-uniqueness, as not
to confuse the user of the language with exceptions.

Jacob Wieland, TU-Berlin

Hi,

Identifier uniqueness IS assured. The scope of each named value is the enumerated type itself. Like the scope of the identifiers for record or set elements: their scope is the type itself within which the identifier is declared.

Therefore to reference a value from an enumaretad type, the type itself shall be referenced implicitly (e.g. when the enumareted type is an element of a record type, and assigning value to this element implicitly quote the given enumerated type) or excplicitly.

What shall be done for the given problem is to allow explicit reference for the type. One possible way to do it is to change the bnf like:

EnumeratedValue ::= [ EnumTypeIdentifier ":"] NamedValueIdentifier,

where the [ EnumTypeIdentifier ":" ] tag shall not be used in assignments where the type is referenced implicitly or before the AssignmentChar.

Best Regards, György

============================================
dr. György RÉTHY
Ericsson Communications Systems Hungary Lim.
Conformance Center
tel.: +36 1 437-7006; fax: +36 1 437-7767
mobile: +36 30 297-7862
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
web: www.r.eth.ericsson.se/~ethgry
============================================


>

---

Original Message

---

>From: Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Monday, December 03, 2001 5:02 PM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: Global uniquess of elements in enumerated types
>
>
>On Mon, 3 Dec 2001, Thomas Deiß wrote:
>
>> Hello all,
>>
>> The TTCN-3 standard says, that 'named identifiers shall be
>unique within
>> the enumerated tpye (but do not have to be globally unique)', section
>> 6.3.3.
>
>Actually, this is contradictory to the statement that all
>identifiers known in one scope have to be unique.
>
>This would mean that two enumeration types which are known in the
>same scope must map the same identifier to the same value to
>make the 'meaning' of that identifier 'unique' in that scope.
>
>Otherwise, if you really want to have such an exception to
>the general rule, I see no solution to the problem you stated
>else from making sure that at least the order of the
>enumerated values must be the same over all enumerations.
>
>Then, it must be statically checked if all enumerated values
>can be ordered topologically (i.e. without any cycles).
>
>type enumerated A {
> a, b
>}
>
>type enumerated B {
> b, c
>}
>
>type enumerated C {
> c, a
>}
>
>would have to result in a compiler error.
>
>However, this less restricted approach is very error-prone as a
>compiler would probably then have to assign arbitrary numbers to
>enumerated values where no explicit values are given, and, if you
>want to use such enumerated values as indices of an array (if that
>is possible in TTCN-3), this could - of course - result in
>runtime-errors.
>
>I would stick to the rule of identifier-uniqueness, as not
>to confuse the user of the language with exceptions.
>
>Jacob Wieland, TU-Berlin
>

On Tue, 4 Dec 2001, Gyorgy Rethy (ETH) wrote:

> Hi,
>
> Identifier uniqueness IS assured.
> The scope of each named value is the enumerated type itself.
> Like the scope of the identifiers for record or set elements:
> their scope is the type itself within which the identifier is declared.
>

The scope of an identifier (on its own) is not the scope of the
definition, but the scope where it is _known_ (on its own).
(For records this is not the same, as the field identifiers
can nowhere be used _on their own_, but only as selectors of
record values where the type is already clear)

If the same identifier is _known_ in one scope with different
semantics (i.e. values), this is called overloading.

So, what you propose is to introduce overloading for the
enumeration types into TTCN-3.
The solution you propose is the normal way to resolve overloading,
i.e. you have to make hypotheses about the type of an identifier
and later on check if these hypotheses are in some way consistent
with each other and the context (i.e. the type of the
field/variable/parameter it is assigned to) and also if they are
unambiguous (i.e. have only one solution, which wasn't the case
in the a < b example).

In my understanding of TTCN-3 up until now, it was intended that
not everything can be annotated with a type to resolve overloading
since there simply _is_ no overloading intended. The change in
the language you propose is only necessary because you want to
allow it nevertheless.

But, if you do so, why only for enumerations?
This would make the language more unorthogonal
and thus more complex to understand.

Of course, if you introduce overloading generally (because your
argument can be applied to all kinds of identifiers, naturally),
then this would increase usability for those who understand
the concept of overloading, but make it probably even less
understandable for everybody else.

Jacob Wieland

I find the problem with overloading, for those that have a problem, is
talking about it in the first place. If you just get on and do it, they have
less of a problem.

Show someone

i:=3; x:=4.5;

where i is an integer, and that person is happy. Start talking of what is
actually happening, overloading, and some people start to get glassy eyed.

Translated into a technical opinion, that means if we want to do general
overloading, we should just get on and do it and show people some simple
examples. But it's probably a bit late for doing it now.

Regards

Derek

---

Derek C Lazenby
Anite
127 Fleet Road
Fleet
Hampshire
GU51 3QN
Tel : +44 1252 775200
Fax: +44 1252 775299

---

Anite Telecoms Limited Registered in England No. 1721900 Registered
Office: 100 Longwater Avenue, GreenPark, Reading, Berkshire RG2 6GP,
United Kingdom

---

Original Message

---

From: Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 04 December 2001 14:17
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Global uniquess of elements in enumerated types


On Tue, 4 Dec 2001, Gyorgy Rethy (ETH) wrote:

> Hi,
>
> Identifier uniqueness IS assured.
> The scope of each named value is the enumerated type itself.
> Like the scope of the identifiers for record or set elements:
> their scope is the type itself within which the identifier is declared.
>

The scope of an identifier (on its own) is not the scope of the
definition, but the scope where it is _known_ (on its own).
(For records this is not the same, as the field identifiers
can nowhere be used _on their own_, but only as selectors of
record values where the type is already clear)

If the same identifier is _known_ in one scope with different
semantics (i.e. values), this is called overloading.

So, what you propose is to introduce overloading for the
enumeration types into TTCN-3.
The solution you propose is the normal way to resolve overloading,
i.e. you have to make hypotheses about the type of an identifier
and later on check if these hypotheses are in some way consistent
with each other and the context (i.e. the type of the
field/variable/parameter it is assigned to) and also if they are
unambiguous (i.e. have only one solution, which wasn't the case
in the a < b example).

In my understanding of TTCN-3 up until now, it was intended that
not everything can be annotated with a type to resolve overloading
since there simply _is_ no overloading intended. The change in
the language you propose is only necessary because you want to
allow it nevertheless.

But, if you do so, why only for enumerations?
This would make the language more unorthogonal
and thus more complex to understand.

Of course, if you introduce overloading generally (because your
argument can be applied to all kinds of identifiers, naturally),
then this would increase usability for those who understand
the concept of overloading, but make it probably even less
understandable for everybody else.

Jacob Wieland

Hi,

You are simply wrong. I'm not proposing nothing new (except the notation) as the draft says today that names of values of an enumerated type shall be unique within the given type only. Named values of an enumerated type are not known as identifiers on their own. For example:

type enumerated E1 := { a, b, c } // a, b and c are just values of
the type but not identifiers like
// the name of constants or variables !
var integer a := 5

causes no ambiguity and very clearly in the case of
var integer b := a

the initial value of "b" will be 5 and there is no ambiguity that it is possibly going about type incompatibilty (a better example follows later). In the case of relational operations I think it was simply forgotten that the scope of enumerations is different than the scope of "normal" constants and variables.


The case is similar to named numbers or named bits in ASN.1. For example in the case of:

AA ::= INTEGER { x(0) }

x INTEGER ::= 2

y INTEGER ::= x
z AA ::= x

The value of y is 2, while the value of z is 0 without any ambiguity. And the named number "x" (defined within the type AA) has nothing to do with the value "x". While the scope of the value "x" is the ASN.1 module, the scope of the named number "x" is the type AA itself, it is not seen outside of this type. Simply given values of the type is getting an additional name and this is similar to the enumerated type with the exception, that in the case of enumerated only the name can be used when referencing a distinct value of the type.

So, there is one more proposal to the draft:
To remove any ambiguity in this issue is to avoid to use the word "identifier" in subclause 6.3.4 (enumerated definition) of the standard and call distinct values of the type simply enumerations (like ASN.1).

If you think this is a change to the current understanding of TTCN-3, I can not agree, because no clear understanding is given in the current draft at all on this issue. And why haven't I proposed to change the overloading concept of TTCN-3? For two reasons:
1. It would be incompatible with ASN.1 (if named values of enumerations would be seen outside of the type);
2. Exactly for the reason you are writing.

Best Regards, György

============================================
dr. György RÉTHY
Ericsson Communications Systems Hungary Lim.
Conformance Center
tel.: +36 1 437-7006; fax: +36 1 437-7767
mobile: +36 30 297-7862
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
web: www.r.eth.ericsson.se/~ethgry
============================================


>

---

Original Message

---

>From: Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Tuesday, December 04, 2001 3:17 PM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: Global uniquess of elements in enumerated types
>
>
>On Tue, 4 Dec 2001, Gyorgy Rethy (ETH) wrote:
>
>> Hi,
>>
>> Identifier uniqueness IS assured.
>> The scope of each named value is the enumerated type itself.
>> Like the scope of the identifiers for record or set elements:
>> their scope is the type itself within which the identifier
>is declared.
>>
>
>The scope of an identifier (on its own) is not the scope of the
>definition, but the scope where it is _known_ (on its own).
>(For records this is not the same, as the field identifiers
>can nowhere be used _on their own_, but only as selectors of
>record values where the type is already clear)
>
>If the same identifier is _known_ in one scope with different
>semantics (i.e. values), this is called overloading.
>
>So, what you propose is to introduce overloading for the
>enumeration types into TTCN-3.
>The solution you propose is the normal way to resolve overloading,
>i.e. you have to make hypotheses about the type of an identifier
>and later on check if these hypotheses are in some way consistent
>with each other and the context (i.e. the type of the
>field/variable/parameter it is assigned to) and also if they are
>unambiguous (i.e. have only one solution, which wasn't the case
>in the a < b example).
>
>In my understanding of TTCN-3 up until now, it was intended that
>not everything can be annotated with a type to resolve overloading
>since there simply _is_ no overloading intended. The change in
>the language you propose is only necessary because you want to
>allow it nevertheless.
>
>But, if you do so, why only for enumerations?
>This would make the language more unorthogonal
>and thus more complex to understand.
>
>Of course, if you introduce overloading generally (because your
>argument can be applied to all kinds of identifiers, naturally),
>then this would increase usability for those who understand
>the concept of overloading, but make it probably even less
>understandable for everybody else.
>
>Jacob Wieland
>

Hi,

I agree. First of all it is too late to debate about overlading. Secondly this is not an overloading issue. If TTCN-3 allowed the following:
var integer x := 5;
var real x := 5E-3;

and than sorting out which identifier "x" to be used for an assignment
var integer y := x

it would be an overloading problem.

But we are talking about something else, what has to do nothing with overloading. As if I add:
var integer z := 5;
var charstring v := "aa";
var charstring w := "aa";

we do not start to talk about "value overloading" or "string overloading".

Best Regards, György

============================================
dr. György RÉTHY
Ericsson Communications Systems Hungary Lim.
Conformance Center
tel.: +36 1 437-7006; fax: +36 1 437-7767
mobile: +36 30 297-7862
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
web: www.r.eth.ericsson.se/~ethgry
============================================


>

---

Original Message

---

>From: Lazenby, Derek [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Wednesday, December 05, 2001 10:33 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: Global uniquess of elements in enumerated types
>
>
>I find the problem with overloading, for those that have a problem, is
>talking about it in the first place. If you just get on and do
>it, they have
>less of a problem.
>
>Show someone
>
>i:=3; x:=4.5;
>
>where i is an integer, and that person is happy. Start talking
>of what is
>actually happening, overloading, and some people start to get
>glassy eyed.
>
>Translated into a technical opinion, that means if we want to
>do general
>overloading, we should just get on and do it and show people
>some simple
>examples. But it's probably a bit late for doing it now.
>
>Regards
>
>Derek
>
>

---

>Derek C Lazenby
>Anite
>127 Fleet Road
>Fleet
>Hampshire
>GU51 3QN
>Tel : +44 1252 775200
>Fax: +44 1252 775299
>

---

>Anite Telecoms Limited Registered in England No. 1721900 Registered
>Office: 100 Longwater Avenue, GreenPark, Reading, Berkshire RG2 6GP,
>United Kingdom
>
>
>

---

Original Message

---

>From: Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: 04 December 2001 14:17
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: Global uniquess of elements in enumerated types
>
>
>On Tue, 4 Dec 2001, Gyorgy Rethy (ETH) wrote:
>
>> Hi,
>>
>> Identifier uniqueness IS assured.
>> The scope of each named value is the enumerated type itself.
>> Like the scope of the identifiers for record or set elements:
>> their scope is the type itself within which the identifier
>is declared.
>>
>
>The scope of an identifier (on its own) is not the scope of the
>definition, but the scope where it is _known_ (on its own).
>(For records this is not the same, as the field identifiers
>can nowhere be used _on their own_, but only as selectors of
>record values where the type is already clear)
>
>If the same identifier is _known_ in one scope with different
>semantics (i.e. values), this is called overloading.
>
>So, what you propose is to introduce overloading for the
>enumeration types into TTCN-3.
>The solution you propose is the normal way to resolve overloading,
>i.e. you have to make hypotheses about the type of an identifier
>and later on check if these hypotheses are in some way consistent
>with each other and the context (i.e. the type of the
>field/variable/parameter it is assigned to) and also if they are
>unambiguous (i.e. have only one solution, which wasn't the case
>in the a < b example).
>
>In my understanding of TTCN-3 up until now, it was intended that
>not everything can be annotated with a type to resolve overloading
>since there simply _is_ no overloading intended. The change in
>the language you propose is only necessary because you want to
>allow it nevertheless.
>
>But, if you do so, why only for enumerations?
>This would make the language more unorthogonal
>and thus more complex to understand.
>
>Of course, if you introduce overloading generally (because your
>argument can be applied to all kinds of identifiers, naturally),
>then this would increase usability for those who understand
>the concept of overloading, but make it probably even less
>understandable for everybody else.
>
>Jacob Wieland
>

On Wed, 5 Dec 2001, Lazenby, Derek wrote:

> I find the problem with overloading, for those that have a problem, is
> talking about it in the first place. If you just get on and do it, they have
> less of a problem.
>
> Show someone
>
> i:=3; x:=4.5;
>
> where i is an integer, and that person is happy. Start talking of what is
> actually happening, overloading, and some people start to get glassy eyed.

Huh? Where is there overloading in that example?

The use of the same identifier with different types in the same
scope is called overloading.

integer i := 3;
float i := 5.3;

Jacob Wieland

On Wed, 5 Dec 2001, Gyorgy Rethy (ETH) wrote:

> Hi,
>
> You are simply wrong. I'm not proposing nothing new (except the notation) as
the draft says today that names of values of an enumerated type shall be unique
within the given type only. Named values of an enumerated type are not known as
identifiers on their own. For example:
>

Firstly, I'm not concerned, what the actual draft says,
as what it says is in my opinion contradictory.

Also, we seem to have TOTALLY different understandings of what
'within the type' means.
For me, it means 'within the type definition'.
For you, it seems to mean something like 'if used as something of the type'.

If named values of an enumerated type are not known as identifiers on
their own, then you could never use them.

But, you seem to think that NAMES (as in named values) and IDENTIFIERS seem
to be two different things.
Well, how do you differentiate between them, then?
Obviously their syntax is the same.

The answer is: by overloading-resolution
(at least that is what you do in your examples, even though you seem
to think it most natural that two things which look exactly alike
can mean two totally different things without any means of differentiation
given as the place where they are used -> Overloading!).

Of course, this is not a very complex concept and if it is
already in ASN.1, then it probably has to be in TTCN-3, as well.
The standard should only be clarified so that either the
exception for global identifier uniqueness (Names ARE Identifiers)
is made explicit or the actual DIFFERENCE between names and
identifiers (meaning: overloading) has to be described properly.

Anyway, the standard as it is is insufficient in any case.
Either the overloading must be disallowed or explicitely
allowed and means to resolve possible the name-clashes
(like in the a < b example) added to the syntax.

Jacob Wieland

On Wed, 5 Dec 2001, Gyorgy Rethy (ETH) wrote:

> Hi,
>
> I agree. First of all it is too late to debate about overlading. Secondly this
is not an overloading issue. If TTCN-3 allowed the following:
> var integer x := 5;
> var real x := 5E-3;
>
> and than sorting out which identifier "x" to be used for an assignment
> var integer y := x
>
> it would be an overloading problem.
>
> But we are talking about something else, what has to do nothing with
overloading. As if I add:
> var integer z := 5;
> var charstring v := "aa";
> var charstring w := "aa";
>
> we do not start to talk about "value overloading" or "string overloading".

No, but if you do something like this (which as far as I understand
you is allowed):

const integer x := 3;
const integer y := 3;
type enumerated E1 { x, y }
type enumerated E2 { y, x }

then, you have three xs and three ys, each of types integer, E1 and E2.

As you can see, each name is unique in each enumerated type,
but you surely have an overloading problem. (You already would
have it if E2 is left out of the example)

Especially interesting as Thomas Deiss pointed out now are the questions
'x < y' and 'x == y'.
That you need here some means to say which pair of x and y you
mean shows that you have an overloading problem (type-wise and not
value-wise where there is no overloading, only assignment which
is something altogether different, as everyone agrees).

Jacob Wieland

Jacob 'Ugh' Wieland wrote:
>
> On Wed, 5 Dec 2001, Gyorgy Rethy (ETH) wrote:
>
> > Hi,
> >
> > You are simply wrong. I'm not proposing nothing new (except the notation) as
the draft says today that names of values of an enumerated type shall be unique
within the given type only. Named values of an enumerated type are not known as
identifiers on their own. For example:
> >
>
> Firstly, I'm not concerned, what the actual draft says,
> as what it says is in my opinion contradictory.
>
> Also, we seem to have TOTALLY different understandings of what
> 'within the type' means.
> For me, it means 'within the type definition'.
> For you, it seems to mean something like 'if used as something of the type'.

The semantics of ASN.1 can be seen as layers such as in a pearl.
First you look at the governor, the ENUMERATED type in your case, and
you check if the identifier (the "x" in Gyorgy's example) is defined by
this type. If it is not, then you try and find a value assignment called
"x" in the current module. If it fails, you check if "x" is imported.
(There is also the case where the type is parameterized with a dummy
parameter which is called "x".)

> If named values of an enumerated type are not known as identifiers on
> their own, then you could never use them.

In ASN.1, they are only known in the context of the governing type.

> But, you seem to think that NAMES (as in named values) and IDENTIFIERS seem
> to be two different things.

I'm not sure that what you call "named values" is the same as the
"NamedValue" production of ASN.1. If yes, then names and identifiers
are the same (even though the ASN.1 standard does not use the word
"name").

> Well, how do you differentiate between them, then?
> Obviously their syntax is the same.

That is not the point. They are lexical items that look the same in
ASN.1. You can always desambiguate them in their context (as an example,
a valuereference and an identifier are the same lexical item; a
typereference and an information object set reference are also the
same lexical item).

> Of course, this is not a very complex concept and if it is
> already in ASN.1,

It is, definitely.

> then it probably has to be in TTCN-3, as well.

I think that SDL has this concept of identifiers that need to be unique
within a specification (if my memory serves me right, this is due to
the operators that can be applied to such values).
--
Olivier DUBUISSON
France Telecom R&D
_ DTL/MSV - 22307 Lannion Cedex - France
( ) tel: +33 2 96 05 38 50 - fax: +33 2 96 05 39 45
/ \/

---

\_/\ Site ASN.1 : asn1.elibel.tm.fr/

>

---

Original Message

---

> From: ext Thomas Deiß
> Sent: Montag, 3. Dezember 2001 14:01
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Global uniquess of elements in enumerated types
>
>
> Hello all,
>
> The TTCN-3 standard says, that 'named identifiers shall be
> unique within
> the enumerated tpye (but do not have to be globally unique)', section
> 6.3.3.
>
> Therefore, in the example below, the type declarations of A and B are
> correct TTCN-3 code. The situation becomes more complicated, when the
> named identifiers shall be used. E.g. what is the correct semantics of
> the function f below: Is it incorrect TTCN-3 because it is
> not correctly
> typed, is its return value true or is its return value false. Any
> decision for true or false would be an arbitrary one.
>
> As far as I can see the notation A:a, which is possible for templates,
> cannot be used for named identifiers. Is there any chance to determine
> whether a and b in the function f belong to type A or B?
>
> As soon as one of a and b is changed to a constant or
> variable of type A
> or B, resp., then type inference can be used to determine of
> which type
> a and b should be.
>
> module tc {
> type enumerated A
> {
> a, b
> }
>
> type enumerated B
> {
> b, a
> }
>
> function f () return boolean
> {
> return ( a < b );
> }
>
> }
>
> Any opinions out there on how this TTCN-3 code should be
> handled? Thanks
> for your help.
>
> Best regards
>
> Thomas
>
>

---

> | Thomas Deiß, Nokia Research Center Street address: |
> | P.O. Box 101823 Meesmannstraße 103 |
> | D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
> | Phone: +49 234 984 2217 (int. 8272217) |
> | Fax: +49 234 984 3491 (int. 8273491) |
> | E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |
>

---

>

Hello all,

thanks for all your explanations. From the discussion so far I consider
it to be the best solution to follow György's proposal and allow the
notation <Type>:<Identifier> to resolve ambiguity also in expressions.

I will prepare a corresponding change request and submit it.

Best regards

Thomas

Ps: I sent a copy of my original email unintentionally, sorry for any
inconvenience.

>

---

Original Message

---

> From: ext Thomas Deiß
> Sent: Montag, 3. Dezember 2001 14:01
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Global uniquess of elements in enumerated types
>
>
> Hello all,
>
> The TTCN-3 standard says, that 'named identifiers shall be
> unique within
> the enumerated tpye (but do not have to be globally unique)', section
> 6.3.3.
>
> Therefore, in the example below, the type declarations of A and B are
> correct TTCN-3 code. The situation becomes more complicated, when the
> named identifiers shall be used. E.g. what is the correct semantics of
> the function f below: Is it incorrect TTCN-3 because it is
> not correctly
> typed, is its return value true or is its return value false. Any
> decision for true or false would be an arbitrary one.
>
> As far as I can see the notation A:a, which is possible for templates,
> cannot be used for named identifiers. Is there any chance to determine
> whether a and b in the function f belong to type A or B?
>
> As soon as one of a and b is changed to a constant or
> variable of type A
> or B, resp., then type inference can be used to determine of
> which type
> a and b should be.
>
> module tc {
> type enumerated A
> {
> a, b
> }
>
> type enumerated B
> {
> b, a
> }
>
> function f () return boolean
> {
> return ( a < b );
> }
>
> }
>
> Any opinions out there on how this TTCN-3 code should be
> handled? Thanks
> for your help.
>
> Best regards
>
> Thomas
>
>

---

> | Thomas Deiß, Nokia Research Center Street address: |
> | P.O. Box 101823 Meesmannstraße 103 |
> | D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
> | Phone: +49 234 984 2217 (int. 8272217) |
> | Fax: +49 234 984 3491 (int. 8273491) |
> | E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |
>

---

>

Hi,

I'm on a different view. Each identifier/name etc. is seen only depending its scope. No overloading can occur between identifiers with different scopes. In your example x and y clearly relates to the integers, because only they are seen from the given context (none of the enumerations can be seen). As no other x and y variables or constants defined in another module and NOT imported into the current module can be seen.

I do not think this debate has any sence. First, because you are looking things purelly from a compiler point of view. Secondly, because I'm looking things from the notational point of view (where identifiers, references and named values ARE different things). Thirdly, because it will not change anything except that we have to solve the problem identified by Thomas.

Best Regards, György

============================================
dr. György RÉTHY
Ericsson Communications Systems Hungary Lim.
Conformance Center
tel.: +36 1 437-7006; fax: +36 1 437-7767
mobile: +36 30 297-7862
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
web: www.r.eth.ericsson.se/~ethgry
============================================


>

---

Original Message

---

>From: Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Wednesday, December 05, 2001 1:40 PM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: Global uniquess of elements in enumerated types
>
>
>On Wed, 5 Dec 2001, Gyorgy Rethy (ETH) wrote:
>
>> Hi,
>>
>> I agree. First of all it is too late to debate about
>overlading. Secondly this is not an overloading issue. If
>TTCN-3 allowed the following:
>> var integer x := 5;
>> var real x := 5E-3;
>>
>> and than sorting out which identifier "x" to be used for an
>assignment
>> var integer y := x
>>
>> it would be an overloading problem.
>>
>> But we are talking about something else, what has to do
>nothing with overloading. As if I add:
>> var integer z := 5;
>> var charstring v := "aa";
>> var charstring w := "aa";
>>
>> we do not start to talk about "value overloading" or "string
>overloading".
>
>No, but if you do something like this (which as far as I understand
>you is allowed):
>
>const integer x := 3;
>const integer y := 3;
>type enumerated E1 { x, y }
>type enumerated E2 { y, x }
>
>then, you have three xs and three ys, each of types integer, E1 and E2.
>
>As you can see, each name is unique in each enumerated type,
>but you surely have an overloading problem. (You already would
>have it if E2 is left out of the example)
>
>Especially interesting as Thomas Deiss pointed out now are the
>questions
>'x < y' and 'x == y'.
>That you need here some means to say which pair of x and y you
>mean shows that you have an overloading problem (type-wise and not
>value-wise where there is no overloading, only assignment which
>is something altogether different, as everyone agrees).
>
>Jacob Wieland
>

On Wed, 5 Dec 2001, Gyorgy Rethy (ETH) wrote:

> Hi,
>
> I'm on a different view. Each identifier/name etc. is seen only depending its
scope. No overloading can occur between identifiers with different scopes. In
your example x and y clearly relates to the integers, because only they are seen
from the given context (none of the enumerations can be seen). As no other x and
y variables or constants defined in another module and NOT imported into the
current module can be seen.
>

You're simply wrong. All three definitions were in the same scope,
so the names of the enumerated values are known in that scope,
of course.

If the 'names' of the enumerated values could not be seen outside
the enumerated type definition, then how would you ever be able to
use them? And if they are seen, then how can they not be in the same
scope?

> I do not think this debate has any sence.

I agree that this discussion has indeed no sense as you don't
seem to understand the same thing under the term 'scope' as I do
(and everybody I work with does).

> First, because you are looking things purelly from a compiler point of view.

I don't look at the problem from a purely compiler point of view,
but from a user point of view.
The problem I have with overloading is that - if you have it - even
only in a very restricted area, then you have it altogether, as
every 'identifier' now always could have several types which makes
the type inference (because of the ensuing overloading resolution)
much more difficult (not algorithmically, but computationally).

But, if you want to have inherently inefficient compilers, then so
be it, I won't have to use them, I just have to implement one.
But don't come running later on and say that I didn't warn anybody
about this problem :-)

> Thirdly, because it will not change anything except that we have
> to solve the problem identified by Thomas.

Well, a very simple solution was given by me, but as you don't see
the problem (although you need to solve it, which is very strange to me)
you can't seem to accept my solution of it.

If indeed this problem existed already in ASN.1, then I would think
that there would also have to exist a solution to it in that language.
So, maybe that solution should be taken and applied to TTCN-3 -
how about that? Or is it not possible to compare enumerated values
in ASN.1? Maybe then you should not introduce such a feature into
TTCN-3, either.

Greetings, Jacob

Hi,

There is at least one point we agree. To compare values of enumerated types does not make much sense to me either. Anyway integer values assingned to different enumerations does not have any semantical meaning, so it is at least unclear what is the meaning to compare them.

An alternative solution to the original problem would be to forbid it.

Best Regards, György

============================================
dr. György RÉTHY
Ericsson Communications Systems Hungary Lim.
Conformance Center
tel.: +36 1 437-7006; fax: +36 1 437-7767
mobile: +36 30 297-7862
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
web: www.r.eth.ericsson.se/~ethgry
============================================


>

---

Original Message

---

>From: Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Friday, December 07, 2001 12:00 PM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: Global uniquess of elements in enumerated types
>
>
>On Wed, 5 Dec 2001, Gyorgy Rethy (ETH) wrote:
>
>> Hi,
>>
>> I'm on a different view. Each identifier/name etc. is seen
>only depending its scope. No overloading can occur between
>identifiers with different scopes. In your example x and y
>clearly relates to the integers, because only they are seen
>from the given context (none of the enumerations can be seen).
>As no other x and y variables or constants defined in another
>module and NOT imported into the current module can be seen.
>>
>
>You're simply wrong. All three definitions were in the same scope,
>so the names of the enumerated values are known in that scope,
>of course.
>
>If the 'names' of the enumerated values could not be seen outside
>the enumerated type definition, then how would you ever be able to
>use them? And if they are seen, then how can they not be in the same
>scope?
>
>> I do not think this debate has any sence.
>
>I agree that this discussion has indeed no sense as you don't
>seem to understand the same thing under the term 'scope' as I do
>(and everybody I work with does).
>
>> First, because you are looking things purelly from a
>compiler point of view.
>
>I don't look at the problem from a purely compiler point of view,
>but from a user point of view.
>The problem I have with overloading is that - if you have it - even
>only in a very restricted area, then you have it altogether, as
>every 'identifier' now always could have several types which makes
>the type inference (because of the ensuing overloading resolution)
>much more difficult (not algorithmically, but computationally).
>
>But, if you want to have inherently inefficient compilers, then so
>be it, I won't have to use them, I just have to implement one.
>But don't come running later on and say that I didn't warn anybody
>about this problem :-)
>
>> Thirdly, because it will not change anything except that we have
>> to solve the problem identified by Thomas.
>
>Well, a very simple solution was given by me, but as you don't see
>the problem (although you need to solve it, which is very
>strange to me)
>you can't seem to accept my solution of it.
>
>If indeed this problem existed already in ASN.1, then I would think
>that there would also have to exist a solution to it in that language.
>So, maybe that solution should be taken and applied to TTCN-3 -
>how about that? Or is it not possible to compare enumerated values
>in ASN.1? Maybe then you should not introduce such a feature into
>TTCN-3, either.
>
>Greetings, Jacob
>