TOPIC:

Hi All,

For 'record of' fields within records, I have a couple of questions. Consider
simply:


type record tField
{
integer a,
integer b
};

template tField tpField ( template integer x, template integer y ) :=
{
a := x,
b := y
};

type record of tField tRecOfFields;

type record tMyRec
{
tRecOfFields fields
};



Problem 1: Supposing I need to set up a template tMyRecord with 256 elements in
'fields' in a regular pattern, is there a way of setting up these elements
except for doing it the long handed way below (ideally, I'd like to be able to
use some sort of 'for' loop)?


template tMyRec tpMyBigRec :=
{
{
tpField(1,?),
tpField(?,2),
tpField(3,?),

tpField(?,4),
...,

tpField(255,?),

tpField(?,256),
}
};



Problem 2: Supposing I want to only to modify the 4th element of 'fields', is
there a way of doing this using the 'modifies' construct without having to
specify all the other 255 elements again?


I think the answer to these questions is no. I have a couple of tentative
solutions. I'd be interested to know what people think.


Possible Solution to Problem 1: Allow 'template variables' and functions
returning templates (I think this could potentially be quite a powerful
feature). E.g.


function buildFields ( integer maxElements ) return template tRecOfFields
{
var template tField field;
var template tRecOfFields fields;
var integer idx;

for ( idx := 1 ; idx <= maxElements ; idx := idx + 1 )
{
if ( ( idx mod 2 ) == 1 ) { field := { idx, ? }; } else { field := { ?,
idx }; }
fields[idx-1] := field;
}
return fields;
}


template tMyRec tpMyBigRec :=
{
fields := buildfields( 256 )
};


Possible Solution to Problem 2: Permit indexing of 'record of' types (and
anything else that can be indexed) in 'modifies' specification:


template tMyRec tpModRec ( template tField newFieldValue ) modifies tpMyBigRec
:=
{
fields[3] := newFieldValue
// of course, for nested indexable types, I'd expect to be able to do this:
// fields[3] :=
// {
// ...
// indexableFields[5] := newValueA,
// ...
// nonIndexableField := newValueB
// ..., etc
// }
};



Regards


Ray Cheung


Motorola GTSS
Swindon
UK

Hi Ray,

Personally I like your idea of template variables. Note that some
tools may already allow you to mix explicit value notation and
matching mechanisms in quite a free form fashion in expressions,
variable assignments, function parameters etc., thus implicitly
supporting 'var template' kind of modifier.

Note that your 'var template' idea could also solve your problem
#2 without the need to introduce any new features into 'modifies'
clause.

Potential solution to problem #2 (assuming that functions can
return templates and relaxed rules to variable assignments
apply):

function tpModRec(
in template tMyRec tpMyBigRec,
in template tField newFieldValue)
return tMyRec
{
tpMyBigRec.fields[3] := newFieldValue;
return tpMyBigRec;
}

/* Original proposal:

template tMyRec tpModRec
( template tField newFieldValue ) modifies tpMyBigRec :=
{
fields[3] := newFieldValue
}
*/

Technical comment: your proposal to use the following:

template tMyRec tpMyBigRec :=
{
fields := buildfields( 256 )
};

may in general deteriorate execution performance of your test script
unless you have a very good optimizing translator. Here is one reason
why this could happen:

Consider more general case:

template tMyRec tpMyBigRec(integer par) :=
{
fields := buildfields( 256, par )
};

and somewhere in your test case:

alt
{
...
[] port1.receive(tpMyBigRec(myLocalVar)) { ... }
}

That could for example mean that 'buildfields()' function is called
every time when the snapshot is evaluated, or at least every time when
this alt branch is reached in the test script in order to correctly
evaluate the template.

An alternative solution could be defining a 'var template' kind of
variable in the test component with the default initial value that
is evaluated only once when the component instance is created:

type component ComponentType
{
var [template] tMyRec tpMyBigRec :=
{
fields := buildfields( 256 )
};
}

Regards,
Alexey Mednonogov
OpenTTCN Oy

Cheung Ray-RCHEUNG1 wrote:

> Hi All,
>
> For 'record of' fields within records, I have a couple of questions.
> Consider simply:
>
>
> type record tField
> {
> integer a,
> integer b
> };
>
> template tField tpField ( template integer x, template integer y ) :=
> {
> a := x,
> b := y
> };
>
> type record of tField tRecOfFields;
>
> type record tMyRec
> {
> tRecOfFields fields
> };
>
>
>
> Problem 1: Supposing I need to set up a template tMyRecord with 256
> elements in 'fields' in a regular pattern, is there a way of setting
> up these elements except for doing it the long handed way below
> (ideally, I'd like to be able to use some sort of 'for' loop)?
>
>
> template tMyRec tpMyBigRec :=
> {
> {
> tpField(1,?),
> tpField(?,2),
> tpField(3,?),
> tpField(?,4),
> ...,
> tpField(255,?),
> tpField(?,256),
> }
> };
>
>
>
> Problem 2: Supposing I want to only to modify the 4th element of
> 'fields', is there a way of doing this using the 'modifies' construct
> without having to specify all the other 255 elements again?
>
>
> I think the answer to these questions is no. I have a couple of
> tentative solutions. I'd be interested to know what people think.
>
>
> Possible Solution to Problem 1: Allow 'template variables' and
> functions returning templates (I think this could potentially be quite
> a powerful feature). E.g.
>
>
> function buildFields ( integer maxElements ) return template
> tRecOfFields
> {
> var template tField field;
> var template tRecOfFields fields;
> var integer idx;
>
> for ( idx := 1 ; idx <= maxElements ; idx := idx + 1 )
> {
> if ( ( idx mod 2 ) == 1 ) { field := { idx, ? }; } else {
> field := { ?, idx }; }
> fields[idx-1] := field;
> }
> return fields;
> }
>
> template tMyRec tpMyBigRec :=
> {
> fields := buildfields( 256 )
> };
>
>
> Possible Solution to Problem 2: Permit indexing of 'record of' types
> (and anything else that can be indexed) in 'modifies' specification:
>
>
> template tMyRec tpModRec ( template tField newFieldValue )
> modifies tpMyBigRec :=
> {
> fields[3] := newFieldValue
> // of course, for nested indexable types, I'd expect to be
> able to do this:
> // fields[3] :=
> // {
> // ...
> // indexableFields[5] := newValueA,
> // ...
> // nonIndexableField := newValueB
> // ..., etc
> // }
> };
>
>
>
> Regards
>
>
> Ray Cheung
>
>
> Motorola GTSS
> Swindon
> UK
>
>
>
>
>
>

Dear Ray, dear Alexey,

there have been already CRs on template returning functions, local
templates and template variables - these CRs are currently under
discussion. We will also consider your proposals.

Cheers, Ina.

Alexey Mednonogov wrote:

> Hi Ray,
>
> Personally I like your idea of template variables. Note that some
> tools may already allow you to mix explicit value notation and
> matching mechanisms in quite a free form fashion in expressions,
> variable assignments, function parameters etc., thus implicitly
> supporting 'var template' kind of modifier.
>
> Note that your 'var template' idea could also solve your problem
> #2 without the need to introduce any new features into 'modifies'
> clause.
>
> Potential solution to problem #2 (assuming that functions can
> return templates and relaxed rules to variable assignments
> apply):
>
> function tpModRec(
> in template tMyRec tpMyBigRec,
> in template tField newFieldValue)
> return tMyRec
> {
> tpMyBigRec.fields[3] := newFieldValue;
> return tpMyBigRec;
> }
>
> /* Original proposal:
>
> template tMyRec tpModRec
> ( template tField newFieldValue ) modifies tpMyBigRec :=
> {
> fields[3] := newFieldValue
> }
> */
>
> Technical comment: your proposal to use the following:
>
> template tMyRec tpMyBigRec :=
> {
> fields := buildfields( 256 )
> };
>
> may in general deteriorate execution performance of your test script
> unless you have a very good optimizing translator. Here is one reason
> why this could happen:
>
> Consider more general case:
>
> template tMyRec tpMyBigRec(integer par) :=
> {
> fields := buildfields( 256, par )
> };
>
> and somewhere in your test case:
>
> alt
> {
> ...
> [] port1.receive(tpMyBigRec(myLocalVar)) { ... }
> }
>
> That could for example mean that 'buildfields()' function is called
> every time when the snapshot is evaluated, or at least every time when
> this alt branch is reached in the test script in order to correctly
> evaluate the template.
>
> An alternative solution could be defining a 'var template' kind of
> variable in the test component with the default initial value that
> is evaluated only once when the component instance is created:
>
> type component ComponentType
> {
> var [template] tMyRec tpMyBigRec :=
> {
> fields := buildfields( 256 )
> };
> }
>
> Regards,
> Alexey Mednonogov
> OpenTTCN Oy
>
> Cheung Ray-RCHEUNG1 wrote:
>
>> Hi All,
>>
>> For 'record of' fields within records, I have a couple of questions.
>> Consider simply:
>>
>>
>> type record tField
>> {
>> integer a,
>> integer b
>> };
>>
>> template tField tpField ( template integer x, template integer y ) :=
>> {
>> a := x,
>> b := y
>> };
>>
>> type record of tField tRecOfFields;
>>
>> type record tMyRec
>> {
>> tRecOfFields fields
>> };
>>
>>
>>
>> Problem 1: Supposing I need to set up a template tMyRecord with 256
>> elements in 'fields' in a regular pattern, is there a way of setting
>> up these elements except for doing it the long handed way below
>> (ideally, I'd like to be able to use some sort of 'for' loop)?
>>
>>
>> template tMyRec tpMyBigRec :=
>> {
>> {
>> tpField(1,?),
>> tpField(?,2),
>> tpField(3,?),
>> tpField(?,4),
>> ...,
>> tpField(255,?),
>> tpField(?,256),
>> }
>> };
>>
>>
>>
>> Problem 2: Supposing I want to only to modify the 4th element of
>> 'fields', is there a way of doing this using the 'modifies' construct
>> without having to specify all the other 255 elements again?
>>
>>
>> I think the answer to these questions is no. I have a couple of
>> tentative solutions. I'd be interested to know what people think.
>>
>>
>> Possible Solution to Problem 1: Allow 'template variables' and
>> functions returning templates (I think this could potentially be quite
>> a powerful feature). E.g.
>>
>>
>> function buildFields ( integer maxElements ) return template
>> tRecOfFields
>> {
>> var template tField field;
>> var template tRecOfFields fields;
>> var integer idx;
>>
>> for ( idx := 1 ; idx <= maxElements ; idx := idx + 1 )
>> {
>> if ( ( idx mod 2 ) == 1 ) { field := { idx, ? }; } else {
>> field := { ?, idx }; }
>> fields[idx-1] := field;
>> }
>> return fields;
>> }
>>
>> template tMyRec tpMyBigRec :=
>> {
>> fields := buildfields( 256 )
>> };
>>
>>
>> Possible Solution to Problem 2: Permit indexing of 'record of' types
>> (and anything else that can be indexed) in 'modifies' specification:
>>
>>
>> template tMyRec tpModRec ( template tField newFieldValue )
>> modifies tpMyBigRec :=
>> {
>> fields[3] := newFieldValue
>> // of course, for nested indexable types, I'd expect to be
>> able to do this:
>> // fields[3] :=
>> // {
>> // ...
>> // indexableFields[5] := newValueA,
>> // ...
>> // nonIndexableField := newValueB
>> // ..., etc
>> // }
>> };
>>
>>
>>
>> Regards
>>
>>
>> Ray Cheung
>>
>>
>> Motorola GTSS
>> Swindon
>> UK
>>
>>
>>
>>
>>
>>
>

--

---

Ina Schieferdecker url: www.fokus.fraunhofer.de/tip
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 Ina and Alexey,

Thanks for the feedback.

Ina, if it's not too much trouble, please could you let me know which CRs deal
with template variables and functions? Thanks.

Thanks, Alexey, for pointing out that it is possible to use solution #1 also as
solution for problem #2. I think the issue about performance and your proposed
component template variable is a good one. I thought bit more about your
suggestions, but I think there're a couple of drawbacks that make solution #2
still worthy of considration by the powers that be:

- Transparency - using the modifies construct is a lot more transparent defining
a function, You know which template you are modifying, but with the function,
you only know that you are modifying a template of the desired type. Of course,
one could argue that the function solution is therefore more flexible.

- Extra names and statements - you need a name for the function and you also
need a name for the modified template, you need to assign the function to the
modified template, and a minor point, you also need to declare the formal
parameters and pass the actual parameters, i.e.:

template tBase myBaseTemplate := { ... }

function funcThatModifiesTheBaseTemplates ( in template tBase tpBase, in
template field, ... )
return template tBase
{
...
}

template tBase tpModifiedBase := funcThatModifiesTheBaseTemplates(
myBaseTemplate, myField, ... );


As you say, solution #1 is capable of doing the job. It's just a case that
having solution #2 may make things things clearer and more concise.



Regards

Ray

---

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 Ina Schieferdecker
Sent: 15 March 2004 12:59
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Create/Modify 'record of' fields in templates.


Dear Ray, dear Alexey,

there have been already CRs on template returning functions, local templates and
template variables - these CRs are currently under discussion. We will also
consider your proposals.

Cheers, Ina.

Alexey Mednonogov wrote:

> Hi Ray,
>
> Personally I like your idea of template variables. Note that some
> tools may already allow you to mix explicit value notation and
> matching mechanisms in quite a free form fashion in expressions,
> variable assignments, function parameters etc., thus implicitly
> supporting 'var template' kind of modifier.
>
> Note that your 'var template' idea could also solve your problem #2
> without the need to introduce any new features into 'modifies' clause.
>
> Potential solution to problem #2 (assuming that functions can return
> templates and relaxed rules to variable assignments
> apply):
>
> function tpModRec(
> in template tMyRec tpMyBigRec,
> in template tField newFieldValue)
> return tMyRec
> {
> tpMyBigRec.fields[3] := newFieldValue;
> return tpMyBigRec;
> }
>
> /* Original proposal:
>
> template tMyRec tpModRec
> ( template tField newFieldValue ) modifies tpMyBigRec :=
> {
> fields[3] := newFieldValue
> }
> */
>
> Technical comment: your proposal to use the following:
>
> template tMyRec tpMyBigRec :=
> {
> fields := buildfields( 256 )
> };
>
> may in general deteriorate execution performance of your test script
> unless you have a very good optimizing translator. Here is one reason
> why this could happen:
>
> Consider more general case:
>
> template tMyRec tpMyBigRec(integer par) :=
> {
> fields := buildfields( 256, par )
> };
>
> and somewhere in your test case:
>
> alt
> {
> ...
> [] port1.receive(tpMyBigRec(myLocalVar)) { ... }
> }
>
> That could for example mean that 'buildfields()' function is called
> every time when the snapshot is evaluated, or at least every time when
> this alt branch is reached in the test script in order to correctly
> evaluate the template.
>
> An alternative solution could be defining a 'var template' kind of
> variable in the test component with the default initial value that is
> evaluated only once when the component instance is created:
>
> type component ComponentType
> {
> var [template] tMyRec tpMyBigRec :=
> {
> fields := buildfields( 256 )
> };
> }
>
> Regards,
> Alexey Mednonogov
> OpenTTCN Oy
>
> Cheung Ray-RCHEUNG1 wrote:
>
>> Hi All,
>>
>> For 'record of' fields within records, I have a couple of questions.
>> Consider simply:
>>
>>
>> type record tField
>> {
>> integer a,
>> integer b
>> };
>>
>> template tField tpField ( template integer x, template integer y ) :=
>> {
>> a := x,
>> b := y
>> };
>>
>> type record of tField tRecOfFields;
>>
>> type record tMyRec
>> {
>> tRecOfFields fields
>> };
>>
>>
>>
>> Problem 1: Supposing I need to set up a template tMyRecord with 256
>> elements in 'fields' in a regular pattern, is there a way of setting
>> up these elements except for doing it the long handed way below
>> (ideally, I'd like to be able to use some sort of 'for' loop)?
>>
>>
>> template tMyRec tpMyBigRec :=
>> {
>> {
>> tpField(1,?),
>> tpField(?,2),
>> tpField(3,?),
>> tpField(?,4),
>> ...,
>> tpField(255,?),
>> tpField(?,256),
>> }
>> };
>>
>>
>>
>> Problem 2: Supposing I want to only to modify the 4th element of
>> 'fields', is there a way of doing this using the 'modifies' construct
>> without having to specify all the other 255 elements again?
>>
>>
>> I think the answer to these questions is no. I have a couple of
>> tentative solutions. I'd be interested to know what people think.
>>
>>
>> Possible Solution to Problem 1: Allow 'template variables' and
>> functions returning templates (I think this could potentially be
>> quite a powerful feature). E.g.
>>
>>
>> function buildFields ( integer maxElements ) return template
>> tRecOfFields
>> {
>> var template tField field;
>> var template tRecOfFields fields;
>> var integer idx;
>>
>> for ( idx := 1 ; idx <= maxElements ; idx := idx + 1 )
>> {
>> if ( ( idx mod 2 ) == 1 ) { field := { idx, ? }; } else {
>> field := { ?, idx }; }
>> fields[idx-1] := field;
>> }
>> return fields;
>> }
>>
>> template tMyRec tpMyBigRec :=
>> {
>> fields := buildfields( 256 )
>> };
>>
>>
>> Possible Solution to Problem 2: Permit indexing of 'record of' types
>> (and anything else that can be indexed) in 'modifies' specification:
>>
>>
>> template tMyRec tpModRec ( template tField newFieldValue )
>> modifies tpMyBigRec :=
>> {
>> fields[3] := newFieldValue
>> // of course, for nested indexable types, I'd expect to be
>> able to do this:
>> // fields[3] :=
>> // {
>> // ...
>> // indexableFields[5] := newValueA,
>> // ...
>> // nonIndexableField := newValueB
>> // ..., etc
>> // }
>> };
>>
>>
>>
>> Regards
>>
>>
>> Ray Cheung
>>
>>
>> Motorola GTSS
>> Swindon
>> UK
>>
>>
>>
>>
>>
>>
>

--

---

Ina Schieferdecker url: www.fokus.fraunhofer.de/tip
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

---