TOPIC:

Hi,

and yet another issue that I would like to discuss:

What I think is missing badly from TTCN-3 is real type parameterization.
This makes writing generic code in TTCN-3 unneccessarily hard. Yes, we
do have the 'anytype' but that is not a real answer. Let me give you an
example that shows where the problem lies and why the anytype is not
really a solution:

Assume that we want to implement a generic liked list. One possible way
to do this in TTCN-3 is with a recursive type definition:

type record LinkedListElement {
integer value,
LinkedList next
};

type union LinkedList {
DummyType empty,
LinkedListElement list
};

type boolean DummyType; // really any type would do

These types allow representation of a linked list in a similar way that,
say, Java, C, or C++ allow representation of a linked list. It is even
closed to the way lists are represented in functional languages.

Of course there is an obvious flaw with this definition: this list can
only store integers. There is a straighforward improvement:

type record LinkedListElement {
anytype value,
LinkedList next
};

Now we can put 'anytype' into this list. But there are still two problems:

a) it is not 'type safe', a lilst can mix elements of different types
and we have to be very careful when accessing elements from that list.

b) When we import our LinkedList module into another module, the anytype
mentioned in the type definition above is the anytpe from the LinkedList
module. I.e., no type that is not known in the LinkedList module can be
put into the list.

Problem b) is why anytype is a strictly weaker mechanism than real type
parameterization. The same problem, for example, occurs when definition
a protocl with variable payload. What should be used to describe the
payload? Again, using anytype will only allow values of types known in
the protocol definition module to be used as payload.

This is a very unsatisfactory solution to type parameterization. In the
absence of generic pointers (void * in C, C++, Object references in
Java) where is not much we can do about these problems except making all
those type that shall be used in the context of such a generic data
structure or protocol definition known in the defining module - a clear
violation of the idea of modularization in the language.

To come to a conclusion - do also other people see this problem and
would it be worthwhile to start a discussion, how real type
parameterization could be added to TTCN-3?

BR

Stephan Tobies

--
Stephan Tobies Sr. Research Engineer, Nokia Research Center
~ Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany

Hi Stephan,

as far as I can remember, type parameterization was present in earlier
versions of TTCN-3.

It has been removed afterwards, but don't ask me why as I can not
remember. As far as we are conserned it could not have been an
implmentation issue.

Best regards,

Theo

Stephan Tobies wrote:

> Hi,
>
> and yet another issue that I would like to discuss:
>
> What I think is missing badly from TTCN-3 is real type parameterization.
> This makes writing generic code in TTCN-3 unneccessarily hard. Yes, we
> do have the 'anytype' but that is not a real answer. Let me give you an
> example that shows where the problem lies and why the anytype is not
> really a solution:
>
> Assume that we want to implement a generic liked list. One possible way
> to do this in TTCN-3 is with a recursive type definition:
>
> type record LinkedListElement {
> integer value,
> LinkedList next
> };
>
> type union LinkedList {
> DummyType empty,
> LinkedListElement list
> };
>
> type boolean DummyType; // really any type would do
>
> These types allow representation of a linked list in a similar way that,
> say, Java, C, or C++ allow representation of a linked list. It is even
> closed to the way lists are represented in functional languages.
>
> Of course there is an obvious flaw with this definition: this list can
> only store integers. There is a straighforward improvement:
>
> type record LinkedListElement {
> anytype value,
> LinkedList next
> };
>
> Now we can put 'anytype' into this list. But there are still two problems:
>
> a) it is not 'type safe', a lilst can mix elements of different types
> and we have to be very careful when accessing elements from that list.
>
> b) When we import our LinkedList module into another module, the anytype
> mentioned in the type definition above is the anytpe from the LinkedList
> module. I.e., no type that is not known in the LinkedList module can be
> put into the list.
>
> Problem b) is why anytype is a strictly weaker mechanism than real type
> parameterization. The same problem, for example, occurs when definition
> a protocl with variable payload. What should be used to describe the
> payload? Again, using anytype will only allow values of types known in
> the protocol definition module to be used as payload.
>
> This is a very unsatisfactory solution to type parameterization. In the
> absence of generic pointers (void * in C, C++, Object references in
> Java) where is not much we can do about these problems except making all
> those type that shall be used in the context of such a generic data
> structure or protocol definition known in the defining module - a clear
> violation of the idea of modularization in the language.
>
> To come to a conclusion - do also other people see this problem and
> would it be worthwhile to start a discussion, how real type
> parameterization could be added to TTCN-3?
>
> BR
>
> Stephan Tobies
>
> --
> Stephan Tobies Sr. Research Engineer, Nokia Research Center
> ~ Mobile Networks Lab, Protocol Engineering Group
> E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Work Phone: +49-234-9842262
> Fax: +49-234-9843491
> Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
>

ext Theofanis Vassiliou-Gioles wrote:

> Hi Stephan,
>
> as far as I can remember, type parameterization was present in earlier
> versions of TTCN-3.
>
> It has been removed afterwards, but don't ask me why as I can not
> remember. As far as we are conserned it could not have been an
> implmentation issue.
>
I can tell you why it was taken out - at that point, it was assumed that
the anytype would already deliver everything that type parameterization
would. It only turned out later that it does not. That's why I want to
restart the discussion on this.

BR

Stephan

--
Stephan Tobies Sr. Research Engineer, Nokia Research Center
~ Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany

Hi,

The real question would be, where type-parameterized types can be used. If they
could be used in other data type and port type definitions only (e.g. not even
in formal parameters lists), seems to be manageable.

If they could be used in constant, variable & template definitions, formal
parameter lists etc., well, this would be a more tricky area, - I believe -
leading to an overcomplicated & mismatched language with unclarities & lots of
exception cases at the end.

