Now that I see that there is still people reading/respoding to this mailing list :)

I would like to bring up one more time this superste issue.
In short: is the difference in meaning of the superset operation in TTCN-2 and TTCN-3 intentional?

Could Jens maybe comment on my earlier email?

Thanks,

stephan

---

> Hi
>
> > Dear Stephan,
> >
> > beside the fact that I believe that the example you gave is a
> > little bit
>
> You may find this surprising but with some tools out in the
> market today this actually analyzed successfully :)
>
> > buggy, I could not found the interpretive issue in the BNF
> > you mentioned.
>
> OK - I am not a TTCN-3 BNF expert .. neither a TTCN-3 parser
> implementor .. but I was looking at the below lines:
>
> 550. ConstantExpression ::= SingleConstExpression |
> CompoundConstExpression
> 551. SingleConstExpression ::= SingleExpression
> /* STATIC SEMANTICS - SingleConstExpression shall not contain
> Variables or Module parameters and
> shall resolve to a constant Value at compile time */
>
> And it was this semantics comment which I was a little blurry
> to me. When I first read this I was tempted of think of
> matching characters as being a short hand notation of a value
> list - which sounded to me as also being constant at compile time.
>
> > According to the BNF superset always reduces to
> SingleConstExpressions
> > or CompoundConstExpression. There is no place for wildcards.
> >
> > So to answer your question, yes you can not use wildcard matching
> > symbols there.
>
> Alright - then why this departure in TTCN-3 from original
> TTCN-2 semantics?
>
> In the TTCN-2 BNF the superset is defined as
>
> 575 superset ::= "(" ConstraintValue&Attributes ")"
> .... tada ..
>
> 563 ConstraintValue ::= ConstraintExpression |
> MatchingSymbol | ConsRef
>
>
> According to my understanding of the language the superset
> operation is meant to be used in matching .. so I Have to say
> that it sounds quite counterintuitive - at least to me - that
> this operation "forbids" the use of matching characters (in TTCN-3).
>
> Moikka,
>
> stephan

Dear Stephan,

to your question:

As far as I remember we tried to delete some TTCN-2 matching mechanisms
in TTCN-3, because we thought they were not used and we might have a
chance get rid of some unused stuff. However, after a while some users
detected this and found reasons for the re-introduction (they come
up with real examples and not only with the backwards-compatability
argument).

Superset was one of these 're-introduced' matching mechanisms (I hope
I remember correctly!). I believe if there is a difference, it is not
intended. At least I cannot remember of any discussion to change the
meaning.

If there is a difference and if you think the current TTCN-3
implementation is a problem, please put in a CR.

Can you give me a hint to what other Email I should respond/comment?

There are lots of TTCN-3 Emails in my box and I haven't had a chance
to read them all.

Regards
Jens



"Dr. Schulz Stephan" schrieb:
>
> Now that I see that there is still people reading/respoding to this mailing
list :)
>
> I would like to bring up one more time this superste issue.
> In short: is the difference in meaning of the superset operation in TTCN-2 and
TTCN-3 intentional?
>
> Could Jens maybe comment on my earlier email?
>
> Thanks,
>
> stephan
>
>

---

---

> > Hi
> >
> > > Dear Stephan,
> > >
> > > beside the fact that I believe that the example you gave is a
> > > little bit
> >
> > You may find this surprising but with some tools out in the
> > market today this actually analyzed successfully :)
> >
> > > buggy, I could not found the interpretive issue in the BNF
> > > you mentioned.
> >
> > OK - I am not a TTCN-3 BNF expert .. neither a TTCN-3 parser
> > implementor .. but I was looking at the below lines:
> >
> > 550. ConstantExpression ::= SingleConstExpression |
> > CompoundConstExpression
> > 551. SingleConstExpression ::= SingleExpression
> > /* STATIC SEMANTICS - SingleConstExpression shall not contain
> > Variables or Module parameters and
> > shall resolve to a constant Value at compile time */
> >
> > And it was this semantics comment which I was a little blurry
> > to me. When I first read this I was tempted of think of
> > matching characters as being a short hand notation of a value
> > list - which sounded to me as also being constant at compile time.
> >
> > > According to the BNF superset always reduces to
> > SingleConstExpressions
> > > or CompoundConstExpression. There is no place for wildcards.
> > >
> > > So to answer your question, yes you can not use wildcard matching
> > > symbols there.
> >
> > Alright - then why this departure in TTCN-3 from original
> > TTCN-2 semantics?
> >
> > In the TTCN-2 BNF the superset is defined as
> >
> > 575 superset ::= "(" ConstraintValue&Attributes ")"
> > .... tada ..
> >
> > 563 ConstraintValue ::= ConstraintExpression |
> > MatchingSymbol | ConsRef
> >
> >
> > According to my understanding of the language the superset
> > operation is meant to be used in matching .. so I Have to say
> > that it sounds quite counterintuitive - at least to me - that
> > this operation "forbids" the use of matching characters (in TTCN-3).
> >
> > Moikka,
> >
> > stephan

--

======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================

Hi,

let me add Thomas' and my thoughts to this discussion. The problem that Stephan Sch. is addressing here is that once cannot use templates in a sub-/super-set matching expression, e.g., one cannot say

type UT union {
integer a,
integer b,
integer c
}

subset ( {a := ?}, {b := ?} )

