Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC: Port variables?

Port variables? 16 Jun 2004 12:35 #6683

Hi,

I have been wondering if it should be allowed to have port variables -
for example:

module demo {

type port PT message {
inout integer;
};

type component CT {
port PT P;
};

function f() runs on CT {
var PT v_P := P;
};
};

I cannot find a definitive statement in the standard, if this should or
should not be allowed. I can find both arguments for this and against this:

+ potentially useful
+ port _parameters_ are already allowed
- port parameters are not normal parameters (similar to timer parameters)
- there is no 'null' for ports

So, what do you think? Should or should it not be allowed to have
variables of port types?

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.
The administrator has disabled public write access.

Port variables? 16 Jun 2004 13:20 #6684

  • Antti Hyrkk
  • Antti Hyrkk's Avatar
  • OFFLINE
  • Senior Boarder
  • Posts: 43
  • Karma: 0
Hi Stephan

I don't think that the current BNF allows you to have port variables.

276. VarInstance ::= VarKeyword Type VarList
409. Type ::= PredefinedType | ReferencedType
410. PredefinedType ::= BitStringKeyword |
BooleanKeyword |
CharStringKeyword |
UniversalCharString |
IntegerKeyword |
OctetStringKeyword |
ObjectIdentifierKeyword |
HexStringKeyword |
VerdictTypeKeyword |
FloatKeyword |
AddressKeyword |
DefaultKeyword |
AnyTypeKeyword
427. ReferencedType ::= [GlobalModuleId Dot] TypeReference
[ExtendedFieldReference]
428. TypeReference ::= StructTypeIdentifier[TypeActualParList] |
EnumTypeIdentifier |
SubTypeIdentifier |
ComponentTypeIdentifier

If the port variables were allowed, then there should be a
"| PortTypeIdentifier" in the production of 428. TypeReference.

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 ext Stephan Tobies
Sent: Wednesday, June 16, 2004 14:36 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Port variables?


Hi,

I have been wondering if it should be allowed to have port variables -
for example:

module demo {

type port PT message {
inout integer;
};

type component CT {
port PT P;
};

function f() runs on CT {
var PT v_P := P;
};
};

I cannot find a definitive statement in the standard, if this should or
should not be allowed. I can find both arguments for this and against this:

+ potentially useful
+ port _parameters_ are already allowed
- port parameters are not normal parameters (similar to timer parameters)
- there is no 'null' for ports

So, what do you think? Should or should it not be allowed to have
variables of port types?

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.
The administrator has disabled public write access.

Port variables? 16 Jun 2004 13:28 #6685

Stephan,

what do you want to do with port variables?

I do not know any benefits of such an extension.

Best regards
Jens

Stephan Tobies wrote:

> Hi,
>
> I have been wondering if it should be allowed to have port variables -
> for example:
>
> module demo {
>
> type port PT message {
> inout integer;
> };
>
> type component CT {
> port PT P;
> };
>
> function f() runs on CT {
> var PT v_P := P;
> };
> };
>
> I cannot find a definitive statement in the standard, if this should or
> should not be allowed. I can find both arguments for this and against
> this:
>
> + potentially useful
> + port _parameters_ are already allowed
> - port parameters are not normal parameters (similar to timer parameters)
> - there is no 'null' for ports
>
> So, what do you think? Should or should it not be allowed to have
> variables of port types?
>
> 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.

--
======================================================================
Prof. Dr. Jens Grabowski
Institute for Informatics phone: +49 551 39 14690
University of Goettingen fax: +49 551 39 14415
Lotzestrasse 16-18
DE-37083 Göttingen This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) www.swe.informatik.uni-goettingen.de
======================================================================
The administrator has disabled public write access.

Port variables? 16 Jun 2004 13:42 #6687

ext Antti Hyrkkanen wrote:

>Hi Stephan
>
>I don't think that the current BNF allows you to have port variables.
>
>276. VarInstance ::= VarKeyword Type VarList
>409. Type ::= PredefinedType | ReferencedType
>410. PredefinedType ::= BitStringKeyword |
> BooleanKeyword |
> CharStringKeyword |
> UniversalCharString |
> IntegerKeyword |
> OctetStringKeyword |
> ObjectIdentifierKeyword |
> HexStringKeyword |
> VerdictTypeKeyword |
> FloatKeyword |
> AddressKeyword |
> DefaultKeyword |
> AnyTypeKeyword
>427. ReferencedType ::= [GlobalModuleId Dot] TypeReference
>[ExtendedFieldReference]
>428. TypeReference ::= StructTypeIdentifier[TypeActualParList] |
> EnumTypeIdentifier |
> SubTypeIdentifier |
> ComponentTypeIdentifier
>
>
>
That is the problem with static semantics somehow being put into the
BNF. Of course, the current BNF does allow to write

type port PT ...;

and then

var PT p;

But indeed, you are probably right that the way that the BNF is written
down indicates that port variables are implicitly forbidden.

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.
The administrator has disabled public write access.

Port variables? 16 Jun 2004 13:48 #6688

ext Jens Grabowski wrote:

> Stephan,
>
> what do you want to do with port variables?
>
> I do not know any benefits of such an extension.
>
One of our users has come up with this question, and his intended usage
is the following:

One component type is used for PTCs in different roles. This component
type has a number of different ports of the same type for different
purposes. Depending on the role in which the PTC is being used,
different ports shall be used for different purposes. By using component
port _variables_ (instead of component _ports_), re-usable code can be
written that works independent of the current role of the PTC because it
refers to the ports via the variables (which can be dynamically
re-assigned) and not via the (static) port names.