BR, Gyorgy

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of Stephan Tobies
> Sent: Friday, November 21, 2003 1:00 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Type parameterization revisited
>
>
> Hi,
>
> and yet another issue that I would like to discuss:
>
> What I think is missing badly from TTCN-3 is real type
> parameterization.
> This makes writing generic code in TTCN-3 unneccessarily hard. Yes, we
> do have the 'anytype' but that is not a real answer. Let me
> give you an
> example that shows where the problem lies and why the anytype is not
> really a solution:
>
> Assume that we want to implement a generic liked list. One
> possible way
> to do this in TTCN-3 is with a recursive type definition:
>
> type record LinkedListElement {
> integer value,
> LinkedList next
> };
>
> type union LinkedList {
> DummyType empty,
> LinkedListElement list
> };
>
> type boolean DummyType; // really any type would do
>
> These types allow representation of a linked list in a
> similar way that,
> say, Java, C, or C++ allow representation of a linked list. It is even
> closed to the way lists are represented in functional languages.
>
> Of course there is an obvious flaw with this definition: this list can
> only store integers. There is a straighforward improvement:
>
> type record LinkedListElement {
> anytype value,
> LinkedList next
> };
>
> Now we can put 'anytype' into this list. But there are still
> two problems:
>
> a) it is not 'type safe', a lilst can mix elements of different types
> and we have to be very careful when accessing elements from that list.
>
> b) When we import our LinkedList module into another module,
> the anytype
> mentioned in the type definition above is the anytpe from the
> LinkedList
> module. I.e., no type that is not known in the LinkedList
> module can be
> put into the list.
>
> Problem b) is why anytype is a strictly weaker mechanism than
> real type
> parameterization. The same problem, for example, occurs when
> definition
> a protocl with variable payload. What should be used to describe the
> payload? Again, using anytype will only allow values of types known in
> the protocol definition module to be used as payload.
>
> This is a very unsatisfactory solution to type
> parameterization. In the
> absence of generic pointers (void * in C, C++, Object references in
> Java) where is not much we can do about these problems except
> making all
> those type that shall be used in the context of such a generic data
> structure or protocol definition known in the defining module
> - a clear
> violation of the idea of modularization in the language.
>
> To come to a conclusion - do also other people see this problem and
> would it be worthwhile to start a discussion, how real type
> parameterization could be added to TTCN-3?
>
> BR
>
> Stephan Tobies
>
> --
> Stephan Tobies Sr. Research Engineer, Nokia Research Center
> ~ Mobile Networks Lab, Protocol Engineering Group
> E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Work Phone: +49-234-9842262
> Fax: +49-234-9843491
> Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
>

György Réthy (IJ/ETH) wrote:

> Hi,
>
> The real question would be, where type-parameterized types can be
> used. If they could be used in other data type and port type
> definitions only (e.g. not even in formal parameters lists), seems to
> be manageable.
>
> If they could be used in constant, variable & template definitions,
> formal parameter lists etc., well, this would be a more tricky area,
> - I believe - leading to an overcomplicated & mismatched language
> with unclarities & lots of exception cases at the end.
>

But if you would like to have (1) without having (2) this would also
lead to a "overcomplicated & mismatched language with unclarities & lots
of exception cases at the end." You would have to define something like
"as types of parameters only types that do not make use of type
parameterization shall be used". ([lots of exception])

As a user I would immediately ask why? ([unclarities])

If there is the opinion is that we should first collect the wish list,
where we would like to have type parameterization and where we could not
imagine that it would be easy to describe and/or implement, I would be
in favor of leaving the TTCN-3 type concept as it is.

We already now have some "extra rules" for some types. So either types
are parameterizable or they aren't. I really believe it would be a bad
idea to search just for a few "useful" exceptions and include them
somehow in the language.

Best regards,

Theo


> BR, Gyorgy
>
>
>>

---

Original Message

---

From: active_ttcn3 : mts stf133 ttcn
>> version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.]On
>> Behalf Of Stephan Tobies Sent: Friday, November 21, 2003 1:00 PM
>> To: This email address is being protected from spambots. You need JavaScript enabled to view it. Subject: Type parameterization revisited
>>
>>
>> Hi,
>>
>> and yet another issue that I would like to discuss:
>>
>> What I think is missing badly from TTCN-3 is real type
>> parameterization. This makes writing generic code in TTCN-3
>> unneccessarily hard. Yes, we do have the 'anytype' but that is not
>> a real answer. Let me give you an example that shows where the
>> problem lies and why the anytype is not really a solution:
>>
>> Assume that we want to implement a generic liked list. One possible
>> way to do this in TTCN-3 is with a recursive type definition:
>>
>> type record LinkedListElement { integer value, LinkedList next };
>>
>> type union LinkedList { DummyType empty, LinkedListElement list };
>>
>> type boolean DummyType; // really any type would do
>>
>> These types allow representation of a linked list in a similar way
>> that, say, Java, C, or C++ allow representation of a linked list.
>> It is even closed to the way lists are represented in functional
>> languages.
>>
>> Of course there is an obvious flaw with this definition: this list
>> can only store integers. There is a straighforward improvement:
>>
>> type record LinkedListElement { anytype value, LinkedList next };
>>
>> Now we can put 'anytype' into this list. But there are still two
>> problems:
>>
>> a) it is not 'type safe', a lilst can mix elements of different
>> types and we have to be very careful when accessing elements from
>> that list.
>>
>> b) When we import our LinkedList module into another module, the
>> anytype mentioned in the type definition above is the anytpe from
>> the LinkedList module. I.e., no type that is not known in the
>> LinkedList module can be put into the list.
>>
>> Problem b) is why anytype is a strictly weaker mechanism than real
>> type parameterization. The same problem, for example, occurs when
>> definition a protocl with variable payload. What should be used to
>> describe the payload? Again, using anytype will only allow values
>> of types known in the protocol definition module to be used as
>> payload.
>>
>> This is a very unsatisfactory solution to type parameterization. In
>> the absence of generic pointers (void * in C, C++, Object
>> references in Java) where is not much we can do about these
>> problems except making all those type that shall be used in the
>> context of such a generic data structure or protocol definition
>> known in the defining module - a clear violation of the idea of
>> modularization in the language.
>>
>> To come to a conclusion - do also other people see this problem and
>> would it be worthwhile to start a discussion, how real type
>> parameterization could be added to TTCN-3?
>>
>> BR
>>
>> Stephan Tobies
>>
>> -- Stephan Tobies Sr. Research Engineer, Nokia Research Center ~
>> Mobile Networks Lab, Protocol Engineering Group E-Mail:
>> This email address is being protected from spambots. You need JavaScript enabled to view it. Work Phone: +49-234-9842262 Fax:
>> +49-234-9843491 Address: NRC Bochum, Meesmannstr. 103,
>> 44807 Bochum, Germany
>>
>
>

