ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0007618 | Part 01: TTCN-3 Core Language | New Feature | public | 16-02-2017 14:37 | 06-08-2019 11:44

Reporter | Jacob Wieland - Spirent |
Assigned To | Jens Grabowski |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | no change required |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | 4.11.1 (published 2019-05) | Fixed in Version |  |
Clause Reference(s) | 20.2
Source (company - Author) | Spirent - Jacob Wieland

Summary | 0007618: alternative event headers could allow a boolean combinators

Description

Sometimes, in an alt statement, different alternatives have the same alternative body, i.e.
alt {
[] <event 1> { S }
[] <event 2> { S }
...
}
In such a case, it would be convenient to only have to write the body once, e.g.
alt {
[] <event 1> or <event 2> { S }
...
}
In a similar fashion, some conditions to be waited on are more complex and cannot be modeled with a single event, like awaiting two messages from different ports. Though this can be modeled now by nested alt statements or using marker flags and the repeat statement (if entering the alt-branch is undesirable as other alternatives might still be active in the top-alt which then would need to be copied to the sub-level alt), it would be more convenient if an and operation could be employed instead, e.g.
alt {
[] <event 1> and <event 2> { ... }
}
Of course, all events treated by such boolean combinations shall be visible in the same snapshot, so it makes no sense to combine two receive statements on the same port handling consecutive messages.
Thus, the proposal is to allow any boolean and/or-combination of allowed events that can be active in the same snapshot.
Care must be taken when combining different events with attached redirects by disjunction as only a subset of the events could be active and thus only a subset of the redirects might occur, e.g.
alt {
[] p1.receive(t1) -> value v1 or p2.receive(t2) -> value v2 {
// here, v1 or v2 might not be bound
}
Finally, similar to the any from P construct for port arrays, a similar construct to await a message from all ports in an array might be added, as well as a base event.
type record of P Ports;
type record of Message Messages;
var Ports ports := { p1, p2, p3 }
var Messages v_msgs;
alt {
[] all from ports.receive(Message:?) -> value v_msgs[@index] {
// the @index reference allows association of the received messages
// to the port it was received from, i.e. v_msgs[i] was received from ports[i]
}

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR-7618-Discussion.pptx (49,271) 08-09-2017 08:00 http://oldforge.etsi.org/mantis/file_download.php?file_id=3683&type=bug

Issue History
Date Modified | Username | Field | Change
16-02-2017 14:37 | Jacob Wieland - Spirent | New Issue |
06-06-2017 14:38 | Jens Grabowski | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
06-06-2017 14:52 | Jens Grabowski | Note Added: 0014633 |
06-06-2017 14:53 | Jens Grabowski | Assigned To | => Jens Grabowski
06-06-2017 14:53 | Jens Grabowski | Status | new => assigned
08-09-2017 07:40 | Jens Grabowski | Note Added: 0014822 |
08-09-2017 08:00 | Jens Grabowski | File Added: CR-7618-Discussion.pptx |
24-10-2017 12:39 | Jens Grabowski | Note Added: 0014843 |
05-01-2018 13:29 | Gyorgy Rethy | Target Version | => 4.11.1 (published 2019-05)
06-08-2019 11:44 | KristÃ³f Szabados | Note Added: 0015373 |
06-08-2019 11:44 | KristÃ³f Szabados | Status | assigned => closed
06-08-2019 11:44 | KristÃ³f Szabados | Resolution | open => no change required

Notes

(0014633)
Jens Grabowski
06-06-2017 14:52

STF discussion: interesting feature, implications need to be studied, maybe feature for another package

(0014822)
Jens Grabowski
08-09-2017 07:40

STF discussion: concentrate on OR semantics (for avoiding code duplication), Case one in slides to be uploaded.

(0014843)
Jens Grabowski
24-10-2017 12:39

STF decision: requires further discussion. To be shifted to 2018 maintenance. Maybe candidate for advanced matching extension package.

(0015373)
KristÃ³f Szabados
06-08-2019 11:44

STF discussion: valid inut for TTCN-5. At the moment this would not provide much gain.