Ok, this is a bit of a hack, I agree, and I am not sure if it would not
be possible to achieve that same functionality via dynamic connections, etc.

I do not have a particularly strong case for the introduction of port
variables, I am more looking for clarification if they are currently
allowed or not.

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
Mobile: +49-163-9842405
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
The administrator has disabled public write access.

Port variables? 16 Jun 2004 14:49 #6690

Hi,

the potential application is clear.

What is unclear to me, why port parameters can not do the same? You can pass an
ID defining the
PTC's role to the function started on the PTC and it can be used to select the
function containing the real PTC behaviour for that role. You can pass the
needed port instances to the chosen function.

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: Wednesday, June 16, 2004 3:48 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Port variables?
>
>
> ext Jens Grabowski wrote:
>
> > Stephan,
> >
> > what do you want to do with port variables?
> >
> > I do not know any benefits of such an extension.
> >
> One of our users has come up with this question, and his
> intended usage
> is the following:
>
> One component type is used for PTCs in different roles. This component
> type has a number of different ports of the same type for different
> purposes. Depending on the role in which the PTC is being used,
> different ports shall be used for different purposes. By
> using component
> port _variables_ (instead of component _ports_), re-usable code can be
> written that works independent of the current role of the PTC
> because it
> refers to the ports via the variables (which can be dynamically
> re-assigned) and not via the (static) port names.
>
> Ok, this is a bit of a hack, I agree, and I am not sure if it
> would not
> be possible to achieve that same functionality via dynamic
> connections, etc.
>
> I do not have a particularly strong case for the introduction of port
> variables, I am more looking for clarification if they are currently
> allowed or not.
>
> 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
> Mobile: +49-163-9842405
> Fax: +49-234-9843491
> Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
>
The administrator has disabled public write access.

Port variables? 16 Jun 2004 14:53 #6691

Hi Stephan,

the answer to your question is that port variables are not allowed. If
this is not clearly stated in the standard, we should add a clarification.

Concerning your other point, I am not sure that value of port variables
will be higher than the problems we will introduce into the language
(e.g., dynamic change of default behaviour by using port variables).

For your concrete problem it might be a solution to put the entire
behaviour of the component into functions/altsteps with port parameters
and to pass in the concrete port names depending on the role.
You can even re-assign port roles by calling behaviour functions with
different parameterizations.

Best regards
Jens




Stephan Tobies wrote:

> ext Jens Grabowski wrote:
>
>> Stephan,
>>
>> what do you want to do with port variables?
>>
>> I do not know any benefits of such an extension.
>>
> One of our users has come up with this question, and his intended usage
> is the following:
>
> One component type is used for PTCs in different roles. This component
> type has a number of different ports of the same type for different
> purposes. Depending on the role in which the PTC is being used,
> different ports shall be used for different purposes. By using component
> port _variables_ (instead of component _ports_), re-usable code can be
> written that works independent of the current role of the PTC because it
> refers to the ports via the variables (which can be dynamically
> re-assigned) and not via the (static) port names.
>
> Ok, this is a bit of a hack, I agree, and I am not sure if it would not
> be possible to achieve that same functionality via dynamic connections,
> etc.
>
> I do not have a particularly strong case for the introduction of port
> variables, I am more looking for clarification if they are currently
> allowed or not.
>
> 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
> Mobile: +49-163-9842405
> Fax: +49-234-9843491
> Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany

--
======================================================================
Prof. Dr. Jens Grabowski
Institute for Informatics phone: +49 551 39 14690
University of Goettingen fax: +49 551 39 14415
Lotzestrasse 16-18
DE-37083 Göttingen This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) www.swe.informatik.uni-goettingen.de
======================================================================
The administrator has disabled public write access.

Port variables? 17 Jun 2004 05:30 #6696

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

>Hi,
>
>the potential application is clear.
>
>What is unclear to me, why port parameters can not do the same? You can pass an ID defining the
>PTC's role to the function started on the PTC and it can be used to select the function containing the real PTC behaviour for that role. You can pass the needed port instances to the chosen function.
>
>

Yes, that would be an alternative solution, I guess. As I said, - I do
not have a very strong case for the introduction of port variables.

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
Mobile: +49-163-9842405
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
The administrator has disabled public write access.

Port variables? 17 Jun 2004 05:32 #6697

ext Jens Grabowski wrote:

> Hi Stephan,
>
> the answer to your question is that port variables are not allowed. If
> this is not clearly stated in the standard, we should add a
> clarification.


Yes, I think so. Currently, it is more or less only implicit in the BNF
that one cannot have port variables - a stronger statement somewhere in
the text would be good. I will write a CR.

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
Mobile: +49-163-9842405
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
The administrator has disabled public write access.

Port variables? 17 Jun 2004 07:48 #6703

Hi,

No need for a new CR because text of $10 Variables is being revised due to
CR317. I will take care the new text clarifies this point too.

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: Thursday, June 17, 2004 7:32 AM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Port variables?
>
>
> ext Jens Grabowski wrote:
>
> > Hi Stephan,
> >
> > the answer to your question is that port variables are not
> allowed. If
> > this is not clearly stated in the standard, we should add a
> > clarification.
>
>
> Yes, I think so. Currently, it is more or less only implicit
> in the BNF
> that one cannot have port variables - a stronger statement
> somewhere in
> the text would be good. I will write a CR.
>
> 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
> Mobile: +49-163-9842405
> Fax: +49-234-9843491
> Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
>
The administrator has disabled public write access.
  • Page:
  • 1

FacebookTwitterGoogle BookmarksRedditNewsvineTechnoratiLinkedin