TOPIC:

Hi All



It seems that there exists confusing asymmetry between sender and recipient
addresses in multicast operations. Just compare ToClause and FromClause
rules in TTCN-3 BNF.

When sending data one may use "(recipient1, recipient2, recipient3)" list of
inline templates in multicast send. Since this is not a 'value list' all
entries in this list may have different and incompatible types.



For example:



type component CT1 {

port PT P1

}



type component CT2 {

port PT P2

}



function f() {

var CT1 c1 := CT1.create;

var CT2 c2 := CT2.create;



P.send(1) to (c1, c2); //CORRECT, although C1 and C2 are not compatible

}



But when specifying valid senders in multicast receive we have to use 'value
list' notation and all entries must have compatible types.



function f() {

var CT1 c1 := CT1.create;

var CT2 c2 := CT2.create;



P.receive(1) from (c1, c2); //ILLEGAL, type error since CT1 and CT2 are
incompatible

}



I think sender addresses should be specified similar to recipient ones.

For example, BNF may look like:



FromClause ::= FromKeyword (AddressRef | AddressRefList | AnyKeyword
ComponentKeyword)



Best regards,

/Pavel

Hi Pavel,

I agree with you. Such restriction was not aimed for the receive oparation, simply from any component has the same semantical meaning as not having the from clause at all. But for common (for the send and receive ops) and symmetric syntax it should be allowed by the bnf and defined in the text part.

Could you write a CR on this?

BR, Gyorgy


________________________________

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 Pavel Yakovenko
Sent: Friday, 2007 January 19. 03:06 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Assymetry in mulicast send and receive



Hi All



It seems that there exists confusing asymmetry between sender and recipient addresses in multicast operations. Just compare ToClause and FromClause rules in TTCN-3 BNF.

When sending data one may use "(recipient1, recipient2, recipient3)" list of inline templates in multicast send. Since this is not a 'value list' all entries in this list may have different and incompatible types.



For example:



type component CT1 {

port PT P1

}



type component CT2 {

port PT P2

}



function f() {

var CT1 c1 := CT1.create;

var CT2 c2 := CT2.create;



P.send(1) to (c1, c2); //CORRECT, although C1 and C2 are not compatible

}



But when specifying valid senders in multicast receive we have to use 'value list' notation and all entries must have compatible types.



function f() {

var CT1 c1 := CT1.create;

var CT2 c2 := CT2.create;



P.receive(1) from (c1, c2); //ILLEGAL, type error since CT1 and CT2 are incompatible

}



I think sender addresses should be specified similar to recipient ones.

For example, BNF may look like:



FromClause ::= FromKeyword (AddressRef | AddressRefList | AnyKeyword ComponentKeyword)



Best regards,

/Pavel

Hi György and Pavel,

Shouldn't BNF for ToClause contain a couple of extra parentheses BTW, e.g. like that:

ToClause ::= ToKeyword (AddressRef | AddressRefList | AllKeyword ComponentKeyword)

Same for FromClause probably.

Alexey

György Réthy (IJ/ETH) <This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote: @page Section1 {size: 595.3pt 841.9pt; margin: 2.0cm 42.5pt 2.0cm 3.0cm; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } SPAN.EmailStyle17 { COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose } DIV.Section1 { page: Section1 } Hi Pavel,

I agree with you. Such restriction was not aimed for the receive oparation, simply from any component has the same semantical meaning as not having the from clause at all. But for common (for the send and receive ops) and symmetric syntax it should be allowed by the bnf and defined in the text part.

Could you write a CR on this?

BR, Gyorgy

---

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 Pavel Yakovenko
Sent: Friday, 2007 January 19. 03:06 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Assymetry in mulicast send and receive



Hi All

It seems that there exists confusing asymmetry between sender and recipient addresses in multicast operations. Just compare ToClause and FromClause rules in TTCN-3 BNF.
When sending data one may use “(recipient1, recipient2, recipient3)” list of inline templates in multicast send. Since this is not a ‘value list’ all entries in this list may have different and incompatible types.

For example:

type component CT1 {
port PT P1
}

type component CT2 {
port PT P2
}

function f() {
var CT1 c1 := CT1.create;
var CT2 c2 := CT2.create;

P.send(1) to (c1, c2); //CORRECT, although C1 and C2 are not compatible
}

But when specifying valid senders in multicast receive we have to use ‘value list‘ notation and all entries must have compatible types.

function f() {
var CT1 c1 := CT1.create;
var CT2 c2 := CT2.create;

P.receive(1) from (c1, c2); //ILLEGAL, type error since CT1 and CT2 are incompatible
}

I think sender addresses should be specified similar to recipient ones.
For example, BNF may look like:

FromClause ::= FromKeyword (AddressRef | AddressRefList | AnyKeyword ComponentKeyword)

Best regards,
/Pavel