to express a set of/record of where no entry has the c alternative chosen.

In general, it is not possible to use templates in value lists. E.g., one cannot use the expression

( {a := ?}, {b := ?} ) to match the set of values of type UT where the c alternative is not chosen.

We cannot see a good reason why it should not be allowed to use arbitrary template expressions in value lists.

Actually, we can see one - the superset matching expression.

Templates can semantically be perceived as sets of values in a straightforward manner. A normal value used as template can be interpreted as the singleton set containing the value, ? and * can be perceived as the set of all values of the type in question, value lists are interpreted as the union of the interpretation of their elements, etc. For a tempalte T, let [T] denote its interpretation as set of values.

When it comes to matching a value x against a template T, the value matches if it is an element of the interpretation of the template, i.e., x \in [T] - so much so good.

When allowing arbitrary templates to be used in value lists, the semantic of the value lists itself and also of the subset matching expression extendes nicely. E.g., a set of value s matches subset (T1, T2, ... , Tn) iff S \subset Union([T1], [T2], ..., [Tn]). No problem here.

When it comes to superset, things are no longer this clear. If we use the naive definition of when a set of value s matches superset (T1, T2, ..., Tn), one would probably require

Union ([T1], [T2], ..., [Tn]) \subset S

Clearly, if T1, ..., Tn are constant expressions, this is euqivalent to the current, operational definition of the superset matching operation.

But here is the problem: Consider the following example:

template boolean T1 := ?;
template boolean T2 := true;
template boolean T3 := false;

Using the above semantics, T1 and (T2, T3) are semantically equivalent:

[T1] = {true, false} = [(T2,T3)]
[subset(T1)] = [subset (T2,T3)] = PowerMultiSet({true,false})

but also

[superset(T1)] = [superset (T2,T3)] = { s \in PowerMultiSet({true,false}) | true \in s and false \in s }

Is this the indended semantics of the superset matching expression??? Operationally, I would rather expect:

[superset(T1)] = PowerMultiSet({true,false}) \ { emptyset }

and

[superset (T2,T3)] = { s \in PowerMultiSet({true,false}) | true \in s and false \in s } as above.

So, in other words - if we allow arbitrary templates in valueslists of superset, then the intuitive semantics of templates as sets can no longer be extended to the superset matching expression - at least not using the straightforward semantics 'mapping' of superset.

Is this really a problem - well, maybe not - currently the whole semantics of templates is defined operationally and not using sets, and the operational semantics extend in a straighforward manner...

On the other hand, maybe then 'superset' is not the right name for the matching expression, because it implies a set-theoretic denotation.

Best regards

Stephan Tobies



>

---

Original Message

---

> From: ext Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 26. February 2003 13:02
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Superset - try II
>
>
> Dear Stephan,
>
> to your question:
>
> As far as I remember we tried to delete some TTCN-2 matching
> mechanisms
> in TTCN-3, because we thought they were not used and we might have a
> chance get rid of some unused stuff. However, after a while some users
> detected this and found reasons for the re-introduction (they come
> up with real examples and not only with the backwards-compatability
> argument).
>
> Superset was one of these 're-introduced' matching mechanisms (I hope
> I remember correctly!). I believe if there is a difference, it is not
> intended. At least I cannot remember of any discussion to change the
> meaning.
>
> If there is a difference and if you think the current TTCN-3
> implementation is a problem, please put in a CR.
>
> Can you give me a hint to what other Email I should respond/comment?
>
> There are lots of TTCN-3 Emails in my box and I haven't had a chance
> to read them all.
>
> Regards
> Jens
>
>
>
> "Dr. Schulz Stephan" schrieb:
> >
> > Now that I see that there is still people reading/respoding
> to this mailing list :)
> >
> > I would like to bring up one more time this superste issue.
> > In short: is the difference in meaning of the superset
> operation in TTCN-2 and TTCN-3 intentional?
> >
> > Could Jens maybe comment on my earlier email?
> >
> > Thanks,
> >
> > stephan
> >
> >
>

---

>

---

> > > Hi
> > >
> > > > Dear Stephan,
> > > >
> > > > beside the fact that I believe that the example you gave is a
> > > > little bit
> > >
> > > You may find this surprising but with some tools out in the
> > > market today this actually analyzed successfully :)
> > >
> > > > buggy, I could not found the interpretive issue in the BNF
> > > > you mentioned.
> > >
> > > OK - I am not a TTCN-3 BNF expert .. neither a TTCN-3 parser
> > > implementor .. but I was looking at the below lines:
> > >
> > > 550. ConstantExpression ::= SingleConstExpression |
> > > CompoundConstExpression
> > > 551. SingleConstExpression ::= SingleExpression
> > > /* STATIC SEMANTICS - SingleConstExpression shall not contain
> > > Variables or Module parameters and
> > > shall resolve to a constant Value at compile time */
> > >
> > > And it was this semantics comment which I was a little blurry
> > > to me. When I first read this I was tempted of think of
> > > matching characters as being a short hand notation of a value
> > > list - which sounded to me as also being constant at compile time.
> > >
> > > > According to the BNF superset always reduces to
> > > SingleConstExpressions
> > > > or CompoundConstExpression. There is no place for wildcards.
> > > >
> > > > So to answer your question, yes you can not use
> wildcard matching
> > > > symbols there.
> > >
> > > Alright - then why this departure in TTCN-3 from original
> > > TTCN-2 semantics?
> > >
> > > In the TTCN-2 BNF the superset is defined as
> > >
> > > 575 superset ::= "(" ConstraintValue&Attributes ")"
> > > .... tada ..
> > >
> > > 563 ConstraintValue ::= ConstraintExpression |
> > > MatchingSymbol | ConsRef
> > >
> > >
> > > According to my understanding of the language the superset
> > > operation is meant to be used in matching .. so I Have to say
> > > that it sounds quite counterintuitive - at least to me - that
> > > this operation "forbids" the use of matching characters
> (in TTCN-3).
> > >
> > > Moikka,
> > >
> > > stephan
>
> --
>
> ======================================================================
> Dr. Jens Grabowski
> Institute for Telematics phone: +49 451 500 3723
> University of Luebeck fax: +49 451 500 3722
> Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
> (Germany) WWW: www.itm.mu-luebeck.de
> ======================================================================
>

