TOPIC:

Hi, as promised, a more complicated issue with encoding attributes:

Consider the following example:

module M0 {

// single record type and constant of that type w/o encoding attribute

type record T0 {
integer field0
}

const T0 t := { 1 };
}

module M1 {
// import T0 with E1
import from M0 {
type T0
} with { encode "E1" }

// wrap T0 in T1_1
type record T1_1 {
T0 field1
}

port PT message {
inout T0
}

const T1_1 c1_1 := { { 1 } };

}

module M2 {
// import T0 with E2
import from M0 {
type T0
} with { encode "E2" }

// wrap T0 in T1_2
type record T1_2 {
T0 field1
}

const T1_2 c1_2 := { { 1 } };

}

module M_root {

// nonrecursive import of T1_1 and T1_2 makes T0 'implicitly' usable in M_root

import from M1 {
type T1_1, PT;
const c1_1;
}

import from M2 {
type T1_2;
const c1_2;
}

import from M0 {
const t
}

type component CT {
port PT P;
}

testcase tc() runs on CT {

P.send(t);
P.send(c1_1.field1);
P.send(c1_2.field1);
}
}

Again, the question is, which encoding attribute is used for the various send statements:

a) T0 is imported three times implictly into M_root with conflicting encoding attributes so there is no natural default choice which to used. Default to 'no attribute' when none is explicitly given, might be one solution. If M_root would explicitly import T0 with an encoding attribute, this would be used.

b) We stick to the encoding attribute that can be derived 'from the context' of the values, so t is sent without attributes, c1_1.field1 with "E1" and c1_2.field2 with "E2". What would then be the encoding attributes used in P.send(T1_1.field1:t) or P.send(T1_2.field1:t) ?

c) The port determines the encoding attribute: since PT is declared using a version of T0 with "E1" set, all three values would be sent using "E1" as encoding attribute. Since type checking for port statements is strict, the type of a template that is sent is always uniquely determined and hence the encoding attribute to choose is clear.

For us, this seems to be the clearest and easiest solution. It has its drawbacks, though:

What happens in the following case. In M_root we have the following:

type port PT1 message {
inout T1_1.field1, T1_2.field1
}

