Hi,

Is it a real problem?

It seems to me a theoretical one, as a test case with a default, which has sending on its top level is useless. As normally you have nothing in your receive buffer when the test case started, execution will run to the default momentarily. Even if you return from the default, the execution will run to it each time a new snapshot is taken and the receive buffer is empty (more preciselly, none of the expected message is received) or a new alternative branch is entered (as normally the execution has to wait a little for the expected message). The situation is similar if a default is activated by ACTIVATE in TTCN-2. So, such TTCN-2 code - even if not forbidden in the standard (by my mind it should be) - would jeopardize any test execution.

So, I have some doubt if anyone ever has written something like this.

Best Regards, György
Szia, Gyuri
============================================
dr. György RÉTHY
Ericsson Communications Systems Hungary Lim.
Conformance Center
tel.: +36 1 437-7006; fax: +36 1 437-7767
mobile: +36 30 297-7862
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
intranet: conformancelab.ericsson.se
personal: www.r.eth.ericsson.se/~ethgry
============================================


>

---

Original Message

---

>From: Johan Nordin [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Friday, February 22, 2002 3:57 PM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Teststeps...
>
>
>Hello all,
>
>I think I have found a problem concerning test steps in TTCN-3:
>
>1) An alternative (alt statement) cannot contain sending operations.
> In other words, all branches must be receiving operations.
>
>2) A test step follows the same syntactical rules as an alternative,
> and so cannot begin its execution by a sending operation...
>
>3) A Default must be a test step.
>
>=> This causes my headache when it comes to translating TTCN-2
>to TTCN-3,
> as the former notation indeed allows both defaults and test steps to
> start out by sending a PDU/ASP. I know it isn't very common for
> defaults to do this, but it does happen on occasion.
>
> If we were only talking about TTCN-2 test steps, the
>problem would not
> be very serious, as they can all be translated into TTCN-3
>functions,
> but the whole thing about Defaults makes things a lot more
>complicated.
>
>Does anyone have any thoughts on this?
>
>Have a good weekend!
>/Johan
>
>

---

>Telelogic Tau 4.3 - makes requirements visible during
>UML development!
>Read more about it at www.telelogic.com/tau43
>

---

>Johan Nordin
>Standardization Specialist, Uppsala Development Lab
>Telelogic AB
>S:t Persgatan 13
>SE-75320 Uppsala, Sweden
>
>Phone: +46 18 661865
>Fax: +46 18 661870
>Mobile: +46 706 424711
>
>This email address is being protected from spambots. You need JavaScript enabled to view it.
>www.telelogic.com
>

---

>Telelogic - Putting you ahead in software development!
>

---

>

Dear Johan,

I think you identified indeed an issue that prevents from translating
TTCN-2 to TTCN-3 too easily. The reason is that in TTCN-2, as we all know,
we had the macro expansion semantics for both test steps and defaults.

If in case you have a default that starts with something else than a
receive-event (send, assignment, etc) in TTCN-2 this statement would always
be successful and would therefore lead to the next indentation within the
default and for this to the next snapshot. So there is no harm in
translating this into a function and ignoring everything else in parallel
to the non-receive statement. (In fact an analyzer would have found these
unreachable statements anyhow).

So you are done, without breaking the snapshot semantics in both worlds.

Best regards,

Theo



At 15:57 22.02.2002, Johan Nordin wrote:
>Hello all,
>
>I think I have found a problem concerning test steps in TTCN-3:
>
>1) An alternative (alt statement) cannot contain sending operations.
> In other words, all branches must be receiving operations.
>
>2) A test step follows the same syntactical rules as an alternative,
> and so cannot begin its execution by a sending operation...
>
>3) A Default must be a test step.
>
>=> This causes my headache when it comes to translating TTCN-2 to TTCN-3,
> as the former notation indeed allows both defaults and test steps to
> start out by sending a PDU/ASP. I know it isn't very common for
> defaults to do this, but it does happen on occasion.
>
> If we were only talking about TTCN-2 test steps, the problem would not
> be very serious, as they can all be translated into TTCN-3 functions,
> but the whole thing about Defaults makes things a lot more complicated.
>
>Does anyone have any thoughts on this?
>
>Have a good weekend!
>/Johan
>
>

---