Hi Stephan,

Jens' response confirms my reply when you first asked this question: no
difference was intended. Please submit a CR.

Regards,
Anthony

>

---

Original Message

---

> From: Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 26 February 2003 13:02
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Superset - try II
>
>
> Dear Stephan,
>
> to your question:
>
> As far as I remember we tried to delete some TTCN-2 matching
> mechanisms
> in TTCN-3, because we thought they were not used and we might have a
> chance get rid of some unused stuff. However, after a while some users
> detected this and found reasons for the re-introduction (they come
> up with real examples and not only with the backwards-compatability
> argument).
>
> Superset was one of these 're-introduced' matching mechanisms (I hope
> I remember correctly!). I believe if there is a difference, it is not
> intended. At least I cannot remember of any discussion to change the
> meaning.
>
> If there is a difference and if you think the current TTCN-3
> implementation is a problem, please put in a CR.
>
> Can you give me a hint to what other Email I should respond/comment?
>
> There are lots of TTCN-3 Emails in my box and I haven't had a chance
> to read them all.
>
> Regards
> Jens
>
>
>
> "Dr. Schulz Stephan" schrieb:
> >
> > Now that I see that there is still people reading/respoding
> to this mailing list :)
> >
> > I would like to bring up one more time this superste issue.
> > In short: is the difference in meaning of the superset
> operation in TTCN-2 and TTCN-3 intentional?
> >
> > Could Jens maybe comment on my earlier email?
> >
> > Thanks,
> >
> > stephan
> >
> >
>

---

>

---

> > > Hi
> > >
> > > > Dear Stephan,
> > > >
> > > > beside the fact that I believe that the example you gave is a
> > > > little bit
> > >
> > > You may find this surprising but with some tools out in the
> > > market today this actually analyzed successfully :)
> > >
> > > > buggy, I could not found the interpretive issue in the BNF
> > > > you mentioned.
> > >
> > > OK - I am not a TTCN-3 BNF expert .. neither a TTCN-3 parser
> > > implementor .. but I was looking at the below lines:
> > >
> > > 550. ConstantExpression ::= SingleConstExpression |
> > > CompoundConstExpression
> > > 551. SingleConstExpression ::= SingleExpression
> > > /* STATIC SEMANTICS - SingleConstExpression shall not contain
> > > Variables or Module parameters and
> > > shall resolve to a constant Value at compile time */
> > >
> > > And it was this semantics comment which I was a little blurry
> > > to me. When I first read this I was tempted of think of
> > > matching characters as being a short hand notation of a value
> > > list - which sounded to me as also being constant at compile time.
> > >
> > > > According to the BNF superset always reduces to
> > > SingleConstExpressions
> > > > or CompoundConstExpression. There is no place for wildcards.
> > > >
> > > > So to answer your question, yes you can not use
> wildcard matching
> > > > symbols there.
> > >
> > > Alright - then why this departure in TTCN-3 from original
> > > TTCN-2 semantics?
> > >
> > > In the TTCN-2 BNF the superset is defined as
> > >
> > > 575 superset ::= "(" ConstraintValue&Attributes ")"
> > > .... tada ..
> > >
> > > 563 ConstraintValue ::= ConstraintExpression |
> > > MatchingSymbol | ConsRef
> > >
> > >
> > > According to my understanding of the language the superset
> > > operation is meant to be used in matching .. so I Have to say
> > > that it sounds quite counterintuitive - at least to me - that
> > > this operation "forbids" the use of matching characters
> (in TTCN-3).
> > >
> > > Moikka,
> > >
> > > stephan
>
> --
>
> ======================================================================
> Dr. Jens Grabowski
> Institute for Telematics phone: +49 451 500 3723
> University of Luebeck fax: +49 451 500 3722
> Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
> (Germany) WWW: www.itm.mu-luebeck.de
> ======================================================================
>

Just a two short follow-up questions:

- Can you explain very short what your whishes are? I understand the
problems, but I do not understand what your proposal to solve these
problems is?

- Are these problems also in TTCN-2?

Regards
Jens


