Hello all,
locally defined templates (e.g. inside a function) yield some special
situations:
in contradiction to global templates there might be component variables
or local defined variables (or var templates) used for assignment to the
template or its fields.
As well these templates can have parameters.

There is nowhere specified when the assignment of the local/component
vars to the template takes place:
1. during template definition
2. during template invocation

I visualise this in an example:

type record R {
integer f1,
boolean f2
}

function sum(inout integer p1, in integer p2) return integer {
p1 = p1 +p2;
return p1;
}

function f1() {
var integer i1 := 10;
var integer i2 := 20;

template R t_r(integer p_i) := {
f1 := sum(i1, p_i), // normally I would expect
this function being evaluated during this definition,
// but by using
p_i this would need to be postponed till template invocation
f2 := true
}
log(i1); // what is the value of i1?
i1 := 20; // will this change the content of f1 from within t_r?
log(i1); // i1 yields 20
log(match({30, true}, t_r(i2))); // will this match?
log(i1); // what is the value of i1: 40 or 30?
}

for functions it is specified that inout parameters are not allowed if
the function is invoked from within a snapshot, but nothing is specified
for their usage while initialising template fields.

I'm looking forward for some advises what the expected behaviour should be.


BR.,
Uwe

Hello,

In my opinion the variables are/should be evaluated when the right hand
side of the template definition is evaluated, which is at the point
during execution when the template instance shall be evaluated, i.e.
when it is used. Basically, all variables known in the context of the
template definition are simply implicit additional parameters to the
local template definition.

Therefore, match({30, true}, t_r(i2)} == match({30, true}, {sum(i1,
p_i), true}) == match({30, true}, {20+20, true}) == false.

Afterwareds, the variable i1 will have the value 40 (= i1+p_i = 20+20).

Any other implementation/interpretation would run into problems as there
could be sub-expressions referencing both variables and parameters which
can only be evaluated at instantiation-time, but not at definition time
(as you've already discovered in your example).

BR, Jacob Wieland

Hello Jacob,
thank you for your quick reply. Your proposal sounds reasonable, though
in such cases a warning to the ttcn-3 user (at compile time) would be
more than adequate to inform him that the local variable changed its
value(if this really happens) in-between its usage inside the template
definition and the invocation of the template. Otherwise the user might
be astonished about the outcome.
Moreover I would like to see your statement inside the standard :-)

BR.,
Uwe

Hello Uwe,

You're right. This is not explicitly stated in the standard. In infer
this for consistency's sake from the following paragraph in 15.3.

At the time of their use (e.g. in communication operations *send*,
*receive*, *call*, *getcall,* etc.), it is allowed to change template
fields by in-line modified templates, to pass in values via value
parameters as well as to pass in templates via template parameters. The
effects of these changes on the values of the template fields do not
persist in the template subsequent to the corresponding communication event.

Basically, for me, referencing a variable inside the template expression
is the same as passing it in as an implicit inout-parameter.

Of course, there is a difference to the case of non-parameterized
templates which can already be evaluated at definition time. Here, it
could be debated whether also the evaluation of the instance should be
deferred to the usage-time instead like for parameterized ones (which
would also lead to a different template every time the variable values
changed). But, templates without parameters are pretty much like
const-definitions and for const it does not make sense to defer the
evaluation of the right-hand-side until its usage (as that would negate
the const-ness in case the const refers to a variable on its right hand
side). Basically, a parameterized template is also a const-like
definition, but it only defines the (unchangeable) rule for
instantiation when given a set of parameters, i.e. at usage-time.

I agree, that in principle, the standard should be augmented to be more
explicit for these cases.

BR, Jacob Wieland