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

ID | Project | Category | View Status | Date Submitted | Last Update
0007682 | Part 01: TTCN-3 Core Language | New Feature | public | 09-06-2017 14:30 | 28-12-2019 15:07

Reporter | Jacob Wieland - Spirent |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.9.1 (published 2017-05) |
Target Version | 4.11.1 (published 2019-05) | Fixed in Version | 4.12.1 (published 2020-05) |
Clause Reference(s) | 6.2
Source (company - Author) | Spirent Jacob Wieland

Summary | 0007682: Table with index-operators using keys as indices should be supported

Description

Tables (or Dictionaries) that associate unique keys with values are a central programming tool in any programming language useful for multitude of algorithms.
A table type concept should be introduced in TTCN-3 to allow definition and usage of tables.
The basic type definiton could look like this:
type table T from IndexType to ValueType;
Operations on table variables would be:
- indexing: t[key] where key needs to be of type IndexType
on the right hand side it yields the value associated with key of ValueType
on the left hand side it associates a new value with the key
If key is not associated to any value, either omit or null could be the result (and could also be used to delete entries from the table).
The index-assignment syntax could be used as a table-value notation:
{ [key1] := value1,
[key2] := value2,
...
}
The same properties as for record of values would apply, record ofs being essentially a special table with integer as key.
At first, this new type needs not to be considered in the context of codecs and TCI because they are to be used for easing implementation of testcases, not as messages.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR7682.docx (263,410) 09-08-2019 10:53 http://oldforge.etsi.org/mantis/file_download.php?file_id=3851&type=bug CR7682-2.docx (254,596) 16-12-2019 12:22 http://oldforge.etsi.org/mantis/file_download.php?file_id=3869&type=bug

Issue History
Date Modified | Username | Field | Change
09-06-2017 14:30 | Jacob Wieland - Spirent | New Issue |
09-06-2017 14:30 | Jacob Wieland - Spirent | Status | new => assigned
09-06-2017 14:30 | Jacob Wieland - Spirent | Assigned To | => Jacob Wieland - Spirent
09-06-2017 15:45 | Jacob Wieland - Spirent | Status | assigned => new
04-09-2017 09:25 | Jens Grabowski | Note Added: 0014804 |
04-09-2017 09:26 | Jens Grabowski | Status | new => assigned
24-10-2017 12:48 | Jens Grabowski | Note Added: 0014845 |
24-10-2017 12:48 | Jens Grabowski | Assigned To | Jacob Wieland - Spirent => Jens Grabowski
05-01-2018 13:29 | Gyorgy Rethy | Target Version | v4.10.1 (published 2018-05) => 4.11.1 (published 2019-05)
06-08-2019 12:54 | KristÃ³f Szabados | Note Added: 0015375 |
08-08-2019 14:20 | KristÃ³f Szabados | Note Added: 0015434 |
08-08-2019 14:20 | KristÃ³f Szabados | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
09-08-2019 10:53 | Jacob Wieland - Spirent | File Added: CR7682.docx |
09-08-2019 10:56 | Jacob Wieland - Spirent | Note Added: 0015439 |
09-08-2019 10:56 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban
09-08-2019 10:56 | Jacob Wieland - Spirent | Status | assigned => confirmed
13-08-2019 16:44 | KristÃ³f Szabados | Note Added: 0015440 |
14-08-2019 09:47 | Jacob Wieland - Spirent | Note Added: 0015441 |
14-08-2019 12:52 | KristÃ³f Szabados | Note Added: 0015442 |
23-08-2019 15:05 | KristÃ³f Szabados | Note Added: 0015447 |
26-08-2019 08:19 | Jacob Wieland - Spirent | Note Added: 0015448 |
26-08-2019 09:49 | KristÃ³f Szabados | Note Added: 0015449 |
26-08-2019 11:25 | Jacob Wieland - Spirent | Note Added: 0015456 |
26-08-2019 11:26 | Jacob Wieland - Spirent | Assigned To | Tomas Urban => Jacob Wieland - Spirent
26-08-2019 11:26 | Jacob Wieland - Spirent | Status | confirmed => assigned
16-12-2019 12:12 | Jacob Wieland - Spirent | File Added: CR7682-2.docx |
16-12-2019 12:22 | Jacob Wieland - Spirent | File Deleted: CR7682-2.docx |
16-12-2019 12:22 | Jacob Wieland - Spirent | File Added: CR7682-2.docx |
16-12-2019 12:24 | Jacob Wieland - Spirent | Note Added: 0015520 |
16-12-2019 12:24 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => KristÃ³f Szabados
16-12-2019 12:24 | Jacob Wieland - Spirent | Status | assigned => confirmed
17-12-2019 09:00 | KristÃ³f Szabados | Note Added: 0015539 |
17-12-2019 09:00 | KristÃ³f Szabados | Status | confirmed => resolved
17-12-2019 09:00 | KristÃ³f Szabados | Fixed in Version | => 4.11.1 (published 2019-05)
17-12-2019 09:00 | KristÃ³f Szabados | Resolution | open => fixed
28-12-2019 12:54 | Gyorgy Rethy | Assigned To | KristÃ³f Szabados => Gyorgy Rethy
28-12-2019 12:54 | Gyorgy Rethy | Status | resolved => assigned
28-12-2019 15:07 | Gyorgy Rethy | Note Added: 0015588 |
28-12-2019 15:07 | Gyorgy Rethy | Status | assigned => closed
28-12-2019 15:07 | Gyorgy Rethy | Fixed in Version | 4.11.1 (published 2019-05) => 4.12.1 (published 2020-05)