We have clause 5.2 in the standard describing general parameterization rules. To say there that "type parameterization is allowed in other data types and port types only" and enforce it in the bnf did not seemed overcomplicated & mismatched to me. But we do not have parameterized constants, variables, in templates only template field values can be parameterized etc. Shortly, we have a clear type-value-template definitions phylosophy and to change the phylosophy of a language seems to be much more problematic. (To be clear, at this point I'm not advocating for or against, just sharing the first thoughts)

Gyorgy

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of Theofanis Vassiliou-Gioles
> Sent: Friday, November 21, 2003 1:24 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Type parameterization revisited
>
>
> György Réthy (IJ/ETH) wrote:
>
> > Hi,
> >
> > The real question would be, where type-parameterized types can be
> > used. If they could be used in other data type and port type
> > definitions only (e.g. not even in formal parameters
> lists), seems to
> > be manageable.
> >
> > If they could be used in constant, variable & template definitions,
> > formal parameter lists etc., well, this would be a more tricky area,
> > - I believe - leading to an overcomplicated & mismatched language
> > with unclarities & lots of exception cases at the end.
> >
>
> But if you would like to have (1) without having (2) this would also
> lead to a "overcomplicated & mismatched language with
> unclarities & lots
> of exception cases at the end." You would have to define
> something like
> "as types of parameters only types that do not make use of type
> parameterization shall be used". ([lots of exception])
>
> As a user I would immediately ask why? ([unclarities])
>
> If there is the opinion is that we should first collect the
> wish list,
> where we would like to have type parameterization and where
> we could not
> imagine that it would be easy to describe and/or implement, I
> would be
> in favor of leaving the TTCN-3 type concept as it is.
>
> We already now have some "extra rules" for some types. So
> either types
> are parameterizable or they aren't. I really believe it would
> be a bad
> idea to search just for a few "useful" exceptions and include them
> somehow in the language.
>
> Best regards,
>
> Theo
>
>
> > BR, Gyorgy
> >
> >
> >>

---

Original Message

---

From: active_ttcn3 : mts stf133 ttcn
> >> version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.]On
> >> Behalf Of Stephan Tobies Sent: Friday, November 21, 2003 1:00 PM
> >> To: This email address is being protected from spambots. You need JavaScript enabled to view it. Subject: Type parameterization revisited
> >>
> >>
> >> Hi,
> >>
> >> and yet another issue that I would like to discuss:
> >>
> >> What I think is missing badly from TTCN-3 is real type
> >> parameterization. This makes writing generic code in TTCN-3
> >> unneccessarily hard. Yes, we do have the 'anytype' but that is not
> >> a real answer. Let me give you an example that shows where the
> >> problem lies and why the anytype is not really a solution:
> >>
> >> Assume that we want to implement a generic liked list. One possible
> >> way to do this in TTCN-3 is with a recursive type definition:
> >>
> >> type record LinkedListElement { integer value, LinkedList next };
> >>
> >> type union LinkedList { DummyType empty, LinkedListElement list };
> >>
> >> type boolean DummyType; // really any type would do
> >>
> >> These types allow representation of a linked list in a similar way
> >> that, say, Java, C, or C++ allow representation of a linked list.
> >> It is even closed to the way lists are represented in functional
> >> languages.
> >>
> >> Of course there is an obvious flaw with this definition: this list
> >> can only store integers. There is a straighforward improvement:
> >>
> >> type record LinkedListElement { anytype value, LinkedList next };
> >>
> >> Now we can put 'anytype' into this list. But there are still two
> >> problems:
> >>
> >> a) it is not 'type safe', a lilst can mix elements of different
> >> types and we have to be very careful when accessing elements from
> >> that list.
> >>
> >> b) When we import our LinkedList module into another module, the
> >> anytype mentioned in the type definition above is the anytpe from
> >> the LinkedList module. I.e., no type that is not known in the
> >> LinkedList module can be put into the list.
> >>
> >> Problem b) is why anytype is a strictly weaker mechanism than real
> >> type parameterization. The same problem, for example, occurs when
> >> definition a protocl with variable payload. What should be used to
> >> describe the payload? Again, using anytype will only allow values
> >> of types known in the protocol definition module to be used as
> >> payload.
> >>
> >> This is a very unsatisfactory solution to type parameterization. In
> >> the absence of generic pointers (void * in C, C++, Object
> >> references in Java) where is not much we can do about these
> >> problems except making all those type that shall be used in the
> >> context of such a generic data structure or protocol definition
> >> known in the defining module - a clear violation of the idea of
> >> modularization in the language.
> >>
> >> To come to a conclusion - do also other people see this problem and
> >> would it be worthwhile to start a discussion, how real type
> >> parameterization could be added to TTCN-3?
> >>
> >> BR
> >>
> >> Stephan Tobies
> >>
> >> -- Stephan Tobies Sr. Research Engineer, Nokia Research Center ~
> >> Mobile Networks Lab, Protocol Engineering Group E-Mail:
> >> This email address is being protected from spambots. You need JavaScript enabled to view it. Work Phone: +49-234-9842262 Fax:
> >> +49-234-9843491 Address: NRC Bochum, Meesmannstr. 103,
> >> 44807 Bochum, Germany
> >>
> >
> >
>