Stephen TOBIES schrieb:
>
> Hi,
>
> let me add Thomas' and my thoughts to this discussion. The problem that
Stephan Sch. is addressing here is that once cannot use templates in a sub-
/super-set matching expression, e.g., one cannot say
>
> type UT union {
> integer a,
> integer b,
> integer c
> }
>
> subset ( {a := ?}, {b := ?} )
>
> to express a set of/record of where no entry has the c alternative chosen.
>
> In general, it is not possible to use templates in value lists. E.g., one
cannot use the expression
>
> ( {a := ?}, {b := ?} ) to match the set of values of type UT where the c
alternative is not chosen.
>
> We cannot see a good reason why it should not be allowed to use arbitrary
template expressions in value lists.
>
> Actually, we can see one - the superset matching expression.
>
> Templates can semantically be perceived as sets of values in a straightforward
manner. A normal value used as template can be interpreted as the singleton set
containing the value, ? and * can be perceived as the set of all values of the
type in question, value lists are interpreted as the union of the interpretation
of their elements, etc. For a tempalte T, let [T] denote its interpretation as
set of values.
>
> When it comes to matching a value x against a template T, the value matches if
it is an element of the interpretation of the template, i.e., x \in [T] - so
much so good.
>
> When allowing arbitrary templates to be used in value lists, the semantic of
the value lists itself and also of the subset matching expression extendes
nicely. E.g., a set of value s matches subset (T1, T2, ... , Tn) iff S \subset
Union([T1], [T2], ..., [Tn]). No problem here.
>
> When it comes to superset, things are no longer this clear. If we use the
naive definition of when a set of value s matches superset (T1, T2, ..., Tn),
one would probably require
>
> Union ([T1], [T2], ..., [Tn]) \subset S
>
> Clearly, if T1, ..., Tn are constant expressions, this is euqivalent to the
current, operational definition of the superset matching operation.
>
> But here is the problem: Consider the following example:
>
> template boolean T1 := ?;
> template boolean T2 := true;
> template boolean T3 := false;
>
> Using the above semantics, T1 and (T2, T3) are semantically equivalent:
>
> [T1] = {true, false} = [(T2,T3)]
> [subset(T1)] = [subset (T2,T3)] = PowerMultiSet({true,false})
>
> but also
>
> [superset(T1)] = [superset (T2,T3)] = { s \in PowerMultiSet({true,false}) |
true \in s and false \in s }
>
> Is this the indended semantics of the superset matching expression???
Operationally, I would rather expect:
>
> [superset(T1)] = PowerMultiSet({true,false}) \ { emptyset }
>
> and
>
> [superset (T2,T3)] = { s \in PowerMultiSet({true,false}) | true \in s and
false \in s } as above.
>
> So, in other words - if we allow arbitrary templates in valueslists of
superset, then the intuitive semantics of templates as sets can no longer be
extended to the superset matching expression - at least not using the
straightforward semantics 'mapping' of superset.
>
> Is this really a problem - well, maybe not - currently the whole semantics of
templates is defined operationally and not using sets, and the operational
semantics extend in a straighforward manner...
>
> On the other hand, maybe then 'superset' is not the right name for the
matching expression, because it implies a set-theoretic denotation.
>
> Best regards
>
> Stephan Tobies
>
> >

---

Original Message

---

> > From: ext Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> > Sent: 26. February 2003 13:02
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Re: Superset - try II
> >
> >
> > Dear Stephan,
> >
> > to your question:
> >
> > As far as I remember we tried to delete some TTCN-2 matching
> > mechanisms
> > in TTCN-3, because we thought they were not used and we might have a
> > chance get rid of some unused stuff. However, after a while some users
> > detected this and found reasons for the re-introduction (they come
> > up with real examples and not only with the backwards-compatability
> > argument).
> >
> > Superset was one of these 're-introduced' matching mechanisms (I hope
> > I remember correctly!). I believe if there is a difference, it is not
> > intended. At least I cannot remember of any discussion to change the
> > meaning.
> >
> > If there is a difference and if you think the current TTCN-3
> > implementation is a problem, please put in a CR.
> >
> > Can you give me a hint to what other Email I should respond/comment?
> >
> > There are lots of TTCN-3 Emails in my box and I haven't had a chance
> > to read them all.
> >
> > Regards
> > Jens
> >
> >
> >
> > "Dr. Schulz Stephan" schrieb:
> > >
> > > Now that I see that there is still people reading/respoding
> > to this mailing list :)
> > >
> > > I would like to bring up one more time this superste issue.
> > > In short: is the difference in meaning of the superset
> > operation in TTCN-2 and TTCN-3 intentional?
> > >
> > > Could Jens maybe comment on my earlier email?
> > >
> > > Thanks,
> > >
> > > stephan
> > >
> > >
> >

---

> >

---

> > > > Hi
> > > >
> > > > > Dear Stephan,
> > > > >
> > > > > beside the fact that I believe that the example you gave is a
> > > > > little bit
> > > >
> > > > You may find this surprising but with some tools out in the
> > > > market today this actually analyzed successfully :)
> > > >
> > > > > buggy, I could not found the interpretive issue in the BNF
> > > > > you mentioned.
> > > >
> > > > OK - I am not a TTCN-3 BNF expert .. neither a TTCN-3 parser
> > > > implementor .. but I was looking at the below lines:
> > > >
> > > > 550. ConstantExpression ::= SingleConstExpression |
> > > > CompoundConstExpression
> > > > 551. SingleConstExpression ::= SingleExpression
> > > > /* STATIC SEMANTICS - SingleConstExpression shall not contain
> > > > Variables or Module parameters and
> > > > shall resolve to a constant Value at compile time */
> > > >
> > > > And it was this semantics comment which I was a little blurry
> > > > to me. When I first read this I was tempted of think of
> > > > matching characters as being a short hand notation of a value
> > > > list - which sounded to me as also being constant at compile time.
> > > >
> > > > > According to the BNF superset always reduces to
> > > > SingleConstExpressions
> > > > > or CompoundConstExpression. There is no place for wildcards.
> > > > >
> > > > > So to answer your question, yes you can not use
> > wildcard matching
> > > > > symbols there.
> > > >
> > > > Alright - then why this departure in TTCN-3 from original
> > > > TTCN-2 semantics?
> > > >
> > > > In the TTCN-2 BNF the superset is defined as
> > > >
> > > > 575 superset ::= "(" ConstraintValue&Attributes ")"
> > > > .... tada ..
> > > >
> > > > 563 ConstraintValue ::= ConstraintExpression |
> > > > MatchingSymbol | ConsRef
> > > >
> > > >
> > > > According to my understanding of the language the superset
> > > > operation is meant to be used in matching .. so I Have to say
> > > > that it sounds quite counterintuitive - at least to me - that
> > > > this operation "forbids" the use of matching characters
> > (in TTCN-3).
> > > >
> > > > Moikka,
> > > >
> > > > stephan
> >
> > --
> >
> > ======================================================================
> > Dr. Jens Grabowski
> > Institute for Telematics phone: +49 451 500 3723
> > University of Luebeck fax: +49 451 500 3722
> > Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
> > (Germany) WWW: www.itm.mu-luebeck.de
> > ======================================================================
> >

--

======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================

Well, first of all, discuss a bit... Eventually, I would like to see the ValueList to be extended so that arbitrary templates can specified in a value list. Yet, I am not sure what to do about the superset in this case.

I don't know TTCN-2 enough to tell whether the problem exists there or not.

BR

Stephan

>

---

Original Message

---

> From: ext Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 26. February 2003 14:50
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Superset - try II
>
>
> Just a two short follow-up questions:
>
> - Can you explain very short what your whishes are? I understand the
> problems, but I do not understand what your proposal to solve these
> problems is?
>
> - Are these problems also in TTCN-2?
>
> Regards
> Jens
>
>
> Stephen TOBIES schrieb:
> >
> > Hi,
> >
> > let me add Thomas' and my thoughts to this discussion. The
> problem that Stephan Sch. is addressing here is that once
> cannot use templates in a sub-/super-set matching expression,
> e.g., one cannot say
> >
> > type UT union {
> > integer a,
> > integer b,
> > integer c
> > }
> >
> > subset ( {a := ?}, {b := ?} )
> >
> > to express a set of/record of where no entry has the c
> alternative chosen.
> >
> > In general, it is not possible to use templates in value
> lists. E.g., one cannot use the expression
> >
> > ( {a := ?}, {b := ?} ) to match the set of values of type
> UT where the c alternative is not chosen.
> >
> > We cannot see a good reason why it should not be allowed to
> use arbitrary template expressions in value lists.
> >
> > Actually, we can see one - the superset matching expression.
> >
> > Templates can semantically be perceived as sets of values
> in a straightforward manner. A normal value used as template
> can be interpreted as the singleton set containing the value,
> ? and * can be perceived as the set of all values of the type
> in question, value lists are interpreted as the union of the
> interpretation of their elements, etc. For a tempalte T, let
> [T] denote its interpretation as set of values.
> >
> > When it comes to matching a value x against a template T,
> the value matches if it is an element of the interpretation
> of the template, i.e., x \in [T] - so much so good.
> >
> > When allowing arbitrary templates to be used in value
> lists, the semantic of the value lists itself and also of the
> subset matching expression extendes nicely. E.g., a set of
> value s matches subset (T1, T2, ... , Tn) iff S \subset
> Union([T1], [T2], ..., [Tn]). No problem here.
> >
> > When it comes to superset, things are no longer this clear.
> If we use the naive definition of when a set of value s
> matches superset (T1, T2, ..., Tn), one would probably require
> >
> > Union ([T1], [T2], ..., [Tn]) \subset S
> >
> > Clearly, if T1, ..., Tn are constant expressions, this is
> euqivalent to the current, operational definition of the
> superset matching operation.
> >
> > But here is the problem: Consider the following example:
> >
> > template boolean T1 := ?;
> > template boolean T2 := true;
> > template boolean T3 := false;
> >
> > Using the above semantics, T1 and (T2, T3) are semantically
> equivalent:
> >
> > [T1] = {true, false} = [(T2,T3)]
> > [subset(T1)] = [subset (T2,T3)] = PowerMultiSet({true,false})
> >
> > but also
> >
> > [superset(T1)] = [superset (T2,T3)] = { s \in
> PowerMultiSet({true,false}) | true \in s and false \in s }
> >
> > Is this the indended semantics of the superset matching
> expression??? Operationally, I would rather expect:
> >
> > [superset(T1)] = PowerMultiSet({true,false}) \ { emptyset }
> >
> > and
> >
> > [superset (T2,T3)] = { s \in PowerMultiSet({true,false}) |
> true \in s and false \in s } as above.
> >
> > So, in other words - if we allow arbitrary templates in
> valueslists of superset, then the intuitive semantics of
> templates as sets can no longer be extended to the superset
> matching expression - at least not using the straightforward
> semantics 'mapping' of superset.
> >
> > Is this really a problem - well, maybe not - currently the
> whole semantics of templates is defined operationally and not
> using sets, and the operational semantics extend in a
> straighforward manner...
> >
> > On the other hand, maybe then 'superset' is not the right
> name for the matching expression, because it implies a
> set-theoretic denotation.
> >
> > Best regards
> >
> > Stephan Tobies
> >
> > >

---

Original Message

---

> > > From: ext Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> > > Sent: 26. February 2003 13:02
> > > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > > Subject: Re: Superset - try II
> > >
> > >
> > > Dear Stephan,
> > >
> > > to your question:
> > >
> > > As far as I remember we tried to delete some TTCN-2 matching
> > > mechanisms
> > > in TTCN-3, because we thought they were not used and we
> might have a
> > > chance get rid of some unused stuff. However, after a
> while some users
> > > detected this and found reasons for the re-introduction (they come
> > > up with real examples and not only with the
> backwards-compatability
> > > argument).
> > >
> > > Superset was one of these 're-introduced' matching
> mechanisms (I hope
> > > I remember correctly!). I believe if there is a
> difference, it is not
> > > intended. At least I cannot remember of any discussion to
> change the
> > > meaning.
> > >
> > > If there is a difference and if you think the current TTCN-3
> > > implementation is a problem, please put in a CR.
> > >
> > > Can you give me a hint to what other Email I should
> respond/comment?
> > >
> > > There are lots of TTCN-3 Emails in my box and I haven't
> had a chance
> > > to read them all.
> > >
> > > Regards
> > > Jens
> > >
> > >
> > >
> > > "Dr. Schulz Stephan" schrieb:
> > > >
> > > > Now that I see that there is still people reading/respoding
> > > to this mailing list :)
> > > >
> > > > I would like to bring up one more time this superste issue.
> > > > In short: is the difference in meaning of the superset
> > > operation in TTCN-2 and TTCN-3 intentional?
> > > >
> > > > Could Jens maybe comment on my earlier email?
> > > >
> > > > Thanks,
> > > >
> > > > stephan
> > > >
> > > >
> > >

---

> > >

---

> > > > > Hi
> > > > >
> > > > > > Dear Stephan,
> > > > > >
> > > > > > beside the fact that I believe that the example you
> gave is a
> > > > > > little bit
> > > > >
> > > > > You may find this surprising but with some tools out in the
> > > > > market today this actually analyzed successfully :)
> > > > >
> > > > > > buggy, I could not found the interpretive issue in the BNF
> > > > > > you mentioned.
> > > > >
> > > > > OK - I am not a TTCN-3 BNF expert .. neither a TTCN-3 parser
> > > > > implementor .. but I was looking at the below lines:
> > > > >
> > > > > 550. ConstantExpression ::= SingleConstExpression |
> > > > > CompoundConstExpression
> > > > > 551. SingleConstExpression ::= SingleExpression
> > > > > /* STATIC SEMANTICS - SingleConstExpression shall not contain
> > > > > Variables or Module parameters and
> > > > > shall resolve to a constant Value at compile time */
> > > > >
> > > > > And it was this semantics comment which I was a little blurry
> > > > > to me. When I first read this I was tempted of think of
> > > > > matching characters as being a short hand notation of a value
> > > > > list - which sounded to me as also being constant at
> compile time.
> > > > >
> > > > > > According to the BNF superset always reduces to
> > > > > SingleConstExpressions
> > > > > > or CompoundConstExpression. There is no place for wildcards.
> > > > > >
> > > > > > So to answer your question, yes you can not use
> > > wildcard matching
> > > > > > symbols there.
> > > > >
> > > > > Alright - then why this departure in TTCN-3 from original
> > > > > TTCN-2 semantics?
> > > > >
> > > > > In the TTCN-2 BNF the superset is defined as
> > > > >
> > > > > 575 superset ::= "(" ConstraintValue&Attributes ")"
> > > > > .... tada ..
> > > > >
> > > > > 563 ConstraintValue ::= ConstraintExpression |
> > > > > MatchingSymbol | ConsRef
> > > > >
> > > > >
> > > > > According to my understanding of the language the superset
> > > > > operation is meant to be used in matching .. so I Have to say
> > > > > that it sounds quite counterintuitive - at least to me - that
> > > > > this operation "forbids" the use of matching characters
> > > (in TTCN-3).
> > > > >
> > > > > Moikka,
> > > > >
> > > > > stephan
> > >
> > > --
> > >
> > >
> ======================================================================
> > > Dr. Jens Grabowski
> > > Institute for Telematics phone: +49 451 500 3723
> > > University of Luebeck fax: +49 451 500 3722
> > > Ratzeburger Allee 160 eMail:
> This email address is being protected from spambots. You need JavaScript enabled to view it.
> > > D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
> > > (Germany) WWW:
www.itm.mu-luebeck.de
> > ======================================================================
> >

--

======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================

Hi Stephan,

I have at the moment not much time for long Email discussions, but
at least I try to explain my standpoint on this.

First of all, I might not be the right person to discuss the superset
issue, because I was in favour to delete this matching mechanism, even
though TTCN-3 would have small compatability problems with TTCN-2.
I think that TTCN-3 was not that successful in deleting unused or
rarely used features of TTCN-2. However, this is a general problem of
standardization.

Concerning the problem you mention, I believe it has nothing directly
to do with superset. The general question is 'What are templates?'.

A template is not a value and therefore it cannot be put into a
ValueList and this is the reason for the problem.

Theoretically, you may consider a template as a subtype of some type,
because it defines a set of values. This view OK for me.

The reason not to use the subtyping mechanism was to avoid cluttering
the types in a module with the test data and to avoid to prescribe the
use of the typechecking mechanism for matching.

I think that putting templates and matching mechanisms on another
level of abstraction would require a complete redesign of the data
part of TTCN-3 and possibly of the whole language.

Concerning this valueList problem, there might be two possiblities
to resolve this issue.

- The first possibility is to find a generalization
of valueList, which allows to use matching mechanisms. This might
be possible, but I think it might be good to change the terminology.
(You mentioned this possiblity already.)

- The second possiblitiy is to extend the language with an operation
that constructs a set with all values of a specific template.
This operation would be a generalization of the valueof-Operation
defined in Section 14.9 of the TTCN-3 core notation document.
With this operation you are able to construct all values for a
given template that includes matching mechanisms.

That's all I can say for the moment.

Regards
Jens







Stephen TOBIES schrieb:
>
> Well, first of all, discuss a bit... Eventually, I would like to see the
ValueList to be extended so that arbitrary templates can specified in a value
list. Yet, I am not sure what to do about the superset in this case.
>
> I don't know TTCN-2 enough to tell whether the problem exists there or not.
>
> BR
>
> Stephan
>
> >

---

Original Message

---

> > From: ext Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> > Sent: 26. February 2003 14:50
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Re: Superset - try II
> >
> >
> > Just a two short follow-up questions:
> >
> > - Can you explain very short what your whishes are? I understand the
> > problems, but I do not understand what your proposal to solve these
> > problems is?
> >
> > - Are these problems also in TTCN-2?
> >
> > Regards
> > Jens
> >
> >
> > Stephen TOBIES schrieb:
> > >
> > > Hi,
> > >
> > > let me add Thomas' and my thoughts to this discussion. The
> > problem that Stephan Sch. is addressing here is that once
> > cannot use templates in a sub-/super-set matching expression,
> > e.g., one cannot say
> > >
> > > type UT union {
> > > integer a,
> > > integer b,
> > > integer c
> > > }
> > >
> > > subset ( {a := ?}, {b := ?} )
> > >
> > > to express a set of/record of where no entry has the c
> > alternative chosen.
> > >
> > > In general, it is not possible to use templates in value
> > lists. E.g., one cannot use the expression
> > >
> > > ( {a := ?}, {b := ?} ) to match the set of values of type
> > UT where the c alternative is not chosen.
> > >
> > > We cannot see a good reason why it should not be allowed to
> > use arbitrary template expressions in value lists.
> > >
> > > Actually, we can see one - the superset matching expression.
> > >
> > > Templates can semantically be perceived as sets of values
> > in a straightforward manner. A normal value used as template
> > can be interpreted as the singleton set containing the value,
> > ? and * can be perceived as the set of all values of the type
> > in question, value lists are interpreted as the union of the
> > interpretation of their elements, etc. For a tempalte T, let
> > [T] denote its interpretation as set of values.
> > >
> > > When it comes to matching a value x against a template T,
> > the value matches if it is an element of the interpretation
> > of the template, i.e., x \in [T] - so much so good.
> > >
> > > When allowing arbitrary templates to be used in value
> > lists, the semantic of the value lists itself and also of the
> > subset matching expression extendes nicely. E.g., a set of
> > value s matches subset (T1, T2, ... , Tn) iff S \subset
> > Union([T1], [T2], ..., [Tn]). No problem here.
> > >
> > > When it comes to superset, things are no longer this clear.
> > If we use the naive definition of when a set of value s
> > matches superset (T1, T2, ..., Tn), one would probably require
> > >
> > > Union ([T1], [T2], ..., [Tn]) \subset S
> > >
> > > Clearly, if T1, ..., Tn are constant expressions, this is
> > euqivalent to the current, operational definition of the
> > superset matching operation.
> > >
> > > But here is the problem: Consider the following example:
> > >
> > > template boolean T1 := ?;
> > > template boolean T2 := true;
> > > template boolean T3 := false;
> > >
> > > Using the above semantics, T1 and (T2, T3) are semantically
> > equivalent:
> > >
> > > [T1] = {true, false} = [(T2,T3)]
> > > [subset(T1)] = [subset (T2,T3)] = PowerMultiSet({true,false})
> > >
> > > but also
> > >
> > > [superset(T1)] = [superset (T2,T3)] = { s \in
> > PowerMultiSet({true,false}) | true \in s and false \in s }
> > >
> > > Is this the indended semantics of the superset matching
> > expression??? Operationally, I would rather expect:
> > >
> > > [superset(T1)] = PowerMultiSet({true,false}) \ { emptyset }
> > >
> > > and
> > >
> > > [superset (T2,T3)] = { s \in PowerMultiSet({true,false}) |
> > true \in s and false \in s } as above.
> > >
> > > So, in other words - if we allow arbitrary templates in
> > valueslists of superset, then the intuitive semantics of
> > templates as sets can no longer be extended to the superset
> > matching expression - at least not using the straightforward
> > semantics 'mapping' of superset.
> > >
> > > Is this really a problem - well, maybe not - currently the
> > whole semantics of templates is defined operationally and not
> > using sets, and the operational semantics extend in a
> > straighforward manner...
> > >
> > > On the other hand, maybe then 'superset' is not the right
> > name for the matching expression, because it implies a
> > set-theoretic denotation.
> > >
> > > Best regards
> > >
> > > Stephan Tobies
> > >
> > > >

---

Original Message

---

> > > > From: ext Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> > > > Sent: 26. February 2003 13:02
> > > > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > > > Subject: Re: Superset - try II
> > > >
> > > >
> > > > Dear Stephan,
> > > >
> > > > to your question:
> > > >
> > > > As far as I remember we tried to delete some TTCN-2 matching
> > > > mechanisms
> > > > in TTCN-3, because we thought they were not used and we
> > might have a
> > > > chance get rid of some unused stuff. However, after a
> > while some users
> > > > detected this and found reasons for the re-introduction (they come
> > > > up with real examples and not only with the
> > backwards-compatability
> > > > argument).
> > > >
> > > > Superset was one of these 're-introduced' matching
> > mechanisms (I hope
> > > > I remember correctly!). I believe if there is a
> > difference, it is not
> > > > intended. At least I cannot remember of any discussion to
> > change the
> > > > meaning.
> > > >
> > > > If there is a difference and if you think the current TTCN-3
> > > > implementation is a problem, please put in a CR.
> > > >
> > > > Can you give me a hint to what other Email I should
> > respond/comment?
> > > >
> > > > There are lots of TTCN-3 Emails in my box and I haven't
> > had a chance
> > > > to read them all.
> > > >
> > > > Regards
> > > > Jens
> > > >
> > > >
> > > >
> > > > "Dr. Schulz Stephan" schrieb:
> > > > >
> > > > > Now that I see that there is still people reading/respoding
> > > > to this mailing list :)
> > > > >
> > > > > I would like to bring up one more time this superste issue.
> > > > > In short: is the difference in meaning of the superset
> > > > operation in TTCN-2 and TTCN-3 intentional?
> > > > >
> > > > > Could Jens maybe comment on my earlier email?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > stephan
> > > > >
> > > > >
> > > >

---

> > > >

---

> > > > > > Hi
> > > > > >
> > > > > > > Dear Stephan,
> > > > > > >
> > > > > > > beside the fact that I believe that the example you
> > gave is a
> > > > > > > little bit
> > > > > >
> > > > > > You may find this surprising but with some tools out in the
> > > > > > market today this actually analyzed successfully :)
> > > > > >
> > > > > > > buggy, I could not found the interpretive issue in the BNF
> > > > > > > you mentioned.
> > > > > >
> > > > > > OK - I am not a TTCN-3 BNF expert .. neither a TTCN-3 parser
> > > > > > implementor .. but I was looking at the below lines:
> > > > > >
> > > > > > 550. ConstantExpression ::= SingleConstExpression |
> > > > > > CompoundConstExpression
> > > > > > 551. SingleConstExpression ::= SingleExpression
> > > > > > /* STATIC SEMANTICS - SingleConstExpression shall not contain
> > > > > > Variables or Module parameters and
> > > > > > shall resolve to a constant Value at compile time */
> > > > > >
> > > > > > And it was this semantics comment which I was a little blurry
> > > > > > to me. When I first read this I was tempted of think of
> > > > > > matching characters as being a short hand notation of a value
> > > > > > list - which sounded to me as also being constant at
> > compile time.
> > > > > >
> > > > > > > According to the BNF superset always reduces to
> > > > > > SingleConstExpressions
> > > > > > > or CompoundConstExpression. There is no place for wildcards.
> > > > > > >
> > > > > > > So to answer your question, yes you can not use
> > > > wildcard matching
> > > > > > > symbols there.
> > > > > >
> > > > > > Alright - then why this departure in TTCN-3 from original
> > > > > > TTCN-2 semantics?
> > > > > >
> > > > > > In the TTCN-2 BNF the superset is defined as
> > > > > >
> > > > > > 575 superset ::= "(" ConstraintValue&Attributes ")"
> > > > > > .... tada ..
> > > > > >
> > > > > > 563 ConstraintValue ::= ConstraintExpression |
> > > > > > MatchingSymbol | ConsRef
> > > > > >
> > > > > >
> > > > > > According to my understanding of the language the superset
> > > > > > operation is meant to be used in matching .. so I Have to say
> > > > > > that it sounds quite counterintuitive - at least to me - that
> > > > > > this operation "forbids" the use of matching characters
> > > > (in TTCN-3).
> > > > > >
> > > > > > Moikka,
> > > > > >
> > > > > > stephan
> > > >
> > > > --
> > > >
> > > >
> > ======================================================================
> > > > Dr. Jens Grabowski
> > > > Institute for Telematics phone: +49 451 500 3723
> > > > University of Luebeck fax: +49 451 500 3722
> > > > Ratzeburger Allee 160 eMail:
> > This email address is being protected from spambots. You need JavaScript enabled to view it.
> > > > D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
> > > > (Germany) WWW:
> www.itm.mu-luebeck.de
> > > ======================================================================
> > >
>
> --
>
> ======================================================================
> Dr. Jens Grabowski
> Institute for Telematics phone: +49 451 500 3723
> University of Luebeck fax: +49 451 500 3722
> Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
> (Germany) WWW: www.itm.mu-luebeck.de
> ======================================================================

--

======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================