Hi,

there is a major problem with the current IMPORT statement and I would
welcome your opinion as to how
this should be resolved.

The issue is this that the current solution resolves the module parameters
for the module that is being imported from,
as a parameter list on the import statement e.g.

import all function from ModuleB( Par1:= 7, Par2:=8, Par3:=9)

Now this is sort of ok in isolation but as a number of you have noted (error
reports from Ericsson and Telelogic)
with multiple import statements associated with the same module we then hit
problems e.g.

import all function from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
import all testcase from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
import all teststep from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
import all template from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
import all constant from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
import type type1, type2, type3, type 4 from ModuleB( Par1:= 7,
Par2:=8, Par3:=9)

In this case for every import statement we have to potentially define the
same parameters n times, but the real issue is
can we define different vales for the same module parameter on different
lines? If yes we get into horrible problems with
types & subtypes no longer being compatible and in the case that the same
definition is imported more than once the
way the tool resolves the issue would determine the value!!!!

The real issue is that the module parameters are associated with the module
not any one particular definition within the
module so defining the module parameters directly in each import statement
is conceptually wrong.

With this in mind STF187 propose a refinement of the import statement. In
this refinement we try to associate the module
parameters with the module and then associate one or more elements to import
from this module e.g.

import from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
{
all function; all testcase; all teststep; //
as in port def etc the semi colons are optional
all template; all constant;
type type1, type2, type3, type 4;
}

Note: import all from a module would become:

import from ModuleB( Par1:= 7, Par2:=8, Par3:=9) {all}


PLEASE: we now need your feedback as soon as possible. Although in actual
fact the syntax change in this proposal is little
more than a reordering of the existing statement parts it does solve the
problem of module parameterisation.
In order to change this however we would need a positive response from you,
the users and tool makers.

BR Colin.

Yes. Solves the problem and is more elegant. Go for it.

Regards

Derek

---

Derek C Lazenby
Anite
127 Fleet Road
Fleet
Hampshire
GU51 3QN
Tel : +44 1252 775200
Fax: +44 1252 775299

---

Anite Telecoms Limited Registered in England No. 1721900 Registered
Office: 100 Longwater Avenue, GreenPark, Reading, Berkshire RG2 6GP,
United Kingdom

---

Original Message

---