György Réthy (IJ/ETH) wrote:

> We have clause 5.2 in the standard describing general
> parameterization rules. To say there that "type parameterization is
> allowed in other data types and port types only" and enforce it in
> the bnf did not seemed overcomplicated & mismatched to me. But we do
> not have parameterized constants, variables, in templates only
> template field values can be parameterized etc.
Yes, but constants have types, variables have types, etc. I understood
your previous email, that this elements should not be allowed to be of
types that are using type parametrization.

I understood Stephans initial mail that he wanted to have something like:

type record LinkedListElement(Type aType) {
aType value,
LinkedList(aType) next
};

type union LinkedList(LinkedListElementType elementType) {
DummyType empty,
elementType list
};

The would give us the possibility to write something like

type LinkedList(integer) IntegerLinkedList ;
or
type LinkedList(MyRecordType) MyRecordLinkedList ;


[NOTE: This are only quick invented code snippets and by no means meant
to be a basis for consistent definition]

But of course I would like, if I can define in such a way new types, to
use them also a type for a constant, a variable etc.

At least this is my undestanding of type parameterization.

Best regards,

Theo


> Shortly, we have a
> clear type-value-template definitions phylosophy and to change the
> phylosophy of a language seems to be much more problematic. (To be
> clear, at this point I'm not advocating for or against, just sharing
> the first thoughts)
>
> Gyorgy
>
>
>>

---

Original Message

---

From: active_ttcn3 : mts stf133 ttcn
>> version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.]On
>> Behalf Of Theofanis Vassiliou-Gioles Sent: Friday, November 21,
>> 2003 1:24 PM To: This email address is being protected from spambots. You need JavaScript enabled to view it. Subject: Re: Type
>> parameterization revisited
>>
>>
>> György Réthy (IJ/ETH) wrote:
>>
>>
>>> Hi,
>>>
>>> The real question would be, where type-parameterized types can be
>>> used. If they could be used in other data type and port type
>>> definitions only (e.g. not even in formal parameters
>>
>> lists), seems to
>>
>>> be manageable.
>>>
>>> If they could be used in constant, variable & template
>>> definitions, formal parameter lists etc., well, this would be a
>>> more tricky area, - I believe - leading to an overcomplicated &
>>> mismatched language with unclarities & lots of exception cases at
>>> the end.
>>>
>>
>> But if you would like to have (1) without having (2) this would
>> also lead to a "overcomplicated & mismatched language with
>> unclarities & lots of exception cases at the end." You would have
>> to define something like "as types of parameters only types that do
>> not make use of type parameterization shall be used". ([lots of
>> exception])
>>
>> As a user I would immediately ask why? ([unclarities])
>>
>> If there is the opinion is that we should first collect the wish
>> list, where we would like to have type parameterization and where
>> we could not imagine that it would be easy to describe and/or
>> implement, I would be in favor of leaving the TTCN-3 type concept
>> as it is.
>>
>> We already now have some "extra rules" for some types. So either
>> types are parameterizable or they aren't. I really believe it would
>> be a bad idea to search just for a few "useful" exceptions and
>> include them somehow in the language.
>>
>> Best regards,
>>
>> Theo
>>
>>
>>
>>> BR, Gyorgy
>>>
>>>
>>>
>>>>

---

Original Message

---

From: active_ttcn3 : mts stf133 ttcn
>>>> version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.]On
>>>> Behalf Of Stephan Tobies Sent: Friday, November 21, 2003 1:00
>>>> PM To: This email address is being protected from spambots. You need JavaScript enabled to view it. Subject: Type parameterization
>>>> revisited
>>>>
>>>>
>>>> Hi,
>>>>
>>>> and yet another issue that I would like to discuss:
>>>>
>>>> What I think is missing badly from TTCN-3 is real type
>>>> parameterization. This makes writing generic code in TTCN-3
>>>> unneccessarily hard. Yes, we do have the 'anytype' but that is
>>>> not a real answer. Let me give you an example that shows where
>>>> the problem lies and why the anytype is not really a solution:
>>>>
>>>> Assume that we want to implement a generic liked list. One
>>>> possible way to do this in TTCN-3 is with a recursive type
>>>> definition:
>>>>
>>>> type record LinkedListElement { integer value, LinkedList next
>>>> };
>>>>
>>>> type union LinkedList { DummyType empty, LinkedListElement list
>>>> };
>>>>
>>>> type boolean DummyType; // really any type would do
>>>>
>>>> These types allow representation of a linked list in a similar
>>>> way that, say, Java, C, or C++ allow representation of a linked
>>>> list. It is even closed to the way lists are represented in
>>>> functional languages.
>>>>
>>>> Of course there is an obvious flaw with this definition: this
>>>> list can only store integers. There is a straighforward
>>>> improvement:
>>>>
>>>> type record LinkedListElement { anytype value, LinkedList next
>>>> };
>>>>
>>>> Now we can put 'anytype' into this list. But there are still
>>>> two problems:
>>>>
>>>> a) it is not 'type safe', a lilst can mix elements of different
>>>> types and we have to be very careful when accessing elements
>>>> from that list.
>>>>
>>>> b) When we import our LinkedList module into another module,
>>>> the anytype mentioned in the type definition above is the
>>>> anytpe from the LinkedList module. I.e., no type that is not
>>>> known in the LinkedList module can be put into the list.
>>>>
>>>> Problem b) is why anytype is a strictly weaker mechanism than
>>>> real type parameterization. The same problem, for example,
>>>> occurs when definition a protocl with variable payload. What
>>>> should be used to describe the payload? Again, using anytype
>>>> will only allow values of types known in the protocol
>>>> definition module to be used as payload.
>>>>
>>>> This is a very unsatisfactory solution to type
>>>> parameterization. In the absence of generic pointers (void * in
>>>> C, C++, Object references in Java) where is not much we can do
>>>> about these problems except making all those type that shall be
>>>> used in the context of such a generic data structure or
>>>> protocol definition known in the defining module - a clear
>>>> violation of the idea of modularization in the language.
>>>>
>>>> To come to a conclusion - do also other people see this problem
>>>> and would it be worthwhile to start a discussion, how real type
>>>> parameterization could be added to TTCN-3?
>>>>
>>>> BR
>>>>
>>>> Stephan Tobies
>>>>
>>>> -- Stephan Tobies Sr. Research Engineer, Nokia Research
>>>> Center ~ Mobile Networks Lab, Protocol Engineering Group
>>>> E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it. Work Phone:
>>>> +49-234-9842262 Fax: +49-234-9843491 Address: NRC
>>>> Bochum, Meesmannstr. 103, 44807 Bochum, Germany
>>>>
>>>
>>>
>