>Telelogic Tau 4.3 - makes requirements visible during
>UML development!
>Read more about it at www.telelogic.com/tau43
>

---

>Johan Nordin
>Standardization Specialist, Uppsala Development Lab
>Telelogic AB
>S:t Persgatan 13
>SE-75320 Uppsala, Sweden
>
>Phone: +46 18 661865
>Fax: +46 18 661870
>Mobile: +46 706 424711
>
>This email address is being protected from spambots. You need JavaScript enabled to view it.
>www.telelogic.com
>

---

>Telelogic - Putting you ahead in software development!
>

---

Hello Theo, long time no C...

Hm, I'm not sure I follow your reasoning here:

> So there is no harm intranslating this into a function

Translate what into a function? A function cannot be activated
as a default.
Maybe I have misunderstood what you meant, can you illustrate
this with an example?

Regards,
/Johan

---

Original Message

---

From: Theofanis Vassiliou-Gioles [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 22 februari 2002 16:40
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Teststeps...


Dear Johan,

I think you identified indeed an issue that prevents from translating
TTCN-2 to TTCN-3 too easily. The reason is that in TTCN-2, as we all know,
we had the macro expansion semantics for both test steps and defaults.

If in case you have a default that starts with something else than a
receive-event (send, assignment, etc) in TTCN-2 this statement would always
be successful and would therefore lead to the next indentation within the
default and for this to the next snapshot. So there is no harm in
translating this into a function and ignoring everything else in parallel
to the non-receive statement. (In fact an analyzer would have found these
unreachable statements anyhow).

So you are done, without breaking the snapshot semantics in both worlds.

Best regards,

Theo



At 15:57 22.02.2002, Johan Nordin wrote:
>Hello all,
>
>I think I have found a problem concerning test steps in TTCN-3:
>
>1) An alternative (alt statement) cannot contain sending operations.
> In other words, all branches must be receiving operations.
>
>2) A test step follows the same syntactical rules as an alternative,
> and so cannot begin its execution by a sending operation...
>
>3) A Default must be a test step.
>
>=> This causes my headache when it comes to translating TTCN-2 to TTCN-3,
> as the former notation indeed allows both defaults and test steps to
> start out by sending a PDU/ASP. I know it isn't very common for
> defaults to do this, but it does happen on occasion.
>
> If we were only talking about TTCN-2 test steps, the problem would not
> be very serious, as they can all be translated into TTCN-3 functions,
> but the whole thing about Defaults makes things a lot more complicated.
>
>Does anyone have any thoughts on this?
>
>Have a good weekend!
>/Johan
>
>

---

>Telelogic Tau 4.3 - makes requirements visible during
>UML development!
>Read more about it at www.telelogic.com/tau43
>

---

>Johan Nordin
>Standardization Specialist, Uppsala Development Lab
>Telelogic AB
>S:t Persgatan 13
>SE-75320 Uppsala, Sweden
>
>Phone: +46 18 661865
>Fax: +46 18 661870
>Mobile: +46 706 424711
>
>This email address is being protected from spambots. You need JavaScript enabled to view it.
>www.telelogic.com
>

---

>Telelogic - Putting you ahead in software development!
>

---

Hi Johan,

this is what I meant, saying there is no "easy" way of translating. In your
special case you could not translate the default to something that can be
activated. Instead you have to translate it context-sensitive by using
functions in the correct place.

Although I understand your concerns (and have seen myself this type of test
suite you are referring to,) Georgy's ideas should not be neglected. Please
see my comments below.

Georgy wrote ...
>It seems to me a theoretical one, as a test case with a default, which has
>sending on its top level is useless.

Agreed, but ... ;-)

>As normally you have nothing in your receive buffer when the test case
>started, execution will run to the default momentarily.

Hmmm. My understanding is that a snapshot will be taken, and then the first
*line* will be executed. So if the line, for example an assignment was
successful you will proceed to the next indentation and then take the next
snapshot. So if, e.g. the is a send statement, by definition the send will
be successful and you will be proceed to the next indentation and so on. So
in most cases you will not run into the default.

The only thing I am not 100% sure is before the execution of the first
line, wether a default will be evaluated or not.