From the viewpoint of (strict) type-compatibility, T1_1.field1 and T1_2.field2 are identical (or aren't they? one might also treat T1_1.field1 as a synomnym of T0), but they have different encoding attributes. What encoding attribute would then apply when sending a value of type T0 over a port of type PT1? One possible solution would be to disallow two versions of the same type that only differ in encoding attributes to be sent/received over the same port.

Opinions?

Best regards

Stephan Tobies

As I understand your examples, your basic question is:

How do type compatibility and encoding attributes mix?

In my understanding, the encoding of an expression
is always specified by the encoding of the type of
that expression in that context. So, the question
would be transformed to 'How is the encoding of a
type in a context determined?'.

In your port example where you want to send
a value that is only _compatible_ with the two
types that can be sent over the port, the value
would have to be (implicitly) transformed first into
one of its compatible sendable variants.
As you always can (or in the case of constants even _have to_)
give the type of the template you are sending upon sending it
(by prefixing the value with it), this type (and
its encoding in that context) should be the
determining factor.

Of course, if you modify your examples so that
you already have a template of type T0 which
you want to send as either T1_1.field1 or
T2_1.field1, there you have an ambiguity
which could either result in a static error
or a dynamic indeterminism (I vote for the last!)
which the user can be warned about - if he doesn't
care which of the possibly conflicting encodings
is used in that case, let him.

Regarding your first mail, I would concur that
fields in a record inherit the records encoding,
but not the values inside the fields if used
singularily (only in the record they are
encoded with the type of the record).
So, if a field of a record is referenced, the
target type for the value of that field
(i.e. the variable that it is assigned to or the
port it is sent over) should be the determining
factor for the encoding, since the value now has
this type and is used as such.

This would mean, of course, that, if you declare
a variable to be of a record field type (like T1_1.field1)
then this type and its encoding are used and not the
encoding of the 'real' type of the field.

type record R {
integer f
} with encode override "X"

R r;

==>

var integer i1 := r.f // encoding of 'integer'
var R.f i2 := r.f // encoding "X"

The same with

type port P message { inout all } with encode "Y"

port P p;

==>

p.send(integer:r.f) // encoding "Y"
p.send(R.f:r.f) // encoding "X"

port P p;

==>

p.send(integer:r.f) // encoding "Y"
p.send(R.f:r.f) // encoding "X"

port P p;

==>

p.send(integer:r.f) // encoding "Y"
p.send(R.f:r.f) // encoding "X"

port P p;

==>

p.send(integer:r.f) // encoding "Y"
p.send(R.f:r.f) // encoding "X"

port P p;

==>

p.send(integer:r.f) // encoding "Y"
p.send(R.f:r.f) // encoding "X"

port P p;

==>

p.send(integer:r.f) // encoding "Y"
p.send(R.f:r.f) // encoding "X"

port P p;

==>

p.send(integer:r.f) // encoding "Y"
p.send(R.f:r.f) // encoding "X"

port P p;

==>

p.send(integer:r.f) // encoding "Y"
p.send(R.f:r.f) // encoding "X"

port P p;

==>

p.send(integer:r.f) // encoding "Y"
p.send(R.f:r.f) // encoding "X"

This is my understanding of the matter so far and I
think this is the easiest approach.

Jacob

I basically agree with Jacobs argumentation. However his example brings
me to another question.

What happened to type parameterisation?

I was looking through the TTCN-3 mailing list archive and could not find
any discussion that argued whether we should drop type parameterisation.
Could anybody enlighten me when and why this was decided? (not that I
did not know it was gone)

The reason I am bringing this up is the reference to a "record field
type" which Jacob considers to be distinguishing from the "real" field
type with regard to encoding rules.

Obviously this construct is useful when you have type parameterisation
and you do not know the type of a field at compile time. Thats why I
believe it is an artefact of the removed type paramterisation. The BNF
does indeed allow this, but I could find no reference to this usage in
the text. So if this feature is really desired, could somebody please
define the semantics (eg. regarding its role for encodings, type
compatibility, etc.)?

Regards,
Thomas

P.S.: There is another artefact of type parameterisation in the text at
chapter 5.3.1.1.c

> This would mean, of course, that, if you declare
> a variable to be of a record field type (like T1_1.field1)
> then this type and its encoding are used and not the
> encoding of the 'real' type of the field.
>
> type record R {
> integer f
> } with encode override "X"
>
> R r;
>
> var integer i1 := r.f // encoding of 'integer'
> var R.f i2 := r.f // encoding "X"

--

---

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,

A comment about this:

> From the viewpoint of (strict) type-compatibility, T1_1.field1 and
> T1_2.field2 are identical (or aren't they? one might also treat
> T1_1.field1 as a synomnym of T0), but they have different encoding
> attributes.

In this case, I don't think there is any ambiguity on the part of the
standard; Type compatibility rules apply as usual, but when
sending/receiving a value across a port, you have to know its type in
order to [en|de]code it properly.

Regards
/Johan

---

Original Message

---

From: Stephen TOBIES [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 21 maj 2002 13:41
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: More fun with encoding attributes

Hi, as promised, a more complicated issue with encoding attributes:

Consider the following example:

module M0 {

// single record type and constant of that type w/o encoding attribute

type record T0 {
integer field0
}

const T0 t := { 1 };
}

module M1 {
// import T0 with E1
import from M0 {
type T0
} with { encode "E1" }

// wrap T0 in T1_1
type record T1_1 {
T0 field1
}

port PT message {
inout T0
}

const T1_1 c1_1 := { { 1 } };

}

module M2 {
// import T0 with E2
import from M0 {
type T0
} with { encode "E2" }

// wrap T0 in T1_2
type record T1_2 {
T0 field1
}

const T1_2 c1_2 := { { 1 } };

}

module M_root {

// nonrecursive import of T1_1 and T1_2 makes T0 'implicitly' usable in
M_root

import from M1 {
type T1_1, PT;
const c1_1;
}

import from M2 {
type T1_2;
const c1_2;
}

import from M0 {
const t
}

type component CT {
port PT P;
}

testcase tc() runs on CT {

P.send(t);
P.send(c1_1.field1);
P.send(c1_2.field1);
}
}

Again, the question is, which encoding attribute is used for the various
send statements:

a) T0 is imported three times implictly into M_root with conflicting
encoding attributes so there is no natural default choice which to used.
Default to 'no attribute' when none is explicitly given, might be one
solution. If M_root would explicitly import T0 with an encoding attribute,
this would be used.

b) We stick to the encoding attribute that can be derived 'from the context'
of the values, so t is sent without attributes, c1_1.field1 with "E1" and
c1_2.field2 with "E2". What would then be the encoding attributes used in
P.send(T1_1.field1:t) or P.send(T1_2.field1:t) ?