ext Theofanis Vassiliou-Gioles wrote:

> György Réthy (IJ/ETH) wrote:
>
>> We have clause 5.2 in the standard describing general
>> parameterization rules. To say there that "type parameterization is
>> allowed in other data types and port types only" and enforce it in
>> the bnf did not seemed overcomplicated & mismatched to me. But we do
>> not have parameterized constants, variables, in templates only
>> template field values can be parameterized etc.
>
> Yes, but constants have types, variables have types, etc. I understood
> your previous email, that this elements should not be allowed to be of
> types that are using type parametrization.
>
> I understood Stephans initial mail that he wanted to have something like:
>
> type record LinkedListElement(Type aType) {
> aType value,
> LinkedList(aType) next
> };
>
> type union LinkedList(LinkedListElementType elementType) {
> DummyType empty,
> elementType list
> };
>
> The would give us the possibility to write something like
>
> type LinkedList(integer) IntegerLinkedList ;
> or
> type LinkedList(MyRecordType) MyRecordLinkedList ;
>
>

Yes, this is exacly what I had in mind. Probably this alone will take
use quite far with the protocol definition payload problem. It is not
enough for generic TTCN-3 libraries, though. There should also be the
possibility to write code that is independent of that actual
instantiation of aType, so, for example, one should be able to write:

function isEmpty(LinkedList list) return boolean {

if (ischosen(list.empty)) {
return true;
} else {
return false;
}
}

So, as long as we do not look into the value field, it should be
possible to write generic code that works for any instantiation of
LinkedList. This would, for example, allow to write also a function that
counts the elements.

But then how to write 'append'. Append also does not need to look into
the value fields, but it should ensure that the two appended lists are
of the same type. So:

function append(LinkedList l1, LinkedList l2) return LinkedList {
...
}


is not enough - this signature does not enforce l1 and l2 to be of the
same instance of LinkedList. It also does not specify that the returned
LinkedList instance is again of the same type.

And what happens when we want to write an 'isElement' function that
needs to ensure type compatibility between the element type and the
LinkedList instance?

So, in other words, it is not that easy.

There are, of course, solutions to this problem, in other programming
languages, maybe we should look there for inspiration: templates in C++,
generics in (currently being added to) Java, type classes in functional
programming languages.

I see Gyorgy's point: maybe the price of adding this to TTCN-3 is too
high, but I would not like to jump to this conclusion right now.

It is good to see, that it is not only me that would think that some
kind of type parameterization in TTCN-3 would be a good idea.

BR

Stephan

[rested snipped]

--
Stephan Tobies Sr. Research Engineer, Nokia Research Center
~ Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany

> It is good to see, that it is not only me that would think that some
> kind of type parameterization in TTCN-3 would be a good idea.

You are not the only one: not to forget that type parameterization was
once in TTCN-3. However, at this point now, we would need a solid CR to
put it back again. A CR is the basis for discussion and decision.

Cheers, Ina.

Stephan Tobies wrote:
> ext Theofanis Vassiliou-Gioles wrote:
>
>> György Réthy (IJ/ETH) wrote:
>>
>>> We have clause 5.2 in the standard describing general
>>> parameterization rules. To say there that "type parameterization is
>>> allowed in other data types and port types only" and enforce it in
>>> the bnf did not seemed overcomplicated & mismatched to me. But we do
>>> not have parameterized constants, variables, in templates only
>>> template field values can be parameterized etc.
>>
>>
>> Yes, but constants have types, variables have types, etc. I understood
>> your previous email, that this elements should not be allowed to be of
>> types that are using type parametrization.
>>
>> I understood Stephans initial mail that he wanted to have something like:
>>
>> type record LinkedListElement(Type aType) {
>> aType value,
>> LinkedList(aType) next
>> };
>>
>> type union LinkedList(LinkedListElementType elementType) {
>> DummyType empty,
>> elementType list
>> };
>>
>> The would give us the possibility to write something like
>>
>> type LinkedList(integer) IntegerLinkedList ;
>> or
>> type LinkedList(MyRecordType) MyRecordLinkedList ;
>>
>>
>
> Yes, this is exacly what I had in mind. Probably this alone will take
> use quite far with the protocol definition payload problem. It is not
> enough for generic TTCN-3 libraries, though. There should also be the
> possibility to write code that is independent of that actual
> instantiation of aType, so, for example, one should be able to write:
>
> function isEmpty(LinkedList list) return boolean {
>
> if (ischosen(list.empty)) {
> return true;
> } else {
> return false;
> }
> }
>
> So, as long as we do not look into the value field, it should be
> possible to write generic code that works for any instantiation of
> LinkedList. This would, for example, allow to write also a function that
> counts the elements.
>
> But then how to write 'append'. Append also does not need to look into
> the value fields, but it should ensure that the two appended lists are
> of the same type. So:
>
> function append(LinkedList l1, LinkedList l2) return LinkedList {
> ...
> }
>
>
> is not enough - this signature does not enforce l1 and l2 to be of the
> same instance of LinkedList. It also does not specify that the returned
> LinkedList instance is again of the same type.
>
> And what happens when we want to write an 'isElement' function that
> needs to ensure type compatibility between the element type and the
> LinkedList instance?
>
> So, in other words, it is not that easy.
>
> There are, of course, solutions to this problem, in other programming
> languages, maybe we should look there for inspiration: templates in C++,
> generics in (currently being added to) Java, type classes in functional
> programming languages.
>
> I see Gyorgy's point: maybe the price of adding this to TTCN-3 is too
> high, but I would not like to jump to this conclusion right now.
>
> It is good to see, that it is not only me that would think that some
> kind of type parameterization in TTCN-3 would be a good idea.
>
> BR
>
> Stephan
>
> [rested snipped]
>