>Even if you return from the default, the execution will run to it each
>time a new snapshot is taken and the receive buffer is empty (more
>preciselly, none of the expected message is received) or a new alternative
>branch is entered (as normally the execution has to wait a little for the
>expected message).

Disagreed, see above.

>The situation is similar if a default is activated by ACTIVATE in TTCN-2.
>So, such TTCN-2 code - even if not forbidden in the standard (by my mind
>it should be) - would jeopardize any test execution.
Not necessarily but I fear that test suite writers who wrote something like
this had a certain test execution model in mind, like "blocking at the
snapshot until something has been received or a timer times out AND
snapshot or only taken when there is no other progress" :-(

But you are right that you would jeopardize the test execution if another
test execution model has been chosen, e.g. "polling your receive and timer
queues and then process all alternatives." This would of course include
then the default, too.

Taking this into account raises the question: "What was intended by the
test suite writer in writing this type of default".

So the translation is then, per definition, context-sensitive and there is
no straight forward translation.

Best regards,

Theo

At 17:19 22.02.2002, Johan Nordin wrote:
>Hello Theo, long time no C...
>
>Hm, I'm not sure I follow your reasoning here:
>
> > So there is no harm intranslating this into a function
>
>Translate what into a function? A function cannot be activated
>as a default.
>Maybe I have misunderstood what you meant, can you illustrate
>this with an example?
>
>Regards,
>/Johan
>
>
>
>

---

Original Message

---

>From: Theofanis Vassiliou-Gioles [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: den 22 februari 2002 16:40
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: Teststeps...
>
>
>Dear Johan,
>
>I think you identified indeed an issue that prevents from translating
>TTCN-2 to TTCN-3 too easily. The reason is that in TTCN-2, as we all know,
>we had the macro expansion semantics for both test steps and defaults.
>
>If in case you have a default that starts with something else than a
>receive-event (send, assignment, etc) in TTCN-2 this statement would always
>be successful and would therefore lead to the next indentation within the
>default and for this to the next snapshot. So there is no harm in
>translating this into a function and ignoring everything else in parallel
>to the non-receive statement. (In fact an analyzer would have found these
>unreachable statements anyhow).
>
>So you are done, without breaking the snapshot semantics in both worlds.
>
>Best regards,
>
>Theo
>
>
>
>At 15:57 22.02.2002, Johan Nordin wrote:
> >Hello all,
> >
> >I think I have found a problem concerning test steps in TTCN-3:
> >
> >1) An alternative (alt statement) cannot contain sending operations.
> > In other words, all branches must be receiving operations.
> >
> >2) A test step follows the same syntactical rules as an alternative,
> > and so cannot begin its execution by a sending operation...
> >
> >3) A Default must be a test step.
> >
> >=> This causes my headache when it comes to translating TTCN-2 to TTCN-3,
> > as the former notation indeed allows both defaults and test steps to
> > start out by sending a PDU/ASP. I know it isn't very common for
> > defaults to do this, but it does happen on occasion.
> >
> > If we were only talking about TTCN-2 test steps, the problem would not
> > be very serious, as they can all be translated into TTCN-3 functions,
> > but the whole thing about Defaults makes things a lot more complicated.
> >
> >Does anyone have any thoughts on this?
> >
> >Have a good weekend!
> >/Johan
> >
> >

---

> >Telelogic Tau 4.3 - makes requirements visible during
> >UML development!
> >Read more about it at www.telelogic.com/tau43
> >

---

> >Johan Nordin
> >Standardization Specialist, Uppsala Development Lab
> >Telelogic AB
> >S:t Persgatan 13
> >SE-75320 Uppsala, Sweden
> >
> >Phone: +46 18 661865
> >Fax: +46 18 661870
> >Mobile: +46 706 424711
> >
> >This email address is being protected from spambots. You need JavaScript enabled to view it.
> >www.telelogic.com
> >

---

> >Telelogic - Putting you ahead in software development!
> >

---

Hi Johan,

we make no restrictions about the structure of the top alternatives
in teststeps or altsteps (as they are called now).

Therefore, if your default starts with sending operation specify
a teststep that starts with an else branch and activate it as
default. This branch will always been taken when this default
is executed, i.e., top branches following the else branch will
never be executed and default that are activated later then the
default with the else branch only will never be executed.

For example:

altstep MyStrangeDefault() {

[else] {
PCO.send ...
....
}
} \\ end altstep


