Hi,


if You_are_bored_reading_long_posts_or_just_these_send_by_me
goto UNIONS IN TTCN-3;


I have never used unions in TTCN and ASN.1, only in C language, in times where in a good fashion was to operate on registers. I am a little bit surprised with unions in TTCN-3 because they have some extra features in my opinion.

Shortly:
1) In TTCN-2 there is no unions. Only word UNION appears as an ASN.1 Reserved Word.
2) Function IS_CHOSEN is defined in TTCN-2 as:

IS_CHOSEN(DataObjectReference) -> BOOLEAN

The operation returns the BOOLEAN value TRUE if and only if the data object reference specifies the variant of the CHOICE type that is actually selected for a given data object. Otherwise the result is FALSE. The operation shall not be applied to data objects or fields of data objects other than those of ASN.1 type CHOICE. The argument of the operation shall have the format as defined in 15.10.2.

EXAMPLE 15: Use of IS_CHOSEN:
if received_PDU is of ASN.1 type
CHOICE {p1 PDU_type1,
p2 PDU_type2,
p3 PDU_type }
then, the operation call
IS_CHOSEN(received_PDU.p2)
returns TRUE if the actual instance of received_PDU carries a PDU of the type PDU_type2.

I am not familar with ASN.1 but I assume the CHOICE variants should be all of unique types. In this case the IS_CHOSEN operation easily /and in unique manner/ identifies the proper variant. Recognition of the variant in the actual instance is done by the unique type stored in instance and then associated reference is known.
IS_CHOSEN operation do everything in reverse order, asks about reference, the associated type is then found and instance is checked for carrying specified type.

3) In TTCN-3 unions are defined as 'unions'. It is similar to C language and may be even misleading for those using C.

Properties of unions in C:
- unions are heterogenous collection of members,

- union may hold different types of information at different times but at any time the union holds only a single type of information,

- components of a union variable share storage,

- the storage is the amount of storage required to store the largest member,

- the storage allocated for the union will be interpreted differently depending on the union member being accessed,

- storage for all members start at the same location /union members overwrite each other/,

- programmer is responsible for asking for the kind of information that was stored there to avoid getting erroneous results.


Example of use for C:

struct FULLREGS {

unsigned int ax;

unsigned int bx;

};



struct FULLREGS {

unsigned char al, ah;

unsigned char bl, bh;

};



union REGS {

struct FULLREGS x;

struct HALFREGS h;

};



This example is specific because:

- all union fields occupy the same memory size;

- every time the REGS union can be read as full or half registers, which means implicit conversion of types occurs by using char-reading or word-reading operation.

---

UNIONS IN TTCN-3

What is different to previous definitions:



1. There is no requirement for union fields to be of different types /as I suppose was in ASN.1 CHOICE construct/. It is only stated in 6.3.5.0 that "Union types are useful to model a structure which can take one of a finite number of known types.".



See example from 15.3:



type union UniD {

integer d1,

integer d2,

};



2. Who keeps information about actually choosed variant and what kind of information is it?



At first it is worth mentioning that TTCN-3 union fields are of not unique types as example 15.3 shows. That means information about type of the chosen field is not enough for the system to identify chosen field in unique manner and 'union' in TTCN-3 should have an extra feature. System should keep reference of the chosen field just for supporting 'ischosen' function.



3. Nothing is known about storage sharing mechanism, i.e. what is size of union structure, what happens when we try to access variant, which is not actually stored in union. Accessing the not chosen variant is in opposition to system data, which should keep reference to chosen field as it is shown in point 2.



4. Please look at Clause 15.3 Relational operators:

"Two values of union types are equal if, and only if, in both values the types of these chosen fields are compatible and the actual values of the chosen fields equal."



What does it mean:

- there is not known if references of chosen fields should be identical,

- there is nothing known about positions of the chosen fields inside unions /if they should be counterparts/,

- types of chosen fields should be compatible,

- actual values of the chosen fields are equal.



Please look at union examples from 15.3:



type union UniD {

integer d1,

integer d2,

};



type union UniE {

integer e1,

integer e2,

};



type union UniF {

integer f1,

integer f2,

boolean f3,

};



const UniD conUniD1 := { d1:= 0 };

const UniE conUniE1 := { e1:= 0 };

const UniE conUniE2; := { e2:= 0 };

const UniF conUniF1; := { f1:= 0 };



// Then



conUniD1 == conUniE1;

// returns true

conUniD1 == conUniE2;

// returns false, as the chosen field e2 is not the counterpart of the field d1 of UniD1

conUniD1 == conUniF1;

// returns false, as the effective value structures of UniD1 and UniF are not compatible





What I think here is that all comparisons should return value 'true'.

The second operation should produce TRUE because types and values of chosen fields are equal. Union was initialized in both cases with integer type of 0 value. The counterpart of fields is not applicable to unions here. The third example says about 'effective value structures' incompatibility but I do not think it is true. For 'effective value' only chosen field should be taken and actual values.



5. Clause 6.0 General

"The special data type anytype is defined as the union of all known types within a module."



Example from 6.4 anytype:



var anytype MyVarOne, MyVarTwo;

var integer MyVarThree;



MyVarOne.integer := 34;

MyVarTwo := {integer := MyVarOne + 1};



MyVarThree := MyVarOne × 12;




I have bad feeling that 'anytype' union may be accessed in two different ways:

a) using field identifier 'integer', which is required for writing to field,

b) using or not not using identifier as in case of read access to MyVarOne:

'MyVarThree := MyVarOne × 12;'

MyVarOne is accessed without field identifier.

Is it an error or it comes from knowledge that only valid value stored in antype is 'integer' type and after the write operation to chosen field this field is chosen until next write operation???

This suggest that we do not need field notation for reading from union, only for writing to field.



6. The power of 'union' in TTCN-3 is doubtful. It has no properties of ASN.1 CHOICE /unique types/, neither C 'union' properties, it is doubtful if test suite writer can read other fields without dynamic error, can convert values implicitly as in example with registers /C language/ and also system should keep not only chosen type but also/rather chosen reference and update it after write operations to union fields.



Last question may be anticipated.

What is a benefit ... ?





BR,

Mariusz Kupiec





BTW: There are also other notes to union description but maybe I do not know the language well.




- the sentence from 6.3.5.0 "Only one of the specified fields will ever be present in an actual union value" is hard to understand for me, maybe 'all of specified fields may be used to reference union value but only one field at 'any/a given' time', why to construct structured variable, which always uses one field only?


- next sentence is not precise "Union types are useful to model a structure which can take one of a finite number of known types", since e.g. we want in union different fields of common type to store temperature as Fahrenheight of Celsius degrees, that is not only 'types' differ union fields but also different representations for the same types?

/collection of overlapped representations of objects of different types/

- example in 6.3.5.0 and the comments should be extended since 'Note, this notation makes the given field to be the chosen one' suggests as the choice was done forever, not only for the current reading operation.

In einer eMail vom 1/18/03 1:06:33 AM W. Europe Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

Hi again,

Working late are we? :-)

Just a short clarification.


> Shortly:
> 1) In TTCN-2 there is no unions. Only word UNION appears as an ASN.1
> Reserved Word.
>
Well, yes. TTCN-2 offers a limited version of the union. That is the PDU
type, which
which is a union of all PDUs defined in a given test suite. ASN.1 also
offers a union
type which is referred to as CHOICE.


Cheers,

Claude.



Claude Desroches e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Technical Architect This email address is being protected from spambots. You need JavaScript enabled to view it.
Strategic Test Solutions Ltd.
City Gate East.
Toll House Hill,
Nottingham.
NG1 5FS.

Tel: +44 115 958 6600
Fax: +44 115 958 6633
Mob: +44 796 648 2165

Hi :-)

> Working late are we? :-)

Yes, may favourite job, spamming on the lists ;-)
Thanks for the clarification and for reading the whole post /I hope ;-)/.

What about other notes?

Cheers,
Mariusz


>> Shortly:
>> 1) In TTCN-2 there is no unions. Only word UNION appears as an ASN.1 Reserved Word.

> Well, yes. TTCN-2 offers a limited version of the union. That is the PDU type, which
> which is a union of all PDUs defined in a given test suite. ASN.1 also offers a union
> type which is referred to as CHOICE.
>
>
> Cheers,
>
> Claude.
>
>
>
> Claude Desroches e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Technical Architect This email address is being protected from spambots. You need JavaScript enabled to view it.
> Strategic Test Solutions Ltd.
> City Gate East.
> Toll House Hill,
> Nottingham.
> NG1 5FS.

> Tel: +44 115 958 6600
> Fax: +44 115 958 6633
> Mob: +44 796 648 2165

Hello Marius,

the union construct in ttcn-3 is used to be able to create
free data types (i.e. values of a term algebra).

The closest associate in well established high-level-languages
is probably the class construct of object-oriented languages
where every object that is a member of an abstract class can
be a member of different concrete subclasses, so the type of
the class (a tag, if you will) must be stored together with the
actual value of the object to differentiate between different
objects of the same class.

Thus, you can have abstract methods which work on all objects
of the abstract class, and, by being able to ask for the class
(in ttcn-3 to ask for the present field), work differently on
different subclasses.

Other prominent examples for such free data types are functional
languages (ML, Haskell, OPAL) where you can often give direct
algebraic declarations of such types.

Another example is XML where you can define choice-elements.

A nice example for the use of free data types is abstract syntax
trees where different nodes can of course have the same type of
content, but the node-kind information differentiates between
different kinds of nodes.

type union absy {
int number; // a denotated number
int identifier; // an index in the symbol table
definition definition;
while_loop while_loop;
...
}

type record definition {
absy lhs;
absy rhs;
}

type record while_loop {
absy condition;
absy body;
}

If you don't have such a construct, it is very hard to implement
such things without going to a very low level of abstraction,
making code harder to write, prone to errors, unreadable and thus
unmaintainable.

> UNIONS IN TTCN-3
>
> What is different to previous definitions:
>
>
>
> 1. There is no requirement for union fields to be of different types /as I suppose was in ASN.1 CHOICE construct/. It is only stated in 6.3.5.0 that "Union types are useful to model a structure which can take one of a finite number of known types.".

... and there shouldn't be, as this only complicates matters unduly.

> See example from 15.3:
>
>
>
> type union UniD {
>
> integer d1,
>
> integer d2,
>
> };
>
>
>
> 2. Who keeps information about actually choosed variant and what kind of information is it?

This information must be stored extra in additional tag-field
(a compiler internal enumeration type, if you will).
If you want to keep the information about the actual NAME
of the field, you can store this in a table (per type, not per
value) which associates tag-number with the name.

> At first it is worth mentioning that TTCN-3 union fields are of not unique types as example 15.3 shows. That means information about type of the chosen field is not enough for the system to identify chosen field in unique manner and 'union' in TTCN-3 should have an extra feature. System should keep reference of the chosen field just for supporting 'ischosen' function.

... and its very important functionality ...

> 3. Nothing is known about storage sharing mechanism, i.e. what is size of union structure, what happens when we try to access variant, which is not actually stored in union. Accessing the not chosen variant is in opposition to system data, which should keep reference to chosen field as it is shown in point 2.

This is probably left open to be decided by the compiler - a tool issue.

> 4. Please look at Clause 15.3 Relational operators:
>
> "Two values of union types are equal if, and only if, in both values the types of these chosen fields are compatible and the actual values of the chosen fields equal."
>
>
>
> What does it mean:
>
> - there is not known if references of chosen fields should be identical,
>
> - there is nothing known about positions of the chosen fields inside unions /if they should be counterparts/,
>
> - types of chosen fields should be compatible,
>
> - actual values of the chosen fields are equal.

Here, you raise a very good point. In my opinion, the differentiation
should be by NAME and not by POSITION, as position in union types
is hardly sigificant (at least it isn't in any other language which
supports such constructs).

> Please look at union examples from 15.3:
>
>
>
> type union UniD {
>
> integer d1,
>
> integer d2,
>
> };
>
>
>
> type union UniE {
>
> integer e1,
>
> integer e2,
>
> };
>
>
>
> type union UniF {
>
> integer f1,
>
> integer f2,
>
> boolean f3,
>
> };
>
>
>
> const UniD conUniD1 := { d1:= 0 };
>
> const UniE conUniE1 := { e1:= 0 };
>
> const UniE conUniE2; := { e2:= 0 };
>
> const UniF conUniF1; := { f1:= 0 };
>
>
>
> // Then
>
>
>
> conUniD1 == conUniE1;
>
> // returns true
>
> conUniD1 == conUniE2;
>
> // returns false, as the chosen field e2 is not the counterpart of the field d1 of UniD1
>
> conUniD1 == conUniF1;
>
> // returns false, as the effective value structures of UniD1 and UniF are not compatible


> What I think here is that all comparisons should return value 'true'.

In my opinion, none of the above should return true.
If x1 = { f := v1 } and x2 = { f := v2 }, then
x1 == x2 should be true, if v1 == v2.

> The second operation should produce TRUE because types and values of chosen fields are equal. Union was initialized in both cases with integer type of 0 value. The counterpart of fields is not applicable to unions here. The third example says about 'effective value structures' incompatibility but I do not think it is true. For 'effective value' only chosen field should be taken and actual values.
>
>
>
> 5. Clause 6.0 General
>
> "The special data type anytype is defined as the union of all known types within a module."
>
>
>
> Example from 6.4 anytype:
>
>
>
> var anytype MyVarOne, MyVarTwo;
>
> var integer MyVarThree;
>
>
>
> MyVarOne.integer := 34;
>
> MyVarTwo := {integer := MyVarOne + 1};
>
>
>
> MyVarThree := MyVarOne × 12;
>
>
>
>
> I have bad feeling that 'anytype' union may be accessed in two different ways:
>
> a) using field identifier 'integer', which is required for writing to field,
>
> b) using or not not using identifier as in case of read access to MyVarOne:
>
> 'MyVarThree := MyVarOne × 12;'
>
> MyVarOne is accessed without field identifier.
>
> Is it an error or it comes from knowledge that only valid value stored in antype is 'integer' type and after the write operation to chosen field this field is chosen until next write operation???
>
> This suggest that we do not need field notation for reading from union, only for writing to field.

This I would call very bad coding style (as it is akin to overloading
in a language where something like that doesnt exist otherwise).

It should not be allowed.

> Last question may be anticipated.
>
> What is a benefit ... ?

... see above ... you can model data structures with variants

> - the sentence from 6.3.5.0 "Only one of the specified fields will ever be present in an actual union value" is hard to understand for me, maybe 'all of specified fields may be used to reference union value but only one field at 'any/a given' time', why to construct structured variable, which always uses one field only?

It doesn't need to always use the same field, just only one at a time.

> - next sentence is not precise "Union types are useful to model a structure which can take one of a finite number of known types", since e.g. we want in union different fields of common type to store temperature as Fahrenheight of Celsius degrees, that is not only 'types' differ union fields but also different representations for the same types?

right you are. This is a useful property of unions, as well.

Jacob