--

---

Ina Schieferdecker
Fraunhofer FOKUS email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
D-10589 Berlin fax: ++49-30-3463-8241

---

ext Ina Schieferdecker wrote:

> > It is good to see, that it is not only me that would think that some
> > kind of type parameterization in TTCN-3 would be a good idea.
>
> You are not the only one: not to forget that type parameterization was
> once in TTCN-3. However, at this point now, we would need a solid CR
> to put it back again. A CR is the basis for discussion and decision.
>
> Cheers, Ina.
>

Actually, I think it is too early to write a CR, at least for me. I
first need to understand the ramifications of adding type
parameterization to the language and the various possible alternative to
do it, before I could come up with a CR solid enough for serious
considerations.

BR

Stephan

--
Stephan Tobies Sr. Research Engineer, Nokia Research Center
~ Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany

Use ASN.1 type definitions if you need type parameterization! You can
easily do the linked list example this way. And you could use import and
use the definition in TTCN-3. I do not see the benefits of
re-implementing ASN.1 in TTCN-3. Anyway, you would not gain much with
this feature as you have no generic way of handling variable types in
TTCN-3. All you need to add into TTCN-3 is C++-like templates and
polymorphism to solve the problem. This sounds to me as a complete
redesign of the language 8( The question is how long do we try to
squeeze new functionality into TTCN-3? There will be always some
problems that you cannot solve with TTCN-3!

BR, Roland.
--
Roland Gecse [ETH/RK] This email address is being protected from spambots. You need JavaScript enabled to view it., ttcn.ericsson.se
Tel.: +36-1-437:7618, ECN: 831:, MS: +36-30-2030881, Fax: +36-1-437 7767
Ericsson Hungary, 1117 Budapest, Irinyi u. 4-20.

Hi,
In your example

> function isEmpty(LinkedList list) return boolean {
>
> if (ischosen(list.empty)) {
> return true;
> } else {
> return false;
> }
> }

your formal parameter do not have (a definite) type as LinkedList(LinkedListElementType elementType) is not complete. Today we do not allow overloading (except operators and the predefined stuff) and require that formal parameters have a type. To make your formal parameter to have a type you would need to write "function isEmpty(LinkedList(integer) list) return boolean ..."
But in this case you have defined a new type in a formal parameters list of a function. Today we require to define user defined types explicitly, following the type keyword.

Similar situations if you want to use a parameterized type in constants, variables, templates etc. etc. etc.

As I told before this would lead to the change of the language philosophy. I do not think that we need such kind of changes today (I would rather say we need something stable that could be deployed easily). At least our testers do not expect us to develop a new complicated language but a simple one which can be used easily and efficiently (otherwise C/C++ could also be used for testing, why to choose TTCN-3?).

Gyorgy
>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of Stephan Tobies
> Sent: Friday, November 21, 2003 2:28 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Type parameterization revisited
>
>
> ext Theofanis Vassiliou-Gioles wrote:
>
> > György Réthy (IJ/ETH) wrote:
> >
> >> We have clause 5.2 in the standard describing general
> >> parameterization rules. To say there that "type parameterization is
> >> allowed in other data types and port types only" and enforce it in
> >> the bnf did not seemed overcomplicated & mismatched to me.
> But we do
> >> not have parameterized constants, variables, in templates only
> >> template field values can be parameterized etc.
> >
> > Yes, but constants have types, variables have types, etc. I
> understood
> > your previous email, that this elements should not be
> allowed to be of
> > types that are using type parametrization.
> >
> > I understood Stephans initial mail that he wanted to have
> something like:
> >
> > type record LinkedListElement(Type aType) {
> > aType value,
> > LinkedList(aType) next
> > };
> >
> > type union LinkedList(LinkedListElementType elementType) {
> > DummyType empty,
> > elementType list
> > };
> >
> > The would give us the possibility to write something like
> >
> > type LinkedList(integer) IntegerLinkedList ;
> > or
> > type LinkedList(MyRecordType) MyRecordLinkedList ;
> >
> >
>
> Yes, this is exacly what I had in mind. Probably this alone will take
> use quite far with the protocol definition payload problem. It is not
> enough for generic TTCN-3 libraries, though. There should also be the
> possibility to write code that is independent of that actual
> instantiation of aType, so, for example, one should be able to write:
>
> function isEmpty(LinkedList list) return boolean {
>
> if (ischosen(list.empty)) {
> return true;
> } else {
> return false;
> }
> }
>
> So, as long as we do not look into the value field, it should be
> possible to write generic code that works for any instantiation of
> LinkedList. This would, for example, allow to write also a
> function that
> counts the elements.
>
> But then how to write 'append'. Append also does not need to
> look into
> the value fields, but it should ensure that the two appended
> lists are
> of the same type. So:
>
> function append(LinkedList l1, LinkedList l2) return LinkedList {
> ...
> }
>
>
> is not enough - this signature does not enforce l1 and l2 to
> be of the
> same instance of LinkedList. It also does not specify that
> the returned
> LinkedList instance is again of the same type.
>
> And what happens when we want to write an 'isElement' function that
> needs to ensure type compatibility between the element type and the
> LinkedList instance?
>
> So, in other words, it is not that easy.
>
> There are, of course, solutions to this problem, in other programming
> languages, maybe we should look there for inspiration:
> templates in C++,
> generics in (currently being added to) Java, type classes in
> functional
> programming languages.
>
> I see Gyorgy's point: maybe the price of adding this to TTCN-3 is too
> high, but I would not like to jump to this conclusion right now.
>
> It is good to see, that it is not only me that would think that some
> kind of type parameterization in TTCN-3 would be a good idea.
>
> BR
>
> Stephan
>
> [rested snipped]
>
> --
> Stephan Tobies Sr. Research Engineer, Nokia Research Center
> ~ Mobile Networks Lab, Protocol Engineering Group
> E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Work Phone: +49-234-9842262
> Fax: +49-234-9843491
> Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
>

This does not work: importing ASN.1 into TTCN-3 means that ASN.1 is
mapped onto the TTCN-3 type system and templates internally... as TTCN-3
has in its strict reading no type parameterization, then you have no
target where to map the ASN.1 type parameterization to. Except that you
have chosen to extend TTCN-3 in order to support type parameterization :-)