Best regards

Jens

Johan Nordin schrieb:
>
> Hello all,
>
> I think I have found a problem concerning test steps in TTCN-3:
>
> 1) An alternative (alt statement) cannot contain sending operations.
> In other words, all branches must be receiving operations.
>
> 2) A test step follows the same syntactical rules as an alternative,
> and so cannot begin its execution by a sending operation...
>
> 3) A Default must be a test step.
>
> => This causes my headache when it comes to translating TTCN-2 to TTCN-3,
> as the former notation indeed allows both defaults and test steps to
> start out by sending a PDU/ASP. I know it isn't very common for
> defaults to do this, but it does happen on occasion.
>
> If we were only talking about TTCN-2 test steps, the problem would not
> be very serious, as they can all be translated into TTCN-3 functions,
> but the whole thing about Defaults makes things a lot more complicated.
>
> Does anyone have any thoughts on this?
>
> Have a good weekend!
> /Johan
>
>

---

> Telelogic Tau 4.3 - makes requirements visible during
> UML development!
> Read more about it at www.telelogic.com/tau43
>

---

> Johan Nordin
> Standardization Specialist, Uppsala Development Lab
> Telelogic AB
> S:t Persgatan 13
> SE-75320 Uppsala, Sweden
>
> Phone: +46 18 661865
> Fax: +46 18 661870
> Mobile: +46 706 424711
>
> This email address is being protected from spambots. You need JavaScript enabled to view it.
> www.telelogic.com
>

---

> Telelogic - Putting you ahead in software development!
>

---

--

======================================================================
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,

I do not agree. When you start a test case a snapshot is taken (naturally the default is looked at as the last alternative at each level). Even if you have some assignments, evaluations, sending at the top level (or even on the few top levels) execution shall come very quickly to a set of alternatives where you expect to receive messages. If no message has arrived when the snapshot for this set of alternatives is taken, you will run to the default (as none of the receive branches are matching). This will happen in real systems practically independly on what you had at higher levels (e.g. sending at the top level), because the test execution is (should be) quicker than the IUT is able to respond (plus transfer etc).

So, my opinion is, that the behaviour I described, normally will not depend on the level of the receive branch (is it at the top level or a few levels below).

But otherwise I agree. If there was any test suite using sending at the top level of default, there is no (and should not be) a straight conversion to a TTCN-3 default.

However, converting this to a function gives a DIFFERENT BEHAVIOR IN TTCN-3! When calling an altstep (test step) or a default in TTCN-2, the evaluation of the same snapshot is continued. This is not the case with a function, you can not continue the evaluation of the same snapshot but has to take a new one!

Best Regards, György

============================================
dr. György RÉTHY
Ericsson Communications Systems Hungary Lim.
Conformance Center
tel.: +36 1 437-7006; fax: +36 1 437-7767
mobile: +36 30 297-7862
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
intranet: conformancelab.ericsson.se
personal: www.r.eth.ericsson.se/~ethgry
============================================


>

---

Original Message

---

