TOPIC:

Hi,

I believe the usage of the union type in the example (and description
in the standard) is correct.

In general, wrong usages of the union type like e.g.,

> age.string := "thirtyfour";
> ageInMoths := age * 12;

can not be detected statically. If I add qualifiers to 'age' and modify
the
example a little bit to

if (MyBoolPar) {
age.number := 34;
}
else {
age.string := "thirtyfour";
}
oneYearOlder := { number := age.number + 1};
ageInMoths := age.number * 12;

you need type checking at run-time. Thus, qualification does not help
to detect the erroneous usage of the union type statically. Therefore,
qualification should not be required for variables of the union type.

In some cases it may even be problematic to add qualifiers:

if (MyBoolPar) {
age.number := 34;
}
else {
age.string := "thirtyfour";
}

MyFunction(age); // assume that MyFunction can handle age with integer
and string values



Regards
Jens






Stephen TOBIES schrieb:
>
> Hi,
>
> in the latest (2.2.0) version of the standard, we have found the following
code example for the union type:
>
> type union MyUnionType {
> integer number,
> charstring string
> };
>
> var MyUnionType age, oneYearOlder;
> var integer ageInMonths;
>
> age.number := 34;
> oneYearOlder := { number := age + 1};
> ageInMoths := age * 12;
>
> My question is whether this constitutes well-types TTCN-3. What I find
offending in this code is the missing qualification of the age variable.
>
> Should it be allowed for a union variable to be used in operations that
require one of its facet types without the qualifier that explicitly selects
this facet? This would weaken the type system of TTCN-3, making it (in general)
impossible to catch type errors like the following at compile time:
>
> age.string := "thirtyfour";
> ageInMoths := age * 12;
>
> This is intentional? If so, some clarifying comments in the standard would we
appropriate - I find this highly 'non-standard'.
>
> Of course, the same considerations apply to the anytype, which is defined to
be an implicit union...
>
> Regards
>
> Stephan Tobies

--

======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================

Since there have been no answers so far, let me elaborate a little bit on the effects of allowing unions to appear where one of their member types is allowed:

If we allow this without any restrictions, then it should also be allowed for the '.' operator, so that the following would be legal TTCN-3:

type record R {
integer field;
}

type union U {
integer alt1,
R alt2
}

var U x := { alt2 := {field := 1} };
x.field := 5; // this is legal because x contains a record of type R which has a field 'field'

Highly un-intuitive.

One can, of course, come up with even stranger examples:

// R as above

type union U1 {
integer alt1;
R field; // same as in R
}

var U1 x1 := { field := { field := 1 } };
x.field := 2; // legal
x.field := { field := 5 }; // also legal...

Conclusion: using this semantics for the '.'-operator is certainly not feasible.

What about function calls? Same problem:

function f1(inout integer x) ...
function f2(inout R x) ...

var U x2 := ... ;

f1(x2); // legal
f2(x2); // also legal...

Also out of the questions, I guess.

What about nested unions?

type union U2 {
integer alt1;
float alt2;
}

type union U3 {
U2 alt1;
integer alt2;
}

var U3 x3 := { alt1 := { alt1 := 5 } };
var integer y := x3; // legal, because x3 contains a union that contains an integer...

What do we gain by allowing a union to appear in place of one of its members? Well, if there would be polymorphic functions/operators in TTCN-3, we would gain some expressivity:

type union U4 {
integer alt1;
float alt2;
}

var U4 x4;

if (...) {
x4.alt1 := 4;
} else {
x4.alt2 := 5.7;
}

if (x4 > 5) { ... }

But even this small example won't work because TTCN-3 does not allow to compare ints with floats so in case the alt2 is selected for x4, the comparison should yield a run time type error. Actually, I don't think there are any really polymorphic operations in TTCN-3.


All these examples seem to suggest that it should not be allowed to used a union in a place where one of its member types is expected. It might be a convenient shorthand notation in some cases, but it does not extend the expressivity of TTCN-3 and is highly confusing in many cases.

Other opinions?

Regards

Stephan Tobies

On Tue, 14 May 2002, Jens Grabowski wrote:

> Hi,
>
> I believe the usage of the union type in the example (and description
> in the standard) is correct.
>
> In general, wrong usages of the union type like e.g.,
>
> > age.string := "thirtyfour";
> > ageInMoths := age * 12;
>
> can not be detected statically. If I add qualifiers to 'age' and modify

Of course, it can be detected statically, if a quantified usage
of a union in an assignment gets the correct type.

The only thing that cannot be statically checked is whether a
union really contains something of the specified variant upone
READING (not assigning) the variant of the union value.

> the
> example a little bit to
>
> if (MyBoolPar) {
> age.number := 34;
> }
> else {
> age.string := "thirtyfour";
> }
> oneYearOlder := { number := age.number + 1};
> ageInMoths := age.number * 12;
>
> you need type checking at run-time. Thus, qualification does not help
> to detect the erroneous usage of the union type statically. Therefore,
> qualification should not be required for variables of the union type.
>
> In some cases it may even be problematic to add qualifiers:
>
> if (MyBoolPar) {
> age.number := 34;
> }
> else {
> age.string := "thirtyfour";
> }
>
> MyFunction(age); // assume that MyFunction can handle age with integer
> and string values

How is that possible in TTCN3, where every function can only have
one input type (either the union type itself or one of the
types variants).

Even WORSE, if you allow what you are proposing, it is not
possible to differentiate between different union variants
that contain the same type anymore:

type union temperature {
float celsius,
float kelvin,
float fahrenheit
}

Now, if I do something like

temperature t := 3.0, I wouldn't know, what variant is set afterwards
(so the ischosen(t.celsius) operation couldn't work properly).

Likewise, t.celsius, t.kelvin and t.fahrenheit would either all be
defined (which would counteract the whole meaning of the union)
or they would all have to be undefined, which surely cannot be
wanted when I wrote t.celsius := 3.0.

My point, in sort:

A union should always have EXACTLY ONE chosen variant, which is
determinded upon assigment of the union value. Only the selection
of EXACTLY that variant in the union value should yield the
assigned value, selection of all other variants, be they of the
same type or not, should yield a runtime error.
The ischosen-operation should have the same behavior
(only with true/false instead of value/error as possible results).

So, your approach would only work for unions with different
(i.e. type-incompatible), types for every two variants in the
union.

Jacob Wieland

Hi Jakob,

see below...

>

---

Original Message

---

> From: ext Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Dienstag, 14. Mai 2002 15:19
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Union variables w/o qualifiers
>
>
> On Tue, 14 May 2002, Jens Grabowski wrote:
>
> > Hi,
> >
> > I believe the usage of the union type in the example (and
> description
> > in the standard) is correct.
> >
> > In general, wrong usages of the union type like e.g.,
> >
> > > age.string := "thirtyfour";
> > > ageInMoths := age * 12;
> >
> > can not be detected statically. If I add qualifiers to
> 'age' and modify
>
> Of course, it can be detected statically, if a quantified usage
> of a union in an assignment gets the correct type.
>
> The only thing that cannot be statically checked is whether a
> union really contains something of the specified variant upone
> READING (not assigning) the variant of the union value.
>
> > the
> > example a little bit to
> >
> > if (MyBoolPar) {
> > age.number := 34;
> > }
> > else {
> > age.string := "thirtyfour";
> > }
> > oneYearOlder := { number := age.number + 1};
> > ageInMoths := age.number * 12;
> >
> > you need type checking at run-time. Thus, qualification
> does not help
> > to detect the erroneous usage of the union type statically.
> Therefore,
> > qualification should not be required for variables of the
> union type.
> >
> > In some cases it may even be problematic to add qualifiers:
> >
> > if (MyBoolPar) {
> > age.number := 34;
> > }
> > else {
> > age.string := "thirtyfour";
> > }
> >
> > MyFunction(age); // assume that MyFunction can handle age
> with integer
> > and string values
>
> How is that possible in TTCN3, where every function can only have
> one input type (either the union type itself or one of the
> types variants).
>
> Even WORSE, if you allow what you are proposing, it is not
> possible to differentiate between different union variants
> that contain the same type anymore:
>
> type union temperature {
> float celsius,
> float kelvin,
> float fahrenheit
> }
>
> Now, if I do something like
>
> temperature t := 3.0, I wouldn't know, what variant is set afterwards
> (so the ischosen(t.celsius) operation couldn't work properly).
>
> Likewise, t.celsius, t.kelvin and t.fahrenheit would either all be
> defined (which would counteract the whole meaning of the union)
> or they would all have to be undefined, which surely cannot be
> wanted when I wrote t.celsius := 3.0.

Of course, one could require to qualify the union whenever it is used as an lvalue and allow the unqualified notation if it is used as an rvalue, but this would make matters even more complicated.

>
> My point, in sort:
>
> A union should always have EXACTLY ONE chosen variant, which is
> determinded upon assigment of the union value. Only the selection
> of EXACTLY that variant in the union value should yield the
> assigned value, selection of all other variants, be they of the
> same type or not, should yield a runtime error.
> The ischosen-operation should have the same behavior
> (only with true/false instead of value/error as possible results).

I second that!

Regards

Stephan Tobies

Hi Jacob,

I do not disagree with your statements.

It looks like a misinterpretation of my example:

> >
> > if (MyBoolPar) {
> > age.number := 34;
> > }
> > else {
> > age.string := "thirtyfour";
> > }
> >
> > MyFunction(age); // assume that MyFunction can handle age with integer
> > // and string values
>


In this example MyFunction(age) was meant to be a function call and not
a
function definition and of course. The 'and string values' might also be
a
misinterpreted. When the function is called, 'age' has only one value of
either
integer or charstring (depending on the value of MyBoolPar) and not
both.

The corresponding function definition might be something like:

function MyFunction (inout MyUnionType MyPar1) { ... }

(This is according your statement:
> ...in TTCN3, where every function can only have
> one input type (either the union type itself or one of the
> types variants).
)

Next time I will try to write more complete examples.

Regards
Jens


Jacob 'Ugh' Wieland schrieb:
>
> On Tue, 14 May 2002, Jens Grabowski wrote:
>
> > Hi,
> >
> > I believe the usage of the union type in the example (and description
> > in the standard) is correct.
> >
> > In general, wrong usages of the union type like e.g.,
> >
> > > age.string := "thirtyfour";
> > > ageInMoths := age * 12;
> >
> > can not be detected statically. If I add qualifiers to 'age' and modify
>
> Of course, it can be detected statically, if a quantified usage
> of a union in an assignment gets the correct type.
>
> The only thing that cannot be statically checked is whether a
> union really contains something of the specified variant upone
> READING (not assigning) the variant of the union value.
>
> > the
> > example a little bit to
> >
> > if (MyBoolPar) {
> > age.number := 34;
> > }
> > else {
> > age.string := "thirtyfour";
> > }
> > oneYearOlder := { number := age.number + 1};
> > ageInMoths := age.number * 12;
> >
> > you need type checking at run-time. Thus, qualification does not help
> > to detect the erroneous usage of the union type statically. Therefore,
> > qualification should not be required for variables of the union type.
> >
> > In some cases it may even be problematic to add qualifiers:
> >
> > if (MyBoolPar) {
> > age.number := 34;
> > }
> > else {
> > age.string := "thirtyfour";
> > }
> >
> > MyFunction(age); // assume that MyFunction can handle age with integer
> > and string values
>
> How is that possible in TTCN3, where every function can only have
> one input type (either the union type itself or one of the
> types variants).
>
> Even WORSE, if you allow what you are proposing, it is not
> possible to differentiate between different union variants
> that contain the same type anymore:
>
> type union temperature {
> float celsius,
> float kelvin,
> float fahrenheit
> }
>
> Now, if I do something like
>
> temperature t := 3.0, I wouldn't know, what variant is set afterwards
> (so the ischosen(t.celsius) operation couldn't work properly).
>
> Likewise, t.celsius, t.kelvin and t.fahrenheit would either all be
> defined (which would counteract the whole meaning of the union)
> or they would all have to be undefined, which surely cannot be
> wanted when I wrote t.celsius := 3.0.
>
> My point, in sort:
>
> A union should always have EXACTLY ONE chosen variant, which is
> determinded upon assigment of the union value. Only the selection
> of EXACTLY that variant in the union value should yield the
> assigned value, selection of all other variants, be they of the
> same type or not, should yield a runtime error.
> The ischosen-operation should have the same behavior
> (only with true/false instead of value/error as possible results).
>
> So, your approach would only work for unions with different
> (i.e. type-incompatible), types for every two variants in the
> union.
>
> Jacob Wieland

--

======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================

On Tue, 14 May 2002, Jens Grabowski wrote:

> Hi Jacob,
>
> I do not disagree with your statements.
>
> It looks like a misinterpretation of my example:
>
> > >
> > > if (MyBoolPar) {
> > > age.number := 34;
> > > }
> > > else {
> > > age.string := "thirtyfour";
> > > }
> > >
> > > MyFunction(age); // assume that MyFunction can handle age with integer
> > > // and string values
> >
>
>
> In this example MyFunction(age) was meant to be a function call and not
> a
> function definition and of course. The 'and string values' might also be
> a
> misinterpreted. When the function is called, 'age' has only one value of
> either
> integer or charstring (depending on the value of MyBoolPar) and not
> both.
>
> The corresponding function definition might be something like:
>
> function MyFunction (inout MyUnionType MyPar1) { ... }
>
> (This is according your statement:
> > ...in TTCN3, where every function can only have
> > one input type (either the union type itself or one of the
> > types variants).
> )
>
> Next time I will try to write more complete examples.

Now I understand your example, but I don't understand its relevance
as to the problem in question. How do you propose to solve the
problems posed by the possibility to use unions unquantified
(which I think would be very unwise to allow it, as my statements show ...)

Either you _have_ tagged unions, or you don't:
you can't have them tagged and then use them like
untagged ones.

Jacob

Hi,

I feel the discussion to go in a wrong direction. There is a
misunderstanding regarding the example:
:
age.number := 34;
oneYearOlder := { number := age + 1};
ageInMoths := age * 12;
:

It does not say, that the value reference "age.number" would be incorrect at
the place of "age"; both are correct. And can not be deducted from it that
either
"
type record R {
integer field;
}

type union U {
integer alt1,
R alt2
}

var U x := { alt2 := {field := 1} };
x.field := 5;
"

or

"
type union temperature {
float celsius,
float kelvin,
float fahrenheit
}

temperature t := 3.0
"
is correct. On the contrary, I think, that both these examples are
incorrect.

The example in the standard shows a value reference and implicitly says that
the referenced variable of union type has the same type as the active field.

Stephen's and Jacob's examples show value notations and not value
references. At value notation, naturaly, the active field shall explicitly
be selected (and a previously activ field can also be changed), so to make
these examples correct we have to add:
" x.alt2.field := 5;" // by the way, this example is not relevant
to $6.3.5.0
// but to $6.3.5.1 "Referencing
fields of a union type"
" temperature t := {celsius:=3.0}"


Further on, in cases, when the actual type of "age" (without .number) can
not be checked at compile time, the error like

age.string := "thirtyfour";
ageInMoths := age.number * 12;

can not be detected either. So far we have not gained too much with the
extra field in the value reference (but again, it is allowed!).

It was also told, that TTCN-3 does not have any polymorphic function. True
for the predefined operations. But what about

function Myf (anytype par_mypar1, anytype par_mypar2 ) return boolean
{
var boolean myresult;
myresult := ( par_mypar1 == par_mypar2 );
return myresult
} // even if probably not true-polymorphic

I'm not saying it is very useful, but allowed. And similar examples also can
be made when the formal parameter is a union type, therefore the actual
parameter should not explicitly (by ".number") pre-determine the active
field.

Also, do not forget about external functions with e.g. anytype formal
parameter(s).

The example:
" function f1(inout integer x) ...
function f2(inout R x) ...

var U x2 := { alt2 := 1) ;

f1(x2); // legal
f2(x2); // also legal...
"
gives a reason to think. But it also may be a good example for the opposit,
if we modify it:

" function f1(inout float x) return integer {...}

var temperature t1 := { kelvin := 0 };

f1(t1);
"

to make f1(t1.fahrenheit) the only mandatory notation would make this
function usable for one of the choices and should return error for the other
two.

BR, Gyorgy

Let me re-emphasize my resentments against this.

What do we gain: notational shortness (which is nor real argument for this approach) and the possibility to have, in some cases, truly polymorphic functions.

Let me discuss this last issue a bit:

- the example for a function that deals both with a string and an integer - for this function to do something sensible, it would have to start with an ischosen clause to determine the actually set alternative. But once we have determined the chosen alternative, we can also explicitly access is using the qualifier notation, so we do not gain anything in that case.

The sencond example MyF is slightly different, bout also in this case I don't think that we gain a lot: equality is also defined on unions and the anytype, so the function would work equally well without the shorthand notation.

On the other hand, there are examples with highly un-intuitive behaviour, if we follow this approach:

Example 1:

type union U1 {
integer alt1,
float alt2
}

type union U2 {
integer alt3,
float alt4
}

var U1 x1 := { alt1 := 1 };
var U2 x2 := { alt3 := 1 };

In this case (x1 == x2) would hold - is this desired? I think not.

Example 2 (recursive union):

type union U3 {
integer alt1,
U3 alt2
}

var x := { alt2 := { alt2 := { alt1 := 1 }}};

function f(U3 z) {
if (z.alt2.alt2.alt1 == 1) ...
}

When calling f(x), will this be successful or will it be a run-time error because the first layer has been stripped away implicitly in the function call?

Similarly:

// x as abive

var x1 := { alt2 := {alt1 := 1}};

Does now x == x1 hold?

I think Jacob is very right in saying that if we want to have tagged (=disjoint) unions then we should allow access to the selected alternative using the qualifier, both for lvalues (where this is the only possibility anyway) and for rvalues (where the other approach would be at least confusing).

Regards

Stephan Tobies


>

---

Original Message

---

> From: ext György Réthy [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Dienstag, 14. Mai 2002 18:17
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Union variables w/o qualifiers
>
>
> Hi,
>
> I feel the discussion to go in a wrong direction. There is a
> misunderstanding regarding the example:
> :
> age.number := 34;
> oneYearOlder := { number := age + 1};
> ageInMoths := age * 12;
> :
>
> It does not say, that the value reference "age.number" would
> be incorrect at
> the place of "age"; both are correct. And can not be deducted
> from it that
> either
> "
> type record R {
> integer field;
> }
>
> type union U {
> integer alt1,
> R alt2
> }
>
> var U x := { alt2 := {field := 1} };
> x.field := 5;
> "
>
> or
>
> "
> type union temperature {
> float celsius,
> float kelvin,
> float fahrenheit
> }
>
> temperature t := 3.0
> "
> is correct. On the contrary, I think, that both these examples are
> incorrect.
>
> The example in the standard shows a value reference and
> implicitly says that
> the referenced variable of union type has the same type as
> the active field.
>
> Stephen's and Jacob's examples show value notations and not value
> references. At value notation, naturaly, the active field
> shall explicitly
> be selected (and a previously activ field can also be
> changed), so to make
> these examples correct we have to add:
> " x.alt2.field := 5;" // by the way, this example
> is not relevant
> to $6.3.5.0
> // but to $6.3.5.1
> "Referencing
> fields of a union type"
> " temperature t := {celsius:=3.0}"
>
>
> Further on, in cases, when the actual type of "age" (without
> .number) can
> not be checked at compile time, the error like
>
> age.string := "thirtyfour";
> ageInMoths := age.number * 12;
>
> can not be detected either. So far we have not gained too
> much with the
> extra field in the value reference (but again, it is allowed!).
>
> It was also told, that TTCN-3 does not have any polymorphic
> function. True
> for the predefined operations. But what about
>
> function Myf (anytype par_mypar1, anytype par_mypar2 ) return boolean
> {
> var boolean myresult;
> myresult := ( par_mypar1 == par_mypar2 );
> return myresult
> } // even if probably not true-polymorphic
>
> I'm not saying it is very useful, but allowed. And similar
> examples also can
> be made when the formal parameter is a union type, therefore
> the actual
> parameter should not explicitly (by ".number") pre-determine
> the active
> field.
>
> Also, do not forget about external functions with e.g. anytype formal
> parameter(s).
>
> The example:
> " function f1(inout integer x) ...
> function f2(inout R x) ...
>
> var U x2 := { alt2 := 1) ;
>
> f1(x2); // legal
> f2(x2); // also legal...
> "
> gives a reason to think. But it also may be a good example
> for the opposit,
> if we modify it:
>
> " function f1(inout float x) return integer {...}
>
> var temperature t1 := { kelvin := 0 };
>
> f1(t1);
> "
>
> to make f1(t1.fahrenheit) the only mandatory notation would make this
> function usable for one of the choices and should return
> error for the other
> two.
>
> BR, Gyorgy
>

Hi,

I think I left implicit in my mail from yesterday (not intentionally, it was
late). Why the value notation and the value reference are different? Because
we have type compatibility. Though we are referencing a variable of a union
type, we are allowed to assign the value of the (currently) active field to
an integer. And I think Jens is rigth saying (confirmed by Jacob), that in
many cases the correctness of the active field can be checked run-time only.

If you look at the very first example of $6.7.2.3, you will see a very
similar case to our "oneYearOlder := { number := age + 1}".

In fact, I think both cases (age & age.number) are correct at the given
place but the example itself seems to be premature. The "age.number" version
is more related to $6.3.5.1 than to 6.3.5.0, the age version is more related
to $6.7.2.3.

BR, Gyorgy


>

---

Original Message

---

> From: György Réthy
> Sent: 14 May 2002 18:17
> To: 'Active_TTCN3 : MTS STF133 TTCN Version 3 - Active Members Only'
> Subject: RE: Union variables w/o qualifiers
>
>
> Hi,
>
> I feel the discussion to go in a wrong direction. There is a
> misunderstanding regarding the example:
> :
> age.number := 34;
> oneYearOlder := { number := age + 1};
> ageInMoths := age * 12;
> :
>
> It does not say, that the value reference "age.number" would
> be incorrect at the place of "age"; both are correct. And can
> not be deducted from it that either
> "
> type record R {
> integer field;
> }
>
> type union U {
> integer alt1,
> R alt2
> }
>
> var U x := { alt2 := {field := 1} };
> x.field := 5;
> "
>
> or
>
> "
> type union temperature {
> float celsius,
> float kelvin,
> float fahrenheit
> }
>
> temperature t := 3.0
> "
> is correct. On the contrary, I think, that both these
> examples are incorrect.
>
> The example in the standard shows a value reference and
> implicitly says that the referenced variable of union type
> has the same type as the active field.
>
> Stephen's and Jacob's examples show value notations and not
> value references. At value notation, naturaly, the active
> field shall explicitly be selected (and a previously activ
> field can also be changed), so to make these examples correct
> we have to add:
> " x.alt2.field := 5;" // by the way, this example is
> not relevant to $6.3.5.0
> // but to $6.3.5.1
> "Referencing fields of a union type"
> " temperature t := {celsius:=3.0}"
>
>
> Further on, in cases, when the actual type of "age" (without
> .number) can not be checked at compile time, the error like
>
> age.string := "thirtyfour";
> ageInMoths := age.number * 12;
>
> can not be detected either. So far we have not gained too
> much with the extra field in the value reference (but again,
> it is allowed!).
>
> It was also told, that TTCN-3 does not have any polymorphic
> function. True for the predefined operations. But what about
>
> function Myf (anytype par_mypar1, anytype par_mypar2 ) return boolean
> {
> var boolean myresult;
> myresult := ( par_mypar1 == par_mypar2 );
> return myresult
> } // even if probably not true-polymorphic
>
> I'm not saying it is very useful, but allowed. And similar
> examples also can be made when the formal parameter is a
> union type, therefore the actual parameter should not
> explicitly (by ".number") pre-determine the active field.
>
> Also, do not forget about external functions with e.g.
> anytype formal parameter(s).
>
> The example:
> " function f1(inout integer x) ...
> function f2(inout R x) ...
>
> var U x2 := { alt2 := 1) ;
>
> f1(x2); // legal
> f2(x2); // also legal...
> "
> gives a reason to think. But it also may be a good example
> for the opposit, if we modify it:
>
> " function f1(inout float x) return integer {...}
>
> var temperature t1 := { kelvin := 0 };
>
> f1(t1);
> "
>
> to make f1(t1.fahrenheit) the only mandatory notation would
> make this function usable for one of the choices and should
> return error for the other two.
>
> BR, Gyorgy
>
>
>
>
>

On Tue, 14 May 2002, György Réthy wrote:

> Hi,
>
> I feel the discussion to go in a wrong direction. There is a
> misunderstanding regarding the example:
> :
> age.number := 34;
> oneYearOlder := { number := age + 1};
> ageInMoths := age * 12;

Here, age is referenced and used as a number, but it isn't a number,
but a union where ONE of the variants is a number. This variant
must be selected to get the number from the union value.

So, the only correct way of writing the above should be:

age.number := 34
oneYearOlder := { number := age.number + 1 };
ageInMonths := age.number * 12;

> :
>
> It does not say, that the value reference "age.number" would be incorrect at
> the place of "age"; both are correct. And can not be deducted from it that
> either
> "

Nobody said that. We (Tobias and I) mean that only 'age' is incorrect.
age.number of course is (statically in every case and dynamically in
case it was set to this variant) correct.

> type record R {
> integer field;
> }
>
> type union U {
> integer alt1,
> R alt2
> }
>
> var U x := { alt2 := {field := 1} };
> x.field := 5;
> "
>
> or
>
> "
> type union temperature {
> float celsius,
> float kelvin,
> float fahrenheit
> }
>
> temperature t := 3.0
> "
> is correct. On the contrary, I think, that both these examples are
> incorrect.

My example was to show how stupid it would be to write something like
that, so _OF COURSE_ it is incorrect!!!

> The example in the standard shows a value reference and implicitly says that
> the referenced variable of union type has the same type as the active field.

But how can you KNOW which variant should be selected upon reading
the union value??? It could be very many which have the same type.
Do you want a celsius or a fahrenheit or a kelvin-value ... all are
numbers but all have different meanings, so only the right one should be selected EXPLICITELY and not just
the type of the field let the compiler determine erratically which
variant is meant!!!

If you allow that then this would be statically AND dynamically correct:

function celsius2kelvin(float celsius) return float {
return <some formula computing kelvin from celsius>;
}

var temperature t := { kelvin := 3.0 }
var temperature t := { kelvin := celsius2kelvin(t) };

If you would enforce quantification of unions, this would be
incorrect (as celsius2kelvin can't deal with a union), as
you would have to write

var temperature t := { kelvin := celsius2kelvin(t.celsius) }

which would result in a runtime error, as opposed to the other case
which would (probably) result in a semantic error the programmer
could search for years!!!

> Stephen's and Jacob's examples show value notations and not value
> references. At value notation, naturaly, the active field shall explicitly
> be selected (and a previously activ field can also be changed), so to make
> these examples correct we have to add:
> " x.alt2.field := 5;" // by the way, this example is not relevant
> to $6.3.5.0
> // but to $6.3.5.1 "Referencing
> fields of a union type"
> " temperature t := {celsius:=3.0}"
>
>
> Further on, in cases, when the actual type of "age" (without .number) can
> not be checked at compile time, the error like
>
> age.string := "thirtyfour";
> ageInMoths := age.number * 12;
>
> can not be detected either. So far we have not gained too much with the
> extra field in the value reference (but again, it is allowed!).

See above what you gain from it. The only case where you gain nothing
is where the union contains only different types for each variant!

> It was also told, that TTCN-3 does not have any polymorphic function. True
> for the predefined operations. But what about
>
> function Myf (anytype par_mypar1, anytype par_mypar2 ) return boolean
> {
> var boolean myresult;
> myresult := ( par_mypar1 == par_mypar2 );
> return myresult
> } // even if probably not true-polymorphic

This is not a polymorphic function as you can only use
operations on these values which are allowed on all values (like
comparison or passing them as anytype paramter or sending them
over all-type-ports or casting them via union-quantification to
an explicit type). This is not polymorhie!

> I'm not saying it is very useful, but allowed. And similar examples also can
> be made when the formal parameter is a union type, therefore the actual
> parameter should not explicitly (by ".number") pre-determine the active
> field.

Again, this is only true if you have disjoint union.

> Also, do not forget about external functions with e.g. anytype formal
> parameter(s).
>
> The example:
> " function f1(inout integer x) ...
> function f2(inout R x) ...
>
> var U x2 := { alt2 := 1) ;
>
> f1(x2); // legal
> f2(x2); // also legal...
> "
> gives a reason to think. But it also may be a good example for the opposit,
> if we modify it:
>
> " function f1(inout float x) return integer {...}
>
> var temperature t1 := { kelvin := 0 };
>
> f1(t1);
> "
>
> to make f1(t1.fahrenheit) the only mandatory notation would make this
> function usable for one of the choices and should return error for the other
> two.

Who said that f1(t1.fahrenheit) should be the only mandatory
notation, of course, f1(t1.celsius) and f1(t1.kelvin) can be used
as well, but NOT f1(t1) as that is ambiguous ... the point of
quantification is to differentiate between different variants of
the same type. Otherwise, you wouldn't need any differentiation on
assigning, either, as it would be clear which variant you want to set.

Jacob