Cheers, Ina.

Roland Gecse wrote:
> Use ASN.1 type definitions if you need type parameterization! You can
> easily do the linked list example this way. And you could use import and
> use the definition in TTCN-3. I do not see the benefits of
> re-implementing ASN.1 in TTCN-3. Anyway, you would not gain much with
> this feature as you have no generic way of handling variable types in
> TTCN-3. All you need to add into TTCN-3 is C++-like templates and
> polymorphism to solve the problem. This sounds to me as a complete
> redesign of the language 8( The question is how long do we try to
> squeeze new functionality into TTCN-3? There will be always some
> problems that you cannot solve with TTCN-3!
>
> BR, Roland.
> --
> Roland Gecse [ETH/RK] This email address is being protected from spambots. You need JavaScript enabled to view it., ttcn.ericsson.se
> Tel.: +36-1-437:7618, ECN: 831:, MS: +36-30-2030881, Fax: +36-1-437 7767
> Ericsson Hungary, 1117 Budapest, Irinyi u. 4-20.


--

---

Ina Schieferdecker
Fraunhofer FOKUS email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
D-10589 Berlin fax: ++49-30-3463-8241

---

You are right, the parameterized ASN.1 type is not visible in TTCN-3.
And it still works -- without extending TTCN-3 with support for type
parameterization 8)

But the type utilizing it shall be visible! See the example below:

=============================================================
M DEFINITIONS ::=
BEGIN

LikedList{Type} ::= SEQUENCE {
item Type,
next LinkedList{Type}
}

LinkedListInt ::= LinkedList{INTEGER}

END
==============================================================

LinkedList{Type} has no TTCN-3 view, but LinkedListInt does!

Sorry,
Roland.