>From: Theofanis Vassiliou-Gioles [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Friday, February 22, 2002 6:12 PM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: Teststeps...
>
>
>Hi Johan,
>
>this is what I meant, saying there is no "easy" way of
>translating. In your
>special case you could not translate the default to something
>that can be
>activated. Instead you have to translate it context-sensitive by using
>functions in the correct place.
>
>Although I understand your concerns (and have seen myself this
>type of test
>suite you are referring to,) Georgy's ideas should not be
>neglected. Please
>see my comments below.
>
>Georgy wrote ...
>>It seems to me a theoretical one, as a test case with a
>default, which has
>>sending on its top level is useless.
>
>Agreed, but ... ;-)
>
>>As normally you have nothing in your receive buffer when the test case
>>started, execution will run to the default momentarily.
>
>Hmmm. My understanding is that a snapshot will be taken, and
>then the first
>*line* will be executed. So if the line, for example an assignment was
>successful you will proceed to the next indentation and then
>take the next
>snapshot. So if, e.g. the is a send statement, by definition
>the send will
>be successful and you will be proceed to the next indentation
>and so on. So
>in most cases you will not run into the default.
>
>The only thing I am not 100% sure is before the execution of the first
>line, wether a default will be evaluated or not.
>
>>Even if you return from the default, the execution will run to it each
>>time a new snapshot is taken and the receive buffer is empty (more
>>preciselly, none of the expected message is received) or a
>new alternative
>>branch is entered (as normally the execution has to wait a
>little for the
>>expected message).
>
>Disagreed, see above.
>
>>The situation is similar if a default is activated by
>ACTIVATE in TTCN-2.
>>So, such TTCN-2 code - even if not forbidden in the standard
>(by my mind
>>it should be) - would jeopardize any test execution.
>Not necessarily but I fear that test suite writers who wrote
>something like
>this had a certain test execution model in mind, like "blocking at the
>snapshot until something has been received or a timer times out AND
>snapshot or only taken when there is no other progress" :-(
>
>But you are right that you would jeopardize the test execution
>if another
>test execution model has been chosen, e.g. "polling your
>receive and timer
>queues and then process all alternatives." This would of course include
>then the default, too.
>
>Taking this into account raises the question: "What was intended by the
>test suite writer in writing this type of default".
>
>So the translation is then, per definition, context-sensitive
>and there is
>no straight forward translation.
>
>Best regards,
>
>Theo
>
>At 17:19 22.02.2002, Johan Nordin wrote:
>>Hello Theo, long time no C...
>>
>>Hm, I'm not sure I follow your reasoning here:
>>
>> > So there is no harm intranslating this into a function
>>
>>Translate what into a function? A function cannot be activated
>>as a default.
>>Maybe I have misunderstood what you meant, can you illustrate
>>this with an example?
>>
>>Regards,
>>/Johan
>>
>>
>>
>>

---

Original Message

---

>>From: Theofanis Vassiliou-Gioles [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>>Sent: den 22 februari 2002 16:40
>>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>Subject: Re: Teststeps...
>>
>>
>>Dear Johan,
>>
>>I think you identified indeed an issue that prevents from translating
>>TTCN-2 to TTCN-3 too easily. The reason is that in TTCN-2, as
>we all know,
>>we had the macro expansion semantics for both test steps and defaults.
>>
>>If in case you have a default that starts with something else than a
>>receive-event (send, assignment, etc) in TTCN-2 this
>statement would always
>>be successful and would therefore lead to the next
>indentation within the
>>default and for this to the next snapshot. So there is no harm in
>>translating this into a function and ignoring everything else
>in parallel
>>to the non-receive statement. (In fact an analyzer would have
>found these
>>unreachable statements anyhow).
>>
>>So you are done, without breaking the snapshot semantics in
>both worlds.
>>
>>Best regards,
>>
>>Theo
>>
>>
>>
>>At 15:57 22.02.2002, Johan Nordin wrote:
>> >Hello all,
>> >
>> >I think I have found a problem concerning test steps in TTCN-3:
>> >
>> >1) An alternative (alt statement) cannot contain sending operations.
>> > In other words, all branches must be receiving operations.
>> >
>> >2) A test step follows the same syntactical rules as an alternative,
>> > and so cannot begin its execution by a sending operation...
>> >
>> >3) A Default must be a test step.
>> >
>> >=> This causes my headache when it comes to translating
>TTCN-2 to TTCN-3,
>> > as the former notation indeed allows both defaults and
>test steps to
>> > start out by sending a PDU/ASP. I know it isn't very common for
>> > defaults to do this, but it does happen on occasion.
>> >
>> > If we were only talking about TTCN-2 test steps, the
>problem would not
>> > be very serious, as they can all be translated into
>TTCN-3 functions,
>> > but the whole thing about Defaults makes things a lot
>more complicated.
>> >
>> >Does anyone have any thoughts on this?
>> >
>> >Have a good weekend!
>> >/Johan
>> >
>> >

---

>> >Telelogic Tau 4.3 - makes requirements visible during
>> >UML development!
>> >Read more about it at www.telelogic.com/tau43
>> >

---

>> >Johan Nordin
>> >Standardization Specialist, Uppsala Development Lab
>> >Telelogic AB
>> >S:t Persgatan 13
>> >SE-75320 Uppsala, Sweden
>> >
>> >Phone: +46 18 661865
>> >Fax: +46 18 661870
>> >Mobile: +46 706 424711
>> >
>> >This email address is being protected from spambots. You need JavaScript enabled to view it.
>> >www.telelogic.com
>> >