From: Colin Willcock [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 17 October 2001 10:44
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: A Problem with Imports
Importance: High


Hi,

there is a major problem with the current IMPORT statement and I would
welcome your opinion as to how
this should be resolved.

The issue is this that the current solution resolves the module parameters
for the module that is being imported from,
as a parameter list on the import statement e.g.

import all function from ModuleB( Par1:= 7, Par2:=8, Par3:=9)

Now this is sort of ok in isolation but as a number of you have noted (error
reports from Ericsson and Telelogic)
with multiple import statements associated with the same module we then hit
problems e.g.

import all function from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
import all testcase from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
import all teststep from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
import all template from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
import all constant from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
import type type1, type2, type3, type 4 from ModuleB( Par1:= 7,
Par2:=8, Par3:=9)

In this case for every import statement we have to potentially define the
same parameters n times, but the real issue is
can we define different vales for the same module parameter on different
lines? If yes we get into horrible problems with
types & subtypes no longer being compatible and in the case that the same
definition is imported more than once the
way the tool resolves the issue would determine the value!!!!

The real issue is that the module parameters are associated with the module
not any one particular definition within the
module so defining the module parameters directly in each import statement
is conceptually wrong.

With this in mind STF187 propose a refinement of the import statement. In
this refinement we try to associate the module
parameters with the module and then associate one or more elements to import
from this module e.g.

import from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
{
all function; all testcase; all teststep; //
as in port def etc the semi colons are optional
all template; all constant;
type type1, type2, type3, type 4;
}

Note: import all from a module would become:

import from ModuleB( Par1:= 7, Par2:=8, Par3:=9) {all}


PLEASE: we now need your feedback as soon as possible. Although in actual
fact the syntax change in this proposal is little
more than a reordering of the existing statement parts it does solve the
problem of module parameterisation.
In order to change this however we would need a positive response from you,
the users and tool makers.

BR Colin.

Hi Colin,

just for clarification: you mean that such an import statement would be
allowed only once, i.e.

import from ModuleB( Par1:= 7, Par2:=8, Par3:=9) {all}
import from ModuleB( Par1:= 1, Par2:=2, Par3:=3) {all}

would be forbidden?

Still, I think that it does not solve the possibility to import the same
definition with different parameters into an importing module. Just an example
of two modules using each a type from a third module. Please ignore the
syntax, I haven't checked it:

module A(integer x) {
import MyType from C(y := x);
type record Arec {
MyType field1;
boolean field2;
}
:
}

module B(integer x) {
import MyType from C(y := x);
type record Brec {
MyType field1;
integer field2;
}
:
}

module C(integer y) {
type integer MyType[y];
:
}

module MyImportingModule {
import from A(x:=1) { Arec, MyType } ; //with the recursive import that
import from B(x:=2) { Brec, MyType } ; //would even not be that obvious
:
}

One possible solution was discussed in Berlin (but not to the final end):
explicitly refer to module instances, i.e. parameterized modules. In that case
we could have

moduletype MyA:= A(x:=1);
moduletype MyB:= B(x:=2);

import Arec,MyType from MyA;
import Brec,MyType from MyB;

Then, you could unambiguously refer to the two different instances of MyType:
MyA.MyType and MyB.MyType


With best regards,

Ina.


> Hi,
>
> there is a major problem with the current IMPORT statement and I would
> welcome your opinion as to how
> this should be resolved.
>
> The issue is this that the current solution resolves the module parameters
> for the module that is being imported from,
> as a parameter list on the import statement e.g.
>
> import all function from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
>
> Now this is sort of ok in isolation but as a number of you have noted (error
> reports from Ericsson and Telelogic)
> with multiple import statements associated with the same module we then hit
> problems e.g.
>
> import all function from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> import all testcase from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> import all teststep from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> import all template from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> import all constant from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> import type type1, type2, type3, type 4 from ModuleB( Par1:= 7,
> Par2:=8, Par3:=9)
>
> In this case for every import statement we have to potentially define the
> same parameters n times, but the real issue is
> can we define different vales for the same module parameter on different
> lines? If yes we get into horrible problems with
> types & subtypes no longer being compatible and in the case that the same
> definition is imported more than once the
> way the tool resolves the issue would determine the value!!!!
>
> The real issue is that the module parameters are associated with the module
> not any one particular definition within the
> module so defining the module parameters directly in each import statement
> is conceptually wrong.
>
> With this in mind STF187 propose a refinement of the import statement. In
> this refinement we try to associate the module
> parameters with the module and then associate one or more elements to import
> from this module e.g.
>
> import from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> {
> all function; all testcase; all teststep; //
> as in port def etc the semi colons are optional
> all template; all constant;
> type type1, type2, type3, type 4;
> }
>
> Note: import all from a module would become:
>
> import from ModuleB( Par1:= 7, Par2:=8, Par3:=9) {all}
>
>
> PLEASE: we now need your feedback as soon as possible. Although in actual
> fact the syntax change in this proposal is little
> more than a reordering of the existing statement parts it does solve the
> problem of module parameterisation.
> In order to change this however we would need a positive response from you,
> the users and tool makers.
>
> BR Colin.

Hi Colin,

This problem was originally detected by Ericsson (actually, by me) a
couple of weeks ago. I also proposed a solution for it, which does not
require any changes on the BNF.

I just paste a quotation from the original comment list:

---

- Imports & module parameters: the proposed solution is unclean.

An example:

module A (integer N)
{

type component mycomp {
var integer myvar[N];
...
}

function set_myvar_to_zero() runs on mycomp
{
var integer i;
for (i := 0; i < N; i := i+1){
myvar := 0;
}
}

function set_myvar_to_one() runs on mycomp
{
var integer i;
for (i := 0; i < N; i := i+1){
myvar := 1;
}
}

// I think this module is consistent as a whole.

}

module B(integer par1, charstring N)
{
import function set_myvar_to_zero from A(5);
import function set_myvar_to_one from A(10);

// mycomp will be recursively imported -> how will it look like?
// will be there two mycomp's?
// how the two imported functions will work?
}

Proposed solution:

- the ETS consists of a set of TTCN-3 modules
- the parameters of ETS shall be the union of parameters of its modules
- actual parameters must not be given in import statements
- the parameters of all modules shall be unambiguously given by the user
(e.g. in one or more configuration file)
- the test executor shall distribute the parameters among the modules
automatically (even in case of parameter name clashes)
- the interpretation of default parameters is trivial

Example configuration file:

[PARAMETERS]

A.N := 5;
B.par1 := 1;
B.N := "Tinky-Winky";

Moreover, the example in the proposal shows a bad coding style:

- if the behaviour of a function or the pattern of a template depends on
one or more parameters, these parameters shall be directly given to the
function or template and not as module parameters

---

I wonder what is your (and list members') opinion about this solution.

Regards,
Zoltan


> there is a major problem with the current IMPORT statement and I would
> welcome your opinion as to how
> this should be resolved.
>
> The issue is this that the current solution resolves the module parameters
> for the module that is being imported from,
> as a parameter list on the import statement e.g.
>
> import all function from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
>

--
János Zoltán Szabó [ETH/RL/S] This email address is being protected from spambots. You need JavaScript enabled to view it.
Tel.: +36-1-437-7635, Fax: +36-1-437-7767
Ericsson Telecommunications Ltd., 1037 Budapest, Laborc u. 1., Hungary

Dear János, dear all,

I don't like the solution that János proposes here, even though it would
not require to change the BNF. I consider requiring the existence of a
separate configuration file in addition to the TTCN-3 module as an
un-intuitive and in-elegant solution, which is also rather error prone.
All necessary information should be present in the TTCN-3 files, even
this this requires changing the BNF.

On the other hand, I also see the problems that Ina has raised in her
mail.

A quick and dirty solution would be to leave everything like it is and
to require that, if a module is imported more than once, then it must be
imported with a the same set of parameters. I think that this would
eliminate all problems, even though I also do not consider it as
particularly elegant.

Also, it might be a good idea to pair the new syntax, which helps
obeying that requirement by being able to group imports from the same
module, with the requirement. This would rule out the problems as Ina
has described them.

Best regards

Stephan Tobies

--
Stephan Tobies 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
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany

>

---

Original Message

---

> From: ext János Zoltán Szabó [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Wednesday, October 17, 2001 12:57 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: A Problem with Imports
>
>
> Hi Colin,
>
> This problem was originally detected by Ericsson (actually, by me) a
> couple of weeks ago. I also proposed a solution for it, which does not
> require any changes on the BNF.
>
> I just paste a quotation from the original comment list:
>

---

>

---

>
> - Imports & module parameters: the proposed solution is unclean.
>
> An example:
>
> module A (integer N)
> {
>
> type component mycomp {
> var integer myvar[N];
> ...
> }
>
> function set_myvar_to_zero() runs on mycomp
> {
> var integer i;
> for (i := 0; i < N; i := i+1){
> myvar := 0;
> }
> }
>
> function set_myvar_to_one() runs on mycomp
> {
> var integer i;
> for (i := 0; i < N; i := i+1){
> myvar := 1;
> }
> }
>
> // I think this module is consistent as a whole.
>
> }
>
> module B(integer par1, charstring N)
> {
> import function set_myvar_to_zero from A(5);
> import function set_myvar_to_one from A(10);
>
> // mycomp will be recursively imported -> how will it look like?
> // will be there two mycomp's?
> // how the two imported functions will work?
> }
>
> Proposed solution:
>
> - the ETS consists of a set of TTCN-3 modules
> - the parameters of ETS shall be the union of parameters of
> its modules
> - actual parameters must not be given in import statements
> - the parameters of all modules shall be unambiguously given
> by the user
> (e.g. in one or more configuration file)
> - the test executor shall distribute the parameters among the modules
> automatically (even in case of parameter name clashes)
> - the interpretation of default parameters is trivial
>
> Example configuration file:
>
> [PARAMETERS]
>
> A.N := 5;
> B.par1 := 1;
> B.N := "Tinky-Winky";
>
> Moreover, the example in the proposal shows a bad coding style:
>
> - if the behaviour of a function or the pattern of a template
> depends on
> one or more parameters, these parameters shall be directly
> given to the
> function or template and not as module parameters
>
>

---

>

---

>
> I wonder what is your (and list members') opinion about this solution.
>
> Regards,
> Zoltan
>
>
> > there is a major problem with the current IMPORT statement
> and I would
> > welcome your opinion as to how
> > this should be resolved.
> >
> > The issue is this that the current solution resolves the
> module parameters
> > for the module that is being imported from,
> > as a parameter list on the import statement e.g.
> >
> > import all function from ModuleB( Par1:= 7,
> Par2:=8, Par3:=9)
> >
>
> --
> János Zoltán Szabó [ETH/RL/S] This email address is being protected from spambots. You need JavaScript enabled to view it.
> Tel.: +36-1-437-7635, Fax: +36-1-437-7767
> Ericsson Telecommunications Ltd., 1037 Budapest, Laborc u. 1., Hungary
>

Dear Stephen,

> I don't like the solution that János proposes here, even though it would
> not require to change the BNF. I consider requiring the existence of a
> separate configuration file in addition to the TTCN-3 module as an
> un-intuitive and in-elegant solution, which is also rather error prone.
> All necessary information should be present in the TTCN-3 files, even
> this this requires changing the BNF.

I think you have missed the point. The only requirement that I assume
that the TTCN-3 Test System (test executor) must resolve and propagate
the parameters of all participating TTCN-3 modules. In the original
approach, all parameters belong to one (root) TTCN-3 module.

The configuration file that I showed was one possible implementation of
this. If you prefer GUIs, you can think on a window with tabs and
sub-windows, where each of them contains the parameters of one module.

Nevertheless, the module parameters must be set anyhow in the Test
System implementation (regardless we think of one module or more
modules). Their purpose is to set configuration information, physical
addresses, etc. (which change frequently during test execution) outside
the ATS in order to keep the ATS unchanged during the entire test
campaign (see also PIXIT in TTCN-2). If you want to archive your
settings, a configuration file, I think, is an ideal solution :-).

> A quick and dirty solution would be to leave everything like it is and
> to require that, if a module is imported more than once, then it must be
> imported with a the same set of parameters. I think that this would
> eliminate all problems, even though I also do not consider it as
> particularly elegant.

A quicker and less dirty solution would be to prohibit importing from
parameterized modules... :-)

Another argument for my solution is the reusability of TTCN-3 modules
e.g. for integration testing.
For example, if you want to integrate a HTTP and a DSS.1 TTCN-3 module
into one ETS, the IP address of the web server and the number of A
subscriber should be handled independently, but simultaneously by the
Test System Implementation.

Regards,
Zoltan

--
János Zoltán Szabó [ETH/RL/S] This email address is being protected from spambots. You need JavaScript enabled to view it.
Tel.: +36-1-437-7635, Fax: +36-1-437-7767
Ericsson Telecommunications Ltd., 1037 Budapest, Laborc u. 1., Hungary

Hi Ina,

sorry for not clarifying the first point. Yes it is allowed to have multiple
import statements
associated with one module but the module parameters specified must be
consistent in
terms of value. Therefore what you have written is not allowed but:

import from ModuleB( Par1:= 7, Par2:=8, Par3:=9) {all}
import from ModuleB( Par1:= 7, Par2:=8, Par3:=9) {all}

is ok (although not very useful!)

As to you proposed problem well such an example is anyway not allowed (as is
stated
in the standard section 7.5: Import statements are not considered module
definitions.
This means, a definition can only be imported from its source module and not
via
chains of import statements from further modules)
the MyType from Module C must be explicitly imported within MyImporting
module

BR Colin.

---

Original Message

---

From: I. Schieferdecker [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 17 October 2001 12:40
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: A Problem with Imports


Hi Colin,

just for clarification: you mean that such an import statement would be
allowed only once, i.e.

import from ModuleB( Par1:= 7, Par2:=8, Par3:=9) {all}
import from ModuleB( Par1:= 1, Par2:=2, Par3:=3) {all}

would be forbidden?

Still, I think that it does not solve the possibility to import the same
definition with different parameters into an importing module. Just an
example
of two modules using each a type from a third module. Please ignore the
syntax, I haven't checked it:

module A(integer x) {
import MyType from C(y := x);
type record Arec {
MyType field1;
boolean field2;
}
:
}

module B(integer x) {
import MyType from C(y := x);
type record Brec {
MyType field1;
integer field2;
}
:
}

module C(integer y) {
type integer MyType[y];
:
}

module MyImportingModule {
import from A(x:=1) { Arec, MyType } ; //with the recursive import that
import from B(x:=2) { Brec, MyType } ; //would even not be that obvious
:
}

One possible solution was discussed in Berlin (but not to the final end):
explicitly refer to module instances, i.e. parameterized modules. In that
case
we could have

moduletype MyA:= A(x:=1);
moduletype MyB:= B(x:=2);

import Arec,MyType from MyA;
import Brec,MyType from MyB;

Then, you could unambiguously refer to the two different instances of
MyType:
MyA.MyType and MyB.MyType


With best regards,

Ina.


> Hi,
>
> there is a major problem with the current IMPORT statement and I would
> welcome your opinion as to how
> this should be resolved.
>
> The issue is this that the current solution resolves the module parameters
> for the module that is being imported from,
> as a parameter list on the import statement e.g.
>
> import all function from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
>
> Now this is sort of ok in isolation but as a number of you have noted
(error
> reports from Ericsson and Telelogic)
> with multiple import statements associated with the same module we then
hit
> problems e.g.
>
> import all function from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> import all testcase from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> import all teststep from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> import all template from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> import all constant from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> import type type1, type2, type3, type 4 from ModuleB( Par1:= 7,
> Par2:=8, Par3:=9)
>
> In this case for every import statement we have to potentially define the
> same parameters n times, but the real issue is
> can we define different vales for the same module parameter on different
> lines? If yes we get into horrible problems with
> types & subtypes no longer being compatible and in the case that the same
> definition is imported more than once the
> way the tool resolves the issue would determine the value!!!!
>
> The real issue is that the module parameters are associated with the
module
> not any one particular definition within the
> module so defining the module parameters directly in each import statement
> is conceptually wrong.
>
> With this in mind STF187 propose a refinement of the import statement. In
> this refinement we try to associate the module
> parameters with the module and then associate one or more elements to
import
> from this module e.g.
>
> import from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> {
> all function; all testcase; all teststep; //
> as in port def etc the semi colons are optional
> all template; all constant;
> type type1, type2, type3, type 4;
> }
>
> Note: import all from a module would become:
>
> import from ModuleB( Par1:= 7, Par2:=8, Par3:=9) {all}
>
>
> PLEASE: we now need your feedback as soon as possible. Although in actual
> fact the syntax change in this proposal is little
> more than a reordering of the existing statement parts it does solve the
> problem of module parameterisation.
> In order to change this however we would need a positive response from
you,
> the users and tool makers.
>
> BR Colin.

Hi Zoltan,

first perhaps I should point out for fairness that this problem
was identified by a number of sources not just Ericsson.

Now to your interesting proposal. Well it was certainly considered
by STF187 but a number of issues were identified which lead to a different
favoured solution.

The issues identified were:

1) The Ericsson proposal uses a superset of all the module parameters of all
modules used in the ETS. In the case where I just wish to import a single
definition
from a module this is going to lead to a very large list of module
parameters being
generated of which maybe only 1% are necessary to specify a value for (what
I want is
the subset of module parameters I need not the superset of all possible).
And there is the
second problem which 1%? In the STF187 proposed solution the required module
parameters
for the testsuite are specified and checked within the TTCN-3 at compile
time. In the Ericsson proposal
you have to wait till run-time to see if you have forgotten anything.

2) The Ericsson proposal does not support the use of constants or
expressions from within the imported
module being used for module parameters for the imported definitions.

3) The Ericsson proposal makes porting of a testsuite from one tool to
another potentially more difficult
because the module parameter file now has tool specific ways of magically
distributing module
parameters to the various modules.

4) Critically I find that conceptually the implicit assumption that all
modules in the ETS are equal
is incorrect. We have the idea of a single central module which is like the
main of c program and it should
be possible to resolve everything from this module (including a single
finite module parameter list)

I believe the Ericsson proposal is a clever and pragmatic stop-gap solution,
but I believe we need something
more definite and fully specified in the TTCN-3 language.

Lastly perhaps I should state that although in this case the Ericsson
proposal did not find favour within STF187
the Ericsson group has invested a lot of time and effort reporting problems
in a good documented form and the vast
majority of the suggestions are being implemented into the standard as we
speak. I would personally like to again thank
Ericsson for their hard work.

BR Colin.

---

Original Message

---

From: János Zoltán Szabó [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 17 October 2001 12:57
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: A Problem with Imports


Hi Colin,

This problem was originally detected by Ericsson (actually, by me) a
couple of weeks ago. I also proposed a solution for it, which does not
require any changes on the BNF.

I just paste a quotation from the original comment list:

---

---

- Imports & module parameters: the proposed solution is unclean.

An example:

module A (integer N)
{

type component mycomp {
var integer myvar[N];
...
}

function set_myvar_to_zero() runs on mycomp
{
var integer i;
for (i := 0; i < N; i := i+1){
myvar := 0;
}
}

function set_myvar_to_one() runs on mycomp
{
var integer i;
for (i := 0; i < N; i := i+1){
myvar := 1;
}
}

// I think this module is consistent as a whole.

}

module B(integer par1, charstring N)
{
import function set_myvar_to_zero from A(5);
import function set_myvar_to_one from A(10);

// mycomp will be recursively imported -> how will it look like?
// will be there two mycomp's?
// how the two imported functions will work?
}

Proposed solution:

- the ETS consists of a set of TTCN-3 modules
- the parameters of ETS shall be the union of parameters of its modules
- actual parameters must not be given in import statements
- the parameters of all modules shall be unambiguously given by the user
(e.g. in one or more configuration file)
- the test executor shall distribute the parameters among the modules
automatically (even in case of parameter name clashes)
- the interpretation of default parameters is trivial

Example configuration file:

[PARAMETERS]

A.N := 5;
B.par1 := 1;
B.N := "Tinky-Winky";

Moreover, the example in the proposal shows a bad coding style:

- if the behaviour of a function or the pattern of a template depends on
one or more parameters, these parameters shall be directly given to the
function or template and not as module parameters

---

---

I wonder what is your (and list members') opinion about this solution.

Regards,
Zoltan


> there is a major problem with the current IMPORT statement and I would
> welcome your opinion as to how
> this should be resolved.
>
> The issue is this that the current solution resolves the module parameters
> for the module that is being imported from,
> as a parameter list on the import statement e.g.
>
> import all function from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
>

--
János Zoltán Szabó [ETH/RL/S] This email address is being protected from spambots. You need JavaScript enabled to view it.
Tel.: +36-1-437-7635, Fax: +36-1-437-7767
Ericsson Telecommunications Ltd., 1037 Budapest, Laborc u. 1., Hungary

Hi again,

..snip..

>
> As to you proposed problem well such an example is anyway not allowed (as is
> stated
> in the standard section 7.5: Import statements are not considered module
> definitions.
> This means, a definition can only be imported from its source module and not
> via
> chains of import statements from further modules)
> the MyType from Module C must be explicitly imported within MyImporting
> module

what is then a recursive import?! In the example, I just wanted to make more
explicit what is going on with MyType.

In other words, with the recursive import you still have the problem: you have
two different MyTypes.

If not, please explain.

With best regards,

Ina.


>
>

---

Original Message

---

> From: I. Schieferdecker [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 17 October 2001 12:40
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: A Problem with Imports
>
>
> Hi Colin,
>
> just for clarification: you mean that such an import statement would be
> allowed only once, i.e.
>
> import from ModuleB( Par1:= 7, Par2:=8, Par3:=9) {all}
> import from ModuleB( Par1:= 1, Par2:=2, Par3:=3) {all}
>
> would be forbidden?
>
> Still, I think that it does not solve the possibility to import the same
> definition with different parameters into an importing module. Just an
> example
> of two modules using each a type from a third module. Please ignore the
> syntax, I haven't checked it:
>
> module A(integer x) {
> import MyType from C(y := x);
> type record Arec {
> MyType field1;
> boolean field2;
> }
> :
> }
>
> module B(integer x) {
> import MyType from C(y := x);
> type record Brec {
> MyType field1;
> integer field2;
> }
> :
> }
>
> module C(integer y) {
> type integer MyType[y];
> :
> }
>
> module MyImportingModule {
> import from A(x:=1) { Arec, MyType } ; //with the recursive import that
> import from B(x:=2) { Brec, MyType } ; //would even not be that obvious
> :
> }
>
> One possible solution was discussed in Berlin (but not to the final end):
> explicitly refer to module instances, i.e. parameterized modules. In that
> case
> we could have
>
> moduletype MyA:= A(x:=1);
> moduletype MyB:= B(x:=2);
>
> import Arec,MyType from MyA;
> import Brec,MyType from MyB;
>
> Then, you could unambiguously refer to the two different instances of
> MyType:
> MyA.MyType and MyB.MyType
>
>
> With best regards,
>
> Ina.
>
>
> > Hi,
> >
> > there is a major problem with the current IMPORT statement and I would
> > welcome your opinion as to how
> > this should be resolved.
> >
> > The issue is this that the current solution resolves the module parameters
> > for the module that is being imported from,
> > as a parameter list on the import statement e.g.
> >
> > import all function from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> >
> > Now this is sort of ok in isolation but as a number of you have noted
> (error
> > reports from Ericsson and Telelogic)
> > with multiple import statements associated with the same module we then
> hit
> > problems e.g.
> >
> > import all function from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> > import all testcase from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> > import all teststep from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> > import all template from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> > import all constant from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> > import type type1, type2, type3, type 4 from ModuleB( Par1:= 7,
> > Par2:=8, Par3:=9)
> >
> > In this case for every import statement we have to potentially define the
> > same parameters n times, but the real issue is
> > can we define different vales for the same module parameter on different
> > lines? If yes we get into horrible problems with
> > types & subtypes no longer being compatible and in the case that the same
> > definition is imported more than once the
> > way the tool resolves the issue would determine the value!!!!
> >
> > The real issue is that the module parameters are associated with the
> module
> > not any one particular definition within the
> > module so defining the module parameters directly in each import statement
> > is conceptually wrong.
> >
> > With this in mind STF187 propose a refinement of the import statement. In
> > this refinement we try to associate the module
> > parameters with the module and then associate one or more elements to
> import
> > from this module e.g.
> >
> > import from ModuleB( Par1:= 7, Par2:=8, Par3:=9)
> > {
> > all function; all testcase; all teststep; //
> > as in port def etc the semi colons are optional
> > all template; all constant;
> > type type1, type2, type3, type 4;
> > }
> >
> > Note: import all from a module would become:
> >
> > import from ModuleB( Par1:= 7, Par2:=8, Par3:=9) {all}
> >
> >
> > PLEASE: we now need your feedback as soon as possible. Although in actual
> > fact the syntax change in this proposal is little
> > more than a reordering of the existing statement parts it does solve the
> > problem of module parameterisation.
> > In order to change this however we would need a positive response from
> you,
> > the users and tool makers.
> >
> > BR Colin.

On Wed, 17 Oct 2001, Colin Willcock wrote:

> Hi Baltasar,
>
> I can see that your solution would work however it adds a whole new class of
> statement and
> indeed a new concept to the TTCN-3 language namely Alias. Since the subject
> of Alias's has
> already been discussed at length in the past and it was rejected I am
> loathed to add it in
> again.

Actually, the concept still exists in TTCN-3 for constants,
types and templates, so to introduce it also for module-instances
(which in essence are some sort of constant records)
would not really add something new.

> I would also question the desirability to allow using different values for
> same module
> parameter within separate import statements (note: this is not unique to
> your solution).
> Within a module each module parameter is defined to have one unique value
> which will be
> constant though the execution of a testcase. To me when I remotely need to
> specify a
> module parameter for a module I am importing from the same semantic should
> apply.

The proposed statement would instantiate the same module, but the
result would be two _different_ instances of the same module.

Otherwise, you would have to ensure that in the whole test system
(all directly and indirectly imported modules), all modules are
always instantiated with the same values (which can only be checked
statically, if those values have to be given literally and not, if
they can be given with external constants or things derived thereof).

If not, I can still do the following (old syntax) which you want
to be prevented by your proposal:

module A(integer i) {
type record of integer list;
}

module B {
import type list from A(1);
type A.list list;
}

module C {
import type list from A(2);
type A.list list;
}

module D {
import type list from B;
import type list from C;
// this is the same as writing:
// import type list from A(1);
// import type list from A(2);
}

Jacob Wieland, TU-Berlin

Hi Colin,

Colin Willcock wrote:
> sorry for not clarifying the first point. Yes it is allowed to have multiple
> import statements
> associated with one module but the module parameters specified must be
> consistent in
> terms of value. Therefore what you have written is not allowed but:
>
> import from ModuleB( Par1:= 7, Par2:=8, Par3:=9) {all}
> import from ModuleB( Par1:= 7, Par2:=8, Par3:=9) {all}
>
> is ok (although not very useful!)

I think your proposed solution is good. However, why do you want to
allow the above mentioned multiple import statements from the same
module? If you simply restrict it so you can only have one import
statement for each imported module, it will be very clear and simple. If
you want to allow this anyway, you could specify that only the first
import statement can have actual parameters.

Cheers,
Thomas

--

---

Thomas Wernitz - Head of Development
Da Vinci Communications Ltd
Christchurch - New Zealand

---

TEL : +64 3 3838311
FAX : +64 3 3838310
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
www : www.davinci-communications.com

---

Hi all,

I am new to this list. I would like to join in the current discussion
and add my 2 cents worth ;)

In my own opinion, module instantiation seems to be a very powerful and
clean solution. Alternatively and embracing the conservative approach, I
would like to extend on the the proposal of Zoltan Szabo with a subtle
difference:
Import statements do not contain parameter values. But, instead of
defining the actual module parameters in an external configuration file,
the value parameterization of the imported modules is done through the
control statement of the importing module. This supports consistency and
clarifies scoping.
All that is needed is to extend the signature of the control language
element to include value parameterization. The value parameterization
itself could be optional to allow precedence of defaults.

The following examples are pretty much self-explanatory:

module MyModuleA (integer p1 := 3)
{
:
control
{
:
}
}

module MyModuleB (float p1 := 3.33, boolean p2 := false)
{
:
import all from module MyModuleA;
:
// actual parameters for MyModuleA
control (MyModuleA.p1 := 123) // overwrite default module parameter
binding
{
:
}
}

module MyModuleC (integer p1)
{
:
import all from module MyModuleB;
:
control (MyModuleA.p1 := p1, // pass on own parameter to imported
module parameter
MyModuleB.p1 := 9.01, // overwrite default module parameter
binding
MyModuleB.p2 := false) // overwrite default module parameter binding
{
:
}
}

module MyModuleD
{
:
import all from module MyModuleB;
import all from module MyModuleA;
:
control (MyModuleA.p1 := 5, // this binding applies to use in
MyModuleD and MyModuleB
MyModuleB.p1 := 6.66,
MyModuleB.p2 := true)
{
:
}
}

Semantically, a module import statement only imports its respective
declarations not the value parameterization in the respective module
control part. This value parameterization only takes place within the
module control part of the importing module for all parameters of all
imported modules including of all transitive imported modules.

I would like to hear your opinion.

Regards,
Peter.

--

---

Dr Peter Meier
Chief Software Architect
Da Vinci Communications Ltd
Christchurch - New Zealand

---

TEL : +64 3 3838311
FAX : +64 3 3838310
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
www : www.davinci-communications.com

---

Hello all,

in several of the contributions to this discussion type definitions as
the following one have been used:

>
> module A(integer i) {
> type record of integer list;
> }
>

But to my understanding of the syntax of TTCN-3 the number of elements
in the 'record of' types resolves to a 'SingleConstExpression'. Note
that the BNF restricts this to a single expression not containing module
parameters.

SingleConstExpression ::= SingleExpression
/* STATIC SEMANTICS - SingleConstExpression shall not
contain Variables or Module parameters and shall resolve to a
constant Value at compile time */

Please correct me, if I am wrong here.

Is there any other way to have types which depend on module parameters?
If not, then I think there is no point in having multiple instances of
the same module.

Best regards

Thomas

---

| Thomas Deiß, Nokia Research Center Street address: |
| P.O. Box 101823 Meesmannstraße 103 |
| D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
| Phone: +49 234 984 2217 (int. 8272217) |
| Fax: +49 234 984 3491 (int. 8273491) |
| E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---