Ina Schieferdecker wrote:
> This does not work: importing ASN.1 into TTCN-3 means that ASN.1 is
> mapped onto the TTCN-3 type system and templates internally... as TTCN-3
> has in its strict reading no type parameterization, then you have no
> target where to map the ASN.1 type parameterization to. Except that you
> have chosen to extend TTCN-3 in order to support type parameterization :-)
>
> Cheers, Ina.
>
> Roland Gecse wrote:
>
>> Use ASN.1 type definitions if you need type parameterization! You can
>> easily do the linked list example this way. And you could use import and
>> use the definition in TTCN-3. I do not see the benefits of
>> re-implementing ASN.1 in TTCN-3. Anyway, you would not gain much with
>> this feature as you have no generic way of handling variable types in
>> TTCN-3. All you need to add into TTCN-3 is C++-like templates and
>> polymorphism to solve the problem. This sounds to me as a complete
>> redesign of the language 8( The question is how long do we try to
>> squeeze new functionality into TTCN-3? There will be always some
>> problems that you cannot solve with TTCN-3!
>>
>> BR, Roland.
>> --
>> Roland Gecse [ETH/RK] This email address is being protected from spambots. You need JavaScript enabled to view it., ttcn.ericsson.se
>> Tel.: +36-1-437:7618, ECN: 831:, MS: +36-30-2030881, Fax: +36-1-437 7767
>> Ericsson Hungary, 1117 Budapest, Irinyi u. 4-20.
>
>
>
> --
>

---

> Ina Schieferdecker
> Fraunhofer FOKUS email: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
> D-10589 Berlin fax: ++49-30-3463-8241
>

---

--
Roland Gecse [ETH/RK] This email address is being protected from spambots. You need JavaScript enabled to view it., ttcn.ericsson.se
Tel.: +36-1-437:7618, ECN: 831:, MS: +36-30-2030881, Fax: +36-1-437 7767
Ericsson Hungary, 1117 Budapest, Irinyi u. 4-20.

...and the "next" field should be optional, of course.

Dear all,

I tried to remember why type parameterization has been finally removed
from TTCN-3: the problems where not with pure data types but with
special types for test configurations. For example, it would be possible
to have a component type which uses a port array whose length depends on
a module parameter. In other words, only at runtime such a component
type would be fixed.

On the other hand, if one would forbid type parameterization for
configuration types but not for data types, this would make the language
asymmetric: this language feature would not be applicable to all types,
what could confuse users.

Also, a strict removal of type parameterization for configuration types
is not useful as for example, there is not harm with local variables.

I think we should reconsider whether the restrictions on type
parameterization for configuration types are necessary - for example, is
it really needed that the TSI is statically fixed. And if yes, is there
an easy to understand way to restrict type parameterization for port
types and implicit arrays of ports (and may be for more: I guess the
address type could also give problems) and to allow it for the other types.

With best regards,

Ina.

--

---

Prof. Dr.-Ing. Ina Schieferdecker
Fraunhofer FOKUS email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
D-10589 Berlin fax: ++49-30-3463-8241

---

Hi,

considering what have been said before (including Stephan initial
proposal, Anthonies statement on resources and Georgys remark on
overloading and stability) I would think it is time to start a first
round of call whether "type parameterization" should be a candidate for
future discussions.

My opinion is that including type parameterization into the language
would be very nice to have. And I would support any kind of work going
into this directions. Of course my interests would be to have such kind
of possible included within the terms I have described in a previous
email (either everywhere or nowhere ;-)

It would help solve every days problems nicely and elegantly.

However, I admit that this is not just a small modification in the sense
of maintenance but but a real, nevertheless very useful extension. To be
honest I was very sorry when this concept was removed from the the
TTCN-3 specification.

But before anybody spends to many man days (and nights) of (volunteer)
work into this subject I would like to know whether beside Stephan, Ina
and myself there are other people that would find this useful.

Best regards,

Theo


Ina Schieferdecker wrote:

> Dear all,
>
> I tried to remember why type parameterization has been finally removed
> from TTCN-3: the problems where not with pure data types but with
> special types for test configurations. For example, it would be possible
> to have a component type which uses a port array whose length depends on
> a module parameter. In other words, only at runtime such a component
> type would be fixed.
>
> On the other hand, if one would forbid type parameterization for
> configuration types but not for data types, this would make the language
> asymmetric: this language feature would not be applicable to all types,
> what could confuse users.
>
> Also, a strict removal of type parameterization for configuration types
> is not useful as for example, there is not harm with local variables.
>
> I think we should reconsider whether the restrictions on type
> parameterization for configuration types are necessary - for example, is
> it really needed that the TSI is statically fixed. And if yes, is there
> an easy to understand way to restrict type parameterization for port
> types and implicit arrays of ports (and may be for more: I guess the
> address type could also give problems) and to allow it for the other types.
>
> With best regards,
>
> Ina.
>
> --
>

---

> Prof. Dr.-Ing. Ina Schieferdecker
> Fraunhofer FOKUS email: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
> D-10589 Berlin fax: ++49-30-3463-8241
>

---

>

In einer eMail vom 23/11/2003 07:23:48 GMT Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

>
> Dear all,

Hi Ina,

I recall one session at ETSI where type parameterization was discussed. We
had
come to the conclusion that it should be avoided as it would cause problems
if type parameterization were used at the module level. I have a vague
memory of Colin W. explaining why it was so.

Colin, do you remember the conversation? :-)

I can't remember what exactly was difficult, but it was mostly because of
this that
we had decided to drop type parameterization.

>
> I tried to remember why type parameterization has been finally removed
> from TTCN-3: the problems where not with pure data types but with
> special types for test configurations. For example, it would be possible
> to have a component type which uses a port array whose length depends on
> a module parameter. In other words, only at runtime such a component
> type would be fixed.
>
> On the other hand, if one would forbid type parameterization for
> configuration types but not for data types, this would make the language
> asymmetric: this language feature would not be applicable to all types,
> what could confuse users.

Yes, non orthogonal languages can be a source of confusion for new users,let
alone
the more experienced ones.

>
> Also, a strict removal of type parameterization for configuration types
> is not useful as for example, there is not harm with local variables.
>
> I think we should reconsider whether the restrictions on type
> parameterization for configuration types are necessary - for example, is
> it really needed that the TSI is statically fixed. And if yes, is there
> an easy to understand way to restrict type parameterization for port
> types and implicit arrays of ports (and may be for more: I guess the
> address type could also give problems) and to allow it for the other types.
>
> With best regards,
>
> Ina.
>

Cheers,

Claude.


Claude Desroches email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Solonplatz 3/2 phone: +49 30 9606 7986
13088 Berlin fax: +49 30 9606 7987

Germany

ext György Réthy (IJ/ETH) wrote:

>Hi,
>In your example
>
>
>
>>function isEmpty(LinkedList list) return boolean {
>>
>> if (ischosen(list.empty)) {
>> return true;
>> } else {
>> return false;
>> }
>>}
>>
>>
>
>your formal parameter do not have (a definite) type as LinkedList(LinkedListElementType elementType) is not complete. Today we do not allow overloading (except operators and the predefined stuff) and require that formal parameters have a type.
>

As long as no access is made to fields that have an undefined type in
this context, such code could still be safe. But it is problematic, I agree.

Still, I think it is worthwhile to think about how type parameterization
could be added _safely_ to the language. Unlike C++, C, or Java, TTCN-3
does not allow void pointers (Object references) and casting. This is
good, because it makes the language safer. It also means that it becomes
impossible to write, for example, a generic container library, and leads
to problems with protocol definition where the payload type should be
kept variable.

The first issue might not even be so bad - after all we are talking
about a test language, not a general purpose programming language, The
second aspect, though, is more severe. Although, it can probably dealt
with with a lighter-weight parameterization issue than the first because
that one involves behaviour, too.

[snip]

BR

Stephan
--

Stephan Tobies Sr. Research Engineer, Nokia Research Center
~ Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany