TOPIC:

Hi there,

>

---

Forwarded message

---

> Date: Wed, 17 Oct 2001 11:43:43 +0200
> From: Colin Willcock <This email address is being protected from spambots. You need JavaScript enabled to view it.>
> Reply-To: "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.>
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: A Problem with Imports
>
> 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)

Statement [A]:

> 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!!!!

Statement :

> 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.

In my opinion, the main problem is that an imported entity is qualified by
a source module *name* only. If a parametrized module is just a module
with open identifiers, then I would agree with .
However, a parametrized module perhaps should denote rather a class of
modules (differing only in the parameter values). Entities imported from
different instances of that class (instantiations of the generic module)
could gracefully coexist in the context of an importing module (see [A]).
Then, only the means of resolving the origin of an imported entity are
inadequate: The origin of an entity should be a module *instance*.
To avoid the redundancy mentioned in [A], there should be a way to give
names to module instances.

We therefore propose to extend the notion of a module:

a) good old module definitions
b) module aliases, may provide parameter values

and restrict import to modules (definitions or aliases) without
parameters.

Possible Syntax:

module MyDefinition {

module MyLibraryInstance1 := MyLibrary(Par1 := 42) ;
module MyLibraryInstance2 := MyLibrary(Par1 := 666) ;

import all from MyLibraryInstance1 ;
import all from MyLibraryInstance2 ;

... MyLibraryInstance1.x ... MyLibraryInstance2.x ...

}


> 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.

There is an implicit condition in this proposal, I guess: There must not
be more than one statement importing from the same module (neither with
the same nor different parameter values).

By giving names to module instances as described above, more flexible use
of imported modules can be achieved without introducing any ambiguity. The
syntax change also would be minimal and the proposed notation should be
self-explanatory.

What are your opinions on this?


Regards

Baltasar Trancon
TU Berlin

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.

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.

BR Colin.

---

Original Message

---

From: Baltasar Trancon-y-Widemann [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 17 October 2001 16:05
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: A Problem with Imports (fwd)


Hi there,

>

---

Forwarded message

---

> Date: Wed, 17 Oct 2001 11:43:43 +0200
> From: Colin Willcock <This email address is being protected from spambots. You need JavaScript enabled to view it.>
> Reply-To: "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.>
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: A Problem with Imports
>
> 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)

Statement [A]:

> 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!!!!

Statement :

> 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.

In my opinion, the main problem is that an imported entity is qualified by
a source module *name* only. If a parametrized module is just a module
with open identifiers, then I would agree with .
However, a parametrized module perhaps should denote rather a class of
modules (differing only in the parameter values). Entities imported from
different instances of that class (instantiations of the generic module)
could gracefully coexist in the context of an importing module (see [A]).
Then, only the means of resolving the origin of an imported entity are
inadequate: The origin of an entity should be a module *instance*.
To avoid the redundancy mentioned in [A], there should be a way to give
names to module instances.

We therefore propose to extend the notion of a module:

a) good old module definitions
b) module aliases, may provide parameter values

and restrict import to modules (definitions or aliases) without
parameters.

Possible Syntax:

module MyDefinition {

module MyLibraryInstance1 := MyLibrary(Par1 := 42) ;
module MyLibraryInstance2 := MyLibrary(Par1 := 666) ;

import all from MyLibraryInstance1 ;
import all from MyLibraryInstance2 ;

... MyLibraryInstance1.x ... MyLibraryInstance2.x ...

}


> 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.

There is an implicit condition in this proposal, I guess: There must not
be more than one statement importing from the same module (neither with
the same nor different parameter values).

By giving names to module instances as described above, more flexible use
of imported modules can be achieved without introducing any ambiguity. The
syntax change also would be minimal and the proposed notation should be
self-explanatory.

What are your opinions on this?


Regards

Baltasar Trancon
TU Berlin

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.
>
> 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.
>
> BR Colin.



I cannot see that a general concept of "alias" is introduced by Baltasars
suggestion.
Indeed the necessity of instantiating a generic module with different
parameters strongly depends on the practical usage of modules.
Maybe this has not been necessary in the past, but potenitally a module
can realize a kind of generic library, e.g. containing complicated type
definitions which only differ in some length constraint or some basic data
type selection.

Of course the parameter values of an instantiated module will keep the
same throughout all usage of this module, but a module with parameters is
NOT such an instantiated module, but a "template" for modules, --
comparable to a C++ template.

A situation like

module shortstrings := Predefined_SpecialProtocol_StringLib (maxlength := 127) ;
module longstrings := Predefined_SpecialProtocol_StringLib (maxlength := 1023) ;

import function compare from shortstrings ;
import type stringtyp from shortstring ;
import function debugprint from lonstrings ;


seems quite natural and understandable.

(Of course you would like to have TYPES as parameters for modules to make
them really generic :-)

This ist the viewpoint of general language design, not of your particular
field, but perhapes these remarks can be helpful.

Greeting
Markus



=======================================================================
|\ /| Markus Lepper
| \/ | TU Berlin - FB13 - Uebb Raum FR5023 Tel +49 30 314 24890
| | daheim Wigstr. 7 - 45239 Essen Tel +49 201 49 25 78
===== \-+--- ===========================================================
\|

In einer eMail vom 10/17/01 4:24:33 PM W. Europe Daylight Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:


Hi Baltasar,

Kudos to you. Wonderful solution. I like it!

Cheers,


Claude.

>
> Hi there,
>
> >

---

Forwarded message

---

> > Date: Wed, 17 Oct 2001 11:43:43 +0200
> > From: Colin Willcock <This email address is being protected from spambots. You need JavaScript enabled to view it.>
> > Reply-To: "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.>
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: A Problem with Imports
> >
> > 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)
>
> Statement [A]:
>
> > 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!!!!
>
> Statement :
>
> > 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.
>
> In my opinion, the main problem is that an imported entity is qualified by
> a source module *name* only. If a parametrized module is just a module
> with open identifiers, then I would agree with .
> However, a parametrized module perhaps should denote rather a class of
> modules (differing only in the parameter values). Entities imported from
> different instances of that class (instantiations of the generic module)
> could gracefully coexist in the context of an importing module (see [A]).
> Then, only the means of resolving the origin of an imported entity are
> inadequate: The origin of an entity should be a module *instance*.
> To avoid the redundancy mentioned in [A], there should be a way to give
> names to module instances.
>
> We therefore propose to extend the notion of a module:
>
> a) good old module definitions
> b) module aliases, may provide parameter values
>
> and restrict import to modules (definitions or aliases) without
> parameters.
>
> Possible Syntax:
>
> module MyDefinition {
>
> module MyLibraryInstance1 := MyLibrary(Par1 := 42) ;
> module MyLibraryInstance2 := MyLibrary(Par1 := 666) ;
>
> import all from MyLibraryInstance1 ;
> import all from MyLibraryInstance2 ;
>
> ... MyLibraryInstance1.x ... MyLibraryInstance2.x ...
>
> }
>
>
> > 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.
>
> There is an implicit condition in this proposal, I guess: There must not
> be more than one statement importing from the same module (neither with
> the same nor different parameter values).
>
> By giving names to module instances as described above, more flexible use
> of imported modules can be achieved without introducing any ambiguity. The
> syntax change also would be minimal and the proposed notation should be
> self-explanatory.
>
> What are your opinions on this?
>
>
> Regards
>
> Baltasar Trancón
> TU Berlin
>