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

ID | Project | Category | View Status | Date Submitted | Last Update
0006089 | Part 01: TTCN-3 Core Language | New Feature | public | 16-05-2012 12:51 | 29-11-2013 12:19

Reporter | Jacob Wieland - Spirent |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.6.1 (published 2014-06) | Fixed in Version | v4.6.1 (published 2014-06) |
Clause Reference(s) | 22
Source (company - Author) | Testing Technologies - Jacob Wieland

Summary | 0006089: receive statements on port arrays

Description

Currently, in TTCN-3 there is a dichotomy between dynamically sized port arrays and static alt statements to check for message reception: If it is not known how many ports are in a port array, it is not possible to write down an alt statement which can receive messages over all these ports in parallel.
Though this can be done by use of the default mechanism, we feel that this neither
makes the TTCN-3 more readable and can lead to confusion (which defaults are actual defaults and which ones are dynamic-port-defaults).
Therefore, we propose to generalize the reception statements (i.e. receive/trigger/getcall/getreply/catch) to work as well on port arrays.
alt {
[] <port_array_ref>.receive(X) { ... }
}
where n is the number of ports in the port array,
would have the same semantics as
alt {
[] <port_array_ref>[0].receive(X) { ... }
...
[] <port_array_ref>[n-1].receive(X) { ... }
}
To facilitate distinction on which actual port the reception took place as well as allow a reaction on the same port, an optional 'port' clause (analogous to 'sender' and 'value') can be added to the assignment part of the receive statement.
Example:
Assuming, <port_array_ref> is a port array of PortType ports, this would be
valid:
var PortType p;
alt {
[] <port_array_ref>.receive(X) -> port p { p.send(Y) }
}
This construct should work the same way on multi-dimensional port arrays as on single dimensional arrays.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR6089.doc (400,384) 08-10-2013 18:36 http://oldforge.etsi.org/mantis/file_download.php?file_id=2900&type=bug CR6089_resolution_v2.doc (472,064) 09-10-2013 16:16 http://oldforge.etsi.org/mantis/file_download.php?file_id=2913&type=bug CR6089_resolution_v3.doc (491,520) 29-11-2013 12:18 http://oldforge.etsi.org/mantis/file_download.php?file_id=2961&type=bug

Issue History
Date Modified | Username | Field | Change
16-05-2012 12:51 | Jacob Wieland - Spirent | New Issue |
16-05-2012 12:51 | Jacob Wieland - Spirent | Clause Reference(s) | => 22
16-05-2012 12:51 | Jacob Wieland - Spirent | Source (company - Author) | => Testing Technologies - Jacob Wieland
16-05-2012 16:03 | Jacob Wieland - Spirent | Note Added: 0010627 |
09-07-2012 16:56 | Ina Schieferdecker | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-07-2012 17:08 | Gyorgy Rethy | Note Added: 0010726 |
10-07-2012 11:40 | Gyorgy Rethy | Note Added: 0010741 |
10-07-2012 11:40 | Gyorgy Rethy | Assigned To | => Jens Grabowski
10-07-2012 11:40 | Gyorgy Rethy | Status | new => assigned
10-07-2012 11:40 | Gyorgy Rethy | Target Version | => Edition 4.5.1
10-07-2012 11:46 | Gyorgy Rethy | Note Edited: 0010741 |
10-07-2012 11:46 | Gyorgy Rethy | Note Deleted: 0010726 |
10-07-2012 13:01 | Jacob Wieland - Spirent | Note Added: 0010751 |
10-07-2012 13:35 | Jacob Wieland - Spirent | Note Added: 0010752 |
08-07-2013 18:19 | Gyorgy Rethy | Target Version | v4.5.1 (published 2013-04) => v4.6.1 (published 2014-06)
12-07-2013 11:53 | Jens Grabowski | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
12-07-2013 13:48 | Jacob Wieland - Spirent | File Added: CR6089.zip |
12-07-2013 13:49 | Jacob Wieland - Spirent | Note Added: 0011577 |
12-07-2013 13:57 | Jacob Wieland - Spirent | Note Added: 0011578 |
12-07-2013 13:57 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
12-07-2013 13:57 | Jacob Wieland - Spirent | Status | assigned => confirmed
29-08-2013 11:14 | Gyorgy Rethy | Note Added: 0011635 |
29-08-2013 11:15 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
29-08-2013 11:15 | Gyorgy Rethy | Status | confirmed => assigned
29-08-2013 11:15 | Gyorgy Rethy | Resolution | open => fixed
29-08-2013 11:15 | Gyorgy Rethy | Note Edited: 0011635 |
29-08-2013 14:41 | Jacob Wieland - Spirent | Note Added: 0011640 |
07-10-2013 13:30 | Jacob Wieland - Spirent | Note Added: 0011685 |
07-10-2013 13:30 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
07-10-2013 13:30 | Jacob Wieland - Spirent | Status | assigned => confirmed
07-10-2013 17:28 | Gyorgy Rethy | Note Added: 0011693 |
07-10-2013 17:30 | Gyorgy Rethy | Note Edited: 0011693 |
07-10-2013 17:32 | Gyorgy Rethy | Note Edited: 0011693 |
07-10-2013 17:33 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
07-10-2013 17:33 | Gyorgy Rethy | Status | confirmed => assigned
08-10-2013 10:48 | Jacob Wieland - Spirent | Note Added: 0011697 |
08-10-2013 11:05 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
08-10-2013 11:05 | Jacob Wieland - Spirent | Status | assigned => confirmed
08-10-2013 14:04 | Gyorgy Rethy | Note Added: 0011703 |
08-10-2013 14:30 | Jacob Wieland - Spirent | Status | confirmed => assigned
08-10-2013 14:30 | Jacob Wieland - Spirent | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
08-10-2013 18:35 | Jacob Wieland - Spirent | File Deleted: CR6089.zip |
08-10-2013 18:36 | Jacob Wieland - Spirent | File Added: CR6089.doc |
08-10-2013 18:36 | Jacob Wieland - Spirent | Note Added: 0011716 |
08-10-2013 18:36 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
08-10-2013 18:36 | Jacob Wieland - Spirent | Status | assigned => confirmed
09-10-2013 16:16 | Gyorgy Rethy | File Added: CR6089_resolution_v2.doc |
09-10-2013 16:18 | Gyorgy Rethy | Note Added: 0011736 |
09-10-2013 16:18 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
09-10-2013 16:18 | Gyorgy Rethy | Status | confirmed => assigned
10-10-2013 15:27 | Jacob Wieland - Spirent | Note Added: 0011756 |
10-10-2013 15:27 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
10-10-2013 15:27 | Jacob Wieland - Spirent | Status | assigned => confirmed
29-11-2013 12:18 | Ina Schieferdecker | File Added: CR6089_resolution_v3.doc |
29-11-2013 12:19 | Ina Schieferdecker | Note Added: 0011865 |
29-11-2013 12:19 | Ina Schieferdecker | Status | confirmed => resolved
29-11-2013 12:19 | Ina Schieferdecker | Fixed in Version | => v4.6.1 (published 2014-06)
29-11-2013 12:19 | Ina Schieferdecker | Status | resolved => closed

Notes

(0010627)
Jacob Wieland - Spirent
16-05-2012 16:03

As an alternative syntax to make the feature more explicit, we could introduce the following: any <port_array_ref>.receive() So, this would be a mixture between any port.receive and <port_ref>.receive.

(0010741)
Gyorgy Rethy
10-07-2012 11:40 (edited on: 10-07-2012 11:46)

STF discussion 2012-07-10:
The need for such feature is agreed. The solution could be made consistent for the different active objects, i.e. for ports, timers, components... and shall allow saving the index of the instance of an array as well. Also any port, any timer, any componanet shall be considered. Both access to the active objects and to the index of active objects should be considered.
Analyse the different alternatives for further discussion.

(0010751)
Jacob Wieland - Spirent
10-07-2012 13:01

Why would that be necessary to know the index of the timer/port? Since timers and ports are passed by reference, it would never be necessary to "assign them back" to their original index. What would the index be useful for otherwise if the port/timer can be assigned to an additional variable to store it for future use.
To enlarge the construction to timers, we would need to introduce timer variables (which de-facto already exist as timer parameters), i.e. see the keyword timer also as a predefined type to be used in var-declarations.

(0010752)
Jacob Wieland - Spirent
10-07-2012 13:35

If really seen as necessary, the index-assignment notation could look like this:
type component C {
port P[10][10][10] p;
}
... runs on C {
var integer i, j, k;
alt {
[] any p.receive(...) -> port [i][j][k] { p[i][j][k].send(...) }
}
As the syntax is clearly distinguishable from a variable reference (as in -> port p2), I think this would be a very readable and clear alternative. Also, it would not introduce any new keywords.

(0011577)
Jacob Wieland - Spirent
12-07-2013 13:49

added proposal for all receiving operations (receive, trigger, getcall, getreply, catch and check) both in text and in BNF. changes for components and timers to be done later

(0011578)
Jacob Wieland - Spirent
12-07-2013 13:57

can you crosscheck?

(0011635)
Gyorgy Rethy
29-08-2013 11:14 (edited on: 29-08-2013 11:15)

My comments:
1) I would prefer a resolution text containing only the clauses changed by this CR and only the changes related to this CR (not the whole standard)
2) The syntax should more intuitively identify that a port array is meant; "any p" is not intuitive enough, a non-experts reader may miss the point easily; for example
[] any Port.receive (MyTemplate);
For similar cases we are already using the [-] syntax (when not a concrete element but the inner type of a record/set of is referred to); i.e.
[] p[-].receive(Mytemplate)
would explicitly show that the receive operation works over the whole port array, not on a single port only
3) The need of saving the index of the port is above question, otherwise it would be impossible to respond to the message received over a port that is member of a port array.
4) For saving the index I propose the syntax port i and port (i,j,k), as we are using this syntax already, when saving certain fields of the received message (see $22.2.2). I.e.
[] p[-].receive(Mytemplate) -> port i //single dimension port array
or
[] p[-].receive(Mytemplate) -> port (i) //single dimension port array
and
[] p[-].receive(Mytemplate) -> port (i,j,k) //3-dimensional port array
5) The meaning of "If the port array is nested, then the inner port arrays are iterated over first." is unclear to me (nesting means to me something in a record field or as a record of element). I suppose multi-dimensional arrays are meant here. I would propose:
"In case of multi-dimensional port arrays the port indices are iterated from the last index to the first index, i.e. [0,0,0] then [0,0,1] ... [0,1,0], [0,1,1] ... [1,0,0], [1,0,1] etc."

(0011640)
Jacob Wieland - Spirent
29-08-2013 14:41

My comments:
1) This was done only because the CR is supposed to include also stuff for component and timer arrays and I didn't want a merge-nightmare between proposals later on. Of course, the final proposal will only contain the changed sections.
2) The syntax you are proposing also is not intuitive to me - you still need to know what it should signify to understand it. I would opt for a thing similar to the 'all from' construct we introduced for permutation/subset, i.e. 'any from Port.receive'. This clearly distinguishes it both from 'any port.receive' and 'Port.receive'. Alternatively, it could be 'any port from P' which would make it clear to everybody, I think. Basically, this would then be a special case of the any port construction.
3) The index is not necessary for reply if you can assign the port to a port variable instead. The index would only be necessary if you need to use the index information for something else on which your reply depends (i.e. some message for even, some other for odd ports).
4) using tuples for index-variable assignment is fine with me. However, if indices are supposed to be assigned, always parantheses should be used (even for single index) to distinguish from port-variable assignment (which I would deem the much more common case and thus a much more useful syntax, especially for multi-dimensional arrays because I only need to declare one port variable instead of one integer variable per dimension and I don't have to pick the port from the array explicitly once more).
you have to agree that for an n-dimensional port array P
var integer i1, ..., in;
[] any port from p.receive(...) -> port (i1, ..., in) { p[i1]...[in].send(...) }
demands a lot of unnecessary work for the user in contrast to:
var P vp;
[] any port from p.receive(...) -> port vp { vp.send(...) }
Also, here you see the additional advantage for the any-port-from-construct as opposed to the p[-]...[-] where you have to know (and care) how many dimensions there are in p.
5) also, I have no problem with rewording the iteration procedure to make it more clear