Notes

(0014804)
Jens Grabowski
04-09-2017 09:25

- Jacob, can you provide a use case? - Is it sufficient to build hash tables/trees with objects in the Java style?

(0014845)
Jens Grabowski
24-10-2017 12:48

STF decision: To be shifted to 2018 maintenance.

(0015375)
KristÃ³f Szabados
06-08-2019 12:54

STF discussion: this can be seen as a short hand notation for a record of record structure, with implicit coding/decoding. And intuitive syntax for element access.

(0015434)
KristÃ³f Szabados
08-08-2019 14:20

STF discussion: Jacob makes a proposal. STF aggress that the feature is useful.

(0015439)
Jacob Wieland - Spirent
09-08-2019 10:56

Added first draft including the following features: - map type definition - indexed assignment notation (for map values) - index operation for accessing elements - from operation for accessing the key set - to operation for accessing the value set - type compatibility Please review

(0015440)
KristÃ³f Szabados
13-08-2019 16:44

The described behavior does not sound to be consistent with the already existing parts of the standard.
When the assignment notation is used on the right hand side, with a key that has no associated value, the index notation shall cause a semantic or runtime error Just like in the case of record of and set of types when the indexed element is undefined or uninitialized.
To check if a key-value mapping is present in the map, the ispresent predefined function should be used.

(0015441)
Jacob Wieland - Spirent
14-08-2019 09:47

I don't understand what you mean with 'When the assignment notation is used on the right hand side with a key that has no associated value'. If you use the assignment notation (i.e. { [key] := value }) on the right hand side, the assignment to the key associates it to a value (or -). I have kept that part the same as for record of values, so this is consistent.
Maybe you are referring to the index notation (i.e. m[key]) on the right hand side?
If you read carefully, for the index notation it is exactly as you describe in the proposal, using it on the right hand side in anything else than a null-comparison shall result in an error. So, the null-comparison is just a way of checking for presentness.
It seemed strange to me that assigning null to a field should be possible and not checking via equality, so allowing comparison with null seemed kind of natural/intuitive. But I am also fine with disallowing even the null-check.
So, if you want to always cause it an error, the isbound/ispresent/isvalue functions can all be used for checking if a key has an associated value (by basically checking that the expression doesn't cause an error).
Are you okay with the null-assignment for removing a key-association or do we need to invent some other syntax for that?

(0015442)
KristÃ³f Szabados
14-08-2019 12:52

True, I ment index notation. Yes, I would find it better if we would disallow the null-check.

(0015447)
KristÃ³f Szabados
23-08-2019 15:05

maybe the replace predefined function would be better for deleting/replacing existing mappings.
For example:
type map from charstring to charstring charToCharMap; // much like record of charstring;
var chartoCharMap myMap:= {["1"] := "1", ["2"] := "2", ["3"] := "3", ["4"] := "4"};
then use something like replace(myMap, "1", 1, {} ) to delete the first mapping, replace (myMap, "1", 2, {}) to replace/delete the first 2 mappings.
This way we could work with multiple mappings at the same time.
Maybe even the substring predefined function could be used like this.
And it would be consistent with a maps are record of record understanding.

(0015448)
Jacob Wieland - Spirent
26-08-2019 08:19

I don't think this is a good idea for several reasons:
- replace doesn't work in place on variables, but produces a copy, so this is a costly operation if the tables are large
- so far, there is no order to the keys imposed, so it would be unintuitive to assume one but you need it to specify something like the 'first two mappings'
As an alternative, we could overload the unmap operation to unmap a key in a table:
unmap(v_table, v_key)

(0015449)
KristÃ³f Szabados
26-08-2019 09:49

unmap might also be fine. please note, that the order in which the mappings are "added" to the table, intuitively create and ordering. Just like with database tables, the order you insert the rows is the order people will expect to read them.

(0015456)
Jacob Wieland - Spirent
26-08-2019 11:25

STF discussion: overload the unmap operation also to delete keys from map variables.

(0015520)
Jacob Wieland - Spirent
16-12-2019 12:24

Changed according to discussion. Unmap to be used to remove key-value associations. isbound etc to be used to check for association. referencing of undefined association on right hand side causes error. Also amended BNF accordingly. Please check.

(0015539)
KristÃ³f Szabados
17-12-2019 09:00

Looks good to me, can be included in the standard.

(0015588)
Gyorgy Rethy
28-12-2019 15:07

Included to final draft 4.11.2.