---

>> >Telelogic - Putting you ahead in software development!
>> >

---

>

Hello Jens,

OK, but is it really allowed to start with an else statement?
Consider the BNF:



AltConstruct ::= AltKeyword BeginChar AltGuardList EndChar

AltKeyword ::= alt

AltGuardList ::= { GuardStatement [SemiColon]}+ [ElseStatement [SemiColon]]

GuardStatement ::= AltGuardChar (AltFunctionCall | GuardOp StatementBlock)


AltFunctionCall ::= AltKeyword Dot FunctionInstance
/* STATIC SEMANTICS the Function instance shall have either have no return
type or a return type
of altcontroltype */

ElseStatement ::= "["ElseKeyword "]" StatementBlock

AltGuardChar ::= "[" [BooleanExpression] "]"



To me it looks like thw else statement cannot appear first in an alt or am I
wrong?
Or is there now a special production for altsteps that is different from
alt:s?

Regards,
/Johan

---

Original Message

---

From: Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 22 februari 2002 18:52
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Teststeps...


Hi Johan,

we make no restrictions about the structure of the top alternatives
in teststeps or altsteps (as they are called now).

Therefore, if your default starts with sending operation specify
a teststep that starts with an else branch and activate it as
default. This branch will always been taken when this default
is executed, i.e., top branches following the else branch will
never be executed and default that are activated later then the
default with the else branch only will never be executed.

For example:

altstep MyStrangeDefault() {

[else] {
PCO.send ...
....
}
} \\ end altstep


Best regards

Jens

Johan Nordin schrieb:
>
> Hello all,
>
> I think I have found a problem concerning test steps in TTCN-3:
>
> 1) An alternative (alt statement) cannot contain sending operations.
> In other words, all branches must be receiving operations.
>
> 2) A test step follows the same syntactical rules as an alternative,
> and so cannot begin its execution by a sending operation...
>
> 3) A Default must be a test step.
>
> => This causes my headache when it comes to translating TTCN-2 to TTCN-3,
> as the former notation indeed allows both defaults and test steps to
> start out by sending a PDU/ASP. I know it isn't very common for
> defaults to do this, but it does happen on occasion.
>
> If we were only talking about TTCN-2 test steps, the problem would not
> be very serious, as they can all be translated into TTCN-3 functions,
> but the whole thing about Defaults makes things a lot more complicated.
>
> Does anyone have any thoughts on this?
>
> Have a good weekend!
> /Johan
>
>

---

> Telelogic Tau 4.3 - makes requirements visible during
> UML development!
> Read more about it at www.telelogic.com/tau43
>

---

> Johan Nordin
> Standardization Specialist, Uppsala Development Lab
> Telelogic AB
> S:t Persgatan 13
> SE-75320 Uppsala, Sweden
>
> Phone: +46 18 661865
> Fax: +46 18 661870
> Mobile: +46 706 424711
>
> This email address is being protected from spambots. You need JavaScript enabled to view it.
> www.telelogic.com
>

---

> Telelogic - Putting you ahead in software development!
>

---

--

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

On Mon, 25 Feb 2002, Johan Nordin wrote:

> Hello Jens,
>
> OK, but is it really allowed to start with an else statement?
> Consider the BNF:
>
>
>
> AltConstruct ::= AltKeyword BeginChar AltGuardList EndChar
>
> AltKeyword ::= alt
>
> AltGuardList ::= { GuardStatement [SemiColon]}+ [ElseStatement [SemiColon]]
>
> GuardStatement ::= AltGuardChar (AltFunctionCall | GuardOp StatementBlock)
>
>
> AltFunctionCall ::= AltKeyword Dot FunctionInstance
> /* STATIC SEMANTICS the Function instance shall have either have no return
> type or a return type
> of altcontroltype */
>
> ElseStatement ::= "["ElseKeyword "]" StatementBlock
>
> AltGuardChar ::= "[" [BooleanExpression] "]"
>
>
>
> To me it looks like thw else statement cannot appear first in an alt or am I
> wrong?

Then, I guess you'd have to use a little hack:

... {
[false] any port.receive {}
[else] { ... }
}

Greetings, Jacob