(0011685)
Jacob Wieland - Spirent
07-10-2013 13:30

please comment on my comments

(0011693)
Gyorgy Rethy
07-10-2013 17:28 (edited on: 07-10-2013 17:32)

Hi:
1) OK
2) "any from P.receive" looks OK for me and still not too long; any port from P seems to be somewhat long, but it is true, is absolutely clear. Also, we have to think about timer arrays, i.e. if I want to check if any timer from an array has expired. We should also add "any from T.timeout" or any timer from T.timeout.
3) & 4) For pure reply yes, a port variable would be an easy solution. But the response-case is usually not so simple. We often has to maintain the state machines of the ports, because the response depends on the (incoming message + port state). The state is most often a record of enumerated or record of integer, so to check the old state of a port and to store the new state after sending the response, the indices are needed anyway. In fact, multi-dimensional port arrays are used very rarely, if used at all. I haven't seen any yet. I think we should design the language for the majority of use-cases.
So, in summary, I think that:
- we cannot avoid a mechanism to store the port (timer) index. In most cases it will be a single-dimensional index, and the syntax should be optimized for this, but there should be a way to store multi-dimensional indexes as well. For example, we can say that an integer variable or an integer array - that has the same dimensions as the port/timer array itself - name shall be used to store the index. And probably, we could also allow using just an integer array name when referencing a port or timer from an array.
- we should keep the solution as simple as possible for the tool makers as well. For this reason one mechanism may be sufficient. On the other hand, port parameters are allowed, therefore allowing port variables as well may not be a tremendous extension for tool providers.

(0011697)
Jacob Wieland - Spirent
08-10-2013 10:48

So, the proposal is this, for an N-dimensional port array P:
any [port] from P.receive(...) -> port X
where X can either be
1) a port variable
2) an integer variable, if N is 1
3) an integer array variable of length N
4) a tuple of integer variables with N components
For easiest usage, we should then also allow for multi-dimensional arrays (case 2) also the syntax P[X], which is short for P[X[0]]...[X[N-1]]
If the last is allowed, then I suppose cases 2 and 3 are really the only ones you need.

(0011703)
Gyorgy Rethy
08-10-2013 14:04

STF discussion: stay with 2) and 3) and the short form of using an integer array as a port index reference. Implement it for port, timer and component arrays. The syntax of storing the index need to be thought about when reviewing the resolution draft.

(0011716)
Jacob Wieland - Spirent
08-10-2013 18:36

please crosscheck

(0011736)
Gyorgy Rethy
09-10-2013 16:18

CR6089_resolution_v2.doc, please review. Hope its self explaining, where I though explanation is useful, added it in a comment.

(0011756)
Jacob Wieland - Spirent
10-10-2013 15:27

In principle okay. I still don't think that the new keyword mechanism really needs to be only for modifiers (for me, the @-symbol is more like a keyword-escape-mechanism), but I can think we can discuss that for the future.
I left out the .running and .alive constructs originally because they are not really problematic (they are not blocking and can be solved with a for-loop over the array) while the problem for the blocking constructs cannot be solved with a for-loop. But, if you really also want them in there, I have no problem with that.

(0011865)
Ina Schieferdecker
29-11-2013 12:19

As proposed with additions/editorials in v4