c) The port determines the encoding attribute: since PT is declared using a
version of T0 with "E1" set, all three values would be sent using "E1" as
encoding attribute. Since type checking for port statements is strict, the
type of a template that is sent is always uniquely determined and hence the
encoding attribute to choose is clear.

For us, this seems to be the clearest and easiest solution. It has its
drawbacks, though:

What happens in the following case. In M_root we have the following:

type port PT1 message {
inout T1_1.field1, T1_2.field1
}

From the viewpoint of (strict) type-compatibility, T1_1.field1 and
T1_2.field2 are identical (or aren't they? one might also treat T1_1.field1
as a synomnym of T0), but they have different encoding attributes. What
encoding attribute would then apply when sending a value of type T0 over a
port of type PT1? One possible solution would be to disallow two versions of
the same type that only differ in encoding attributes to be sent/received
over the same port.

Opinions?

Best regards

Stephan Tobies

Hi Jacob,

in general, I agree that your solution is a good solution - encoding attributes are based on the 'absolute' type of the template that is being sent/received.

Though, I have two questions to what you have written - see below.

>

---

Original Message

---

> From: ext Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Dienstag, 21. Mai 2002 14:26
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: More fun with encoding attributes
>
>
> In your port example where you want to send
> a value that is only _compatible_ with the two
> types that can be sent over the port, the value
> would have to be (implicitly) transformed first into
> one of its compatible sendable variants.
> As you always can (or in the case of constants even _have to_)

Have to? What do you base this on? Since every constant is also typed, why not consider it as an implicit template of exactly this type?

> give the type of the template you are sending upon sending it
> (by prefixing the value with it), this type (and
> its encoding in that context) should be the
> determining factor.

Agreed.

>
> Of course, if you modify your examples so that
> you already have a template of type T0 which
> you want to send as either T1_1.field1 or
> T2_1.field1, there you have an ambiguity
> which could either result in a static error
> or a dynamic indeterminism (I vote for the last!)
> which the user can be warned about - if he doesn't
> care which of the possibly conflicting encodings
> is used in that case, let him.

I don't think that there is any ambiguity here. If the template is of type T0 and used as such use the encoding attributes for T0, if it is cast to another (compatible) type, use the corresponding encoding attributes.

>
> Regarding your first mail, I would concur that
> fields in a record inherit the records encoding,
> but not the values inside the fields if used
> singularily (only in the record they are
> encoded with the type of the record).
> So, if a field of a record is referenced, the
> target type for the value of that field
> (i.e. the variable that it is assigned to or the
> port it is sent over) should be the determining
> factor for the encoding, since the value now has
> this type and is used as such.
>
> This would mean, of course, that, if you declare
> a variable to be of a record field type (like T1_1.field1)
> then this type and its encoding are used and not the
> encoding of the 'real' type of the field.
>
> type record R {
> integer f
> } with encode override "X"
>
> R r;
>
> ==>
>
> var integer i1 := r.f // encoding of 'integer'
> var R.f i2 := r.f // encoding "X"

I disagree. The encoding "X" should be valid only within the context of R.

>
> The same with
>
> type port P message { inout all } with encode "Y"

I had the discussion what the meaning of an encoding attribute placed at a port should be. I read your code that for you the encoding attribute place at a port influences all messages being sent over that port. While I agree that it might be useful to have such a thing, I don't find any support in the current version of the standard for this semantics.

In the current version, there is no exception for ports, the "Y" in this case would be encoding attribute to be used when sending/receiving instances of 'P', not when sending/receiving messages on a port of type P.

It might be desirable to have a semantics as you propose, but then this needs to be made explicit in the standard.

Regards

Stephan

On Fri, 24 May 2002, Stephen TOBIES wrote:

> Hi Jacob,
>
> > In your port example where you want to send
> > a value that is only _compatible_ with the two
> > types that can be sent over the port, the value
> > would have to be (implicitly) transformed first into
> > one of its compatible sendable variants.
> > As you always can (or in the case of constants even _have to_)
>
> Have to? What do you base this on? Since every constant is also typed, why not
consider it as an implicit template of exactly this type?

Okay, you are right, I meant 'literal values' like '5' or '"foobar"'
or '{ 1, 3, 5 }' which could be of several types.
The standard says that the type must be given if the expression
is of ambiguous type.

> > give the type of the template you are sending upon sending it
> > (by prefixing the value with it), this type (and
> > its encoding in that context) should be the
> > determining factor.
>
> Agreed.
>
> >
> > Of course, if you modify your examples so that
> > you already have a template of type T0 which
> > you want to send as either T1_1.field1 or
> > T2_1.field1, there you have an ambiguity
> > which could either result in a static error
> > or a dynamic indeterminism (I vote for the last!)
> > which the user can be warned about - if he doesn't
> > care which of the possibly conflicting encodings
> > is used in that case, let him.
>
> I don't think that there is any ambiguity here. If the template is of type T0
and used as such use the encoding attributes for T0, if it is cast to another
(compatible) type, use the corresponding encoding attributes.
>

Oh? I remembered in your example that the port may only send
T1_1 and T2_1 and thus not T0, which - though
it is compatible to both - would have to be transformed
into one or the other before sending.

> > Regarding your first mail, I would concur that
> > fields in a record inherit the records encoding,
> > but not the values inside the fields if used
> > singularily (only in the record they are
> > encoded with the type of the record).
> > So, if a field of a record is referenced, the
> > target type for the value of that field
> > (i.e. the variable that it is assigned to or the
> > port it is sent over) should be the determining
> > factor for the encoding, since the value now has
> > this type and is used as such.
> >
> > This would mean, of course, that, if you declare
> > a variable to be of a record field type (like T1_1.field1)
> > then this type and its encoding are used and not the
> > encoding of the 'real' type of the field.
> >
> > type record R {
> > integer f
> > } with encode override "X"
> >
> > R r;
> >
> > ==>
> >
> > var integer i1 := r.f // encoding of 'integer'
> > var R.f i2 := r.f // encoding "X"
>
> I disagree. The encoding "X" should be valid only within the context of R.

Why? R.f is (if it is a valid type expression) clearly defined with
the encoding of R.

> > The same with
> >
> > type port P message { inout all } with encode "Y"
>
> I had the discussion what the meaning of an encoding attribute placed at a
port should be. I read your code that for you the encoding attribute place at a
port influences all messages being sent over that port. While I agree that it
might be useful to have such a thing, I don't find any support in the current
version of the standard for this semantics.
>
> In the current version, there is no exception for ports, the "Y" in this case
would be encoding attribute to be used when sending/receiving instances of 'P',
not when sending/receiving messages on a port of type P.
>

Oh! I didn't know that you could send ports over ports as it is totally
unclear what the interpretation of a 'foreign' port in another component
should be (it can't use it for anything except maybe comparison with
other ports it received or again sending it) - you can't ask a port
for its component, you can only send or receive something on your
own ports, you can't connect it ... so why send it - and thus - why
encode it?

> It might be desirable to have a semantics as you propose, but then this needs
to be made explicit in the standard.

I concur with that.

Jacob

>

---

Original Message

---

> From: ext Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Freitag, 24. Mai 2002 14:09
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: More fun with encoding attributes
>
>
> On Fri, 24 May 2002, Stephen TOBIES wrote:
>
> > Hi Jacob,
> >
> > > In your port example where you want to send
> > > a value that is only _compatible_ with the two
> > > types that can be sent over the port, the value
> > > would have to be (implicitly) transformed first into
> > > one of its compatible sendable variants.
> > > As you always can (or in the case of constants even _have to_)
> >
> > Have to? What do you base this on? Since every constant is
> also typed, why not consider it as an implicit template of
> exactly this type?
>
> Okay, you are right, I meant 'literal values' like '5' or '"foobar"'
> or '{ 1, 3, 5 }' which could be of several types.
> The standard says that the type must be given if the expression
> is of ambiguous type.
>
> > > give the type of the template you are sending upon sending it
> > > (by prefixing the value with it), this type (and
> > > its encoding in that context) should be the
> > > determining factor.
> >
> > Agreed.
> >
> > >
> > > Of course, if you modify your examples so that
> > > you already have a template of type T0 which
> > > you want to send as either T1_1.field1 or
> > > T2_1.field1, there you have an ambiguity
> > > which could either result in a static error
> > > or a dynamic indeterminism (I vote for the last!)
> > > which the user can be warned about - if he doesn't
> > > care which of the possibly conflicting encodings
> > > is used in that case, let him.
> >
> > I don't think that there is any ambiguity here. If the
> template is of type T0 and used as such use the encoding
> attributes for T0, if it is cast to another (compatible)
> type, use the corresponding encoding attributes.
> >
>
> Oh? I remembered in your example that the port may only send
> T1_1 and T2_1 and thus not T0, which - though
> it is compatible to both - would have to be transformed
> into one or the other before sending.

That brings us back to the question whether in the case

type record R {
integer f
}

R.f and integer are synonyms or the same type. I think that we have somehow agreed that they were equal when it comes to type checking. So a port that, in the previous example, can send T1_1.field1 or T2_1.field1 can also send T0, and the encoding attribute will depend on which of these types is actually being sent.

>
> > > Regarding your first mail, I would concur that
> > > fields in a record inherit the records encoding,
> > > but not the values inside the fields if used
> > > singularily (only in the record they are
> > > encoded with the type of the record).
> > > So, if a field of a record is referenced, the
> > > target type for the value of that field
> > > (i.e. the variable that it is assigned to or the
> > > port it is sent over) should be the determining
> > > factor for the encoding, since the value now has
> > > this type and is used as such.
> > >
> > > This would mean, of course, that, if you declare
> > > a variable to be of a record field type (like T1_1.field1)
> > > then this type and its encoding are used and not the
> > > encoding of the 'real' type of the field.
> > >
> > > type record R {
> > > integer f
> > > } with encode override "X"
> > >
> > > R r;
> > >
> > > ==>
> > >
> > > var integer i1 := r.f // encoding of 'integer'
> > > var R.f i2 := r.f // encoding "X"
> >
> > I disagree. The encoding "X" should be valid only within
> the context of R.
>
> Why? R.f is (if it is a valid type expression) clearly defined with
> the encoding of R.

It is a matter of taste, really, and should be resolved by the standard. Both approaches have their pros and cons.

>
> > > The same with
> > >
> > > type port P message { inout all } with encode "Y"
> >
> > I had the discussion what the meaning of an encoding
> attribute placed at a port should be. I read your code that
> for you the encoding attribute place at a port influences all
> messages being sent over that port. While I agree that it
> might be useful to have such a thing, I don't find any
> support in the current version of the standard for this semantics.
> >
> > In the current version, there is no exception for ports,
> the "Y" in this case would be encoding attribute to be used
> when sending/receiving instances of 'P', not when
> sending/receiving messages on a port of type P.
> >
>
> Oh! I didn't know that you could send ports over ports as it
> is totally
> unclear what the interpretation of a 'foreign' port in
> another component
> should be (it can't use it for anything except maybe comparison with
> other ports it received or again sending it) - you can't ask a port
> for its component, you can only send or receive something on your
> own ports, you can't connect it ... so why send it - and thus - why
> encode it?

I never said that it would make sense to send ports - it is only that the standard does not mention ports as special cases when it comes to specifying encoding attributes, and soe they should not get any special treatment.

>
> > It might be desirable to have a semantics as you propose,
> but then this needs to be made explicit in the standard.
>
> I concur with that.
>
> Jacob
>

On Fri, 24 May 2002, Stephen TOBIES wrote:

> That brings us back to the question whether in the case
>
> type record R {
> integer f
> }
>
> R.f and integer are synonyms or the same type.
> I think that we have somehow agreed that they were equal

not equal - compatible, I think there's a difference

> when it comes to type checking.

But not regarding their encoding.

> So a port that, in the previous example, can send T1_1.field1
> or T2_1.field1 can also send T0, and the encoding attribute will
> depend on which of these types is actually being sent.

Which I would call an ambiguity, as the standard doesn't say which
is meant.

> > Why? R.f is (if it is a valid type expression) clearly defined with
> > the encoding of R.
>
> It is a matter of taste, really, and should be resolved by the standard. Both
approaches have their pros and cons.

Which cons are that?

> > > > The same with
> > > >
> > > > type port P message { inout all } with encode "Y"
> > >
> > > I had the discussion what the meaning of an encoding
> > attribute placed at a port should be. I read your code that
> > for you the encoding attribute place at a port influences all
> > messages being sent over that port. While I agree that it
> > might be useful to have such a thing, I don't find any
> > support in the current version of the standard for this semantics.
> > >
> > > In the current version, there is no exception for ports,
> > the "Y" in this case would be encoding attribute to be used
> > when sending/receiving instances of 'P', not when
> > sending/receiving messages on a port of type P.
> > >
> >
> > Oh! I didn't know that you could send ports over ports as it
> > is totally
> > unclear what the interpretation of a 'foreign' port in
> > another component
> > should be (it can't use it for anything except maybe comparison with
> > other ports it received or again sending it) - you can't ask a port
> > for its component, you can only send or receive something on your
> > own ports, you can't connect it ... so why send it - and thus - why
> > encode it?
>
> I never said that it would make sense to send ports - it is only that the
standard does not mention ports as special cases when it comes to specifying
encoding attributes, and soe they should not get any special treatment.

As I understood the encoding attribute it defines for a context
how the DATA in that context should be encoded upon sending them
over a port.

So, if you add an encode attribute to a module, it distributes
to all its contents.

if you add an encode attribute to a funciton/testcase/altstep,
it distributes to the send statements therein.

if you add an encode attribute to a component type it distributes
to the components fields (i.e. the ports, variables and constants)

if you add an encode attribute to a port type, it distributes to
the types that are sent over ports of that type

This, I would gather from the fact that it doesn't make sense
to send functions/testcases/altsteps, components or ports, but
it would make a lot of sense to interprete their encode attributes
that way.

> > > It might be desirable to have a semantics as you propose,
> > but then this needs to be made explicit in the standard.

I agree that the standard should describe the semantics of the
encode attribute for the different constructs (and not only
the overwrite behavior).

Jacob

>

---

Original Message

---

> From: ext Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Freitag, 24. Mai 2002 20:07
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: More fun with encoding attributes
>
>
> On Fri, 24 May 2002, Stephen TOBIES wrote:
>
> > That brings us back to the question whether in the case
> >
> > type record R {
> > integer f
> > }
> >
> > R.f and integer are synonyms or the same type.
> > I think that we have somehow agreed that they were equal
>
> not equal - compatible, I think there's a difference

Agreed - compatible, also in the strict sense of type checking in port statements.

>
> > when it comes to type checking.
>
> But not regarding their encoding.
>
> > So a port that, in the previous example, can send T1_1.field1
> > or T2_1.field1 can also send T0, and the encoding attribute will
> > depend on which of these types is actually being sent.
>
> Which I would call an ambiguity, as the standard doesn't say which
> is meant.

It's ambiguous in the standard, yes. But if we choose the type-base approach of determining the EA, there is no ambiguity when fixing the EA - it comes with the type of the entity/template being used in the send/receive statement.

>
> > > Why? R.f is (if it is a valid type expression) clearly
> defined with
> > > the encoding of R.
> >
> > It is a matter of taste, really, and should be resolved by
> the standard. Both approaches have their pros and cons.
>
> Which cons are that?

I would need to change my implementation :-) - I admit, your approach seems to make much sense, at least, if the notation R.f for types is to remain in the language. Personally, I don't like it very much and I cannot find any sensible use of it, maybne except for the usage in connection with encoding attributes.

>
> > > > > The same with
> > > > >
> > > > > type port P message { inout all } with encode "Y"
> > > >
> > > > I had the discussion what the meaning of an encoding
> > > attribute placed at a port should be. I read your code that
> > > for you the encoding attribute place at a port influences all
> > > messages being sent over that port. While I agree that it
> > > might be useful to have such a thing, I don't find any
> > > support in the current version of the standard for this semantics.
> > > >
> > > > In the current version, there is no exception for ports,
> > > the "Y" in this case would be encoding attribute to be used
> > > when sending/receiving instances of 'P', not when
> > > sending/receiving messages on a port of type P.
> > > >
> > >
> > > Oh! I didn't know that you could send ports over ports as it
> > > is totally
> > > unclear what the interpretation of a 'foreign' port in
> > > another component
> > > should be (it can't use it for anything except maybe
> comparison with
> > > other ports it received or again sending it) - you can't
> ask a port
> > > for its component, you can only send or receive something on your
> > > own ports, you can't connect it ... so why send it - and
> thus - why
> > > encode it?
> >
> > I never said that it would make sense to send ports - it is
> only that the standard does not mention ports as special
> cases when it comes to specifying encoding attributes, and
> soe they should not get any special treatment.
>
> As I understood the encoding attribute it defines for a context
> how the DATA in that context should be encoded upon sending them
> over a port.
>
> So, if you add an encode attribute to a module, it distributes
> to all its contents.
>
> if you add an encode attribute to a funciton/testcase/altstep,
> it distributes to the send statements therein.
>
> if you add an encode attribute to a component type it distributes
> to the components fields (i.e. the ports, variables and constants)
>
> if you add an encode attribute to a port type, it distributes to
> the types that are sent over ports of that type
>
> This, I would gather from the fact that it doesn't make sense
> to send functions/testcases/altsteps, components or ports, but
> it would make a lot of sense to interprete their encode attributes
> that way.

You have a dymanic interpretation of the meaning of EA's while, in my opinion, the standard uses a static approach, where the EA's are tied to a type definition. This would make usage of EA's for function-like definitions meaningless. I agree that the dymanic approach that you describe might be useful, but I don't think that it is currently supported by the standard.

Unfortunately, the standard is extremely vague in this respect, and I would like to hear some clarifying words on this issue soon.

>
> > > > It might be desirable to have a semantics as you propose,
> > > but then this needs to be made explicit in the standard.
>
> I agree that the standard should describe the semantics of the
> encode attribute for the different constructs (and not only
> the overwrite behavior).

True, very true indeed!

Best regards

Stephan