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

ID | Project | Category | View Status | Date Submitted | Last Update
0007530 | Part 01: TTCN-3 Core Language | New Feature | public | 17-11-2016 16:30 | 30-12-2017 15:41

Reporter | Jacob Wieland - Spirent |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | no change required |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.10.1 (published 2018-05) | Fixed in Version |  |
Clause Reference(s) | Appendix A.1.3
Source (company - Author) | Spirent - Jacob Wieland

Summary | 0007530: keywords should be escapable to be used as a TTCN-3 identifier.

Description

Nowadays, it is possible that an old module for a previous version of TTCN-3 is imported into a module with a newer language tag or that uses packages that the imported module does not use.
This can lead to the situation that in the newer/more-package-heavy module some identifiers that are totally valid identifiers in the other module are keywords and thus, not valid identifiers anymore.
The importing module would then not be able to reference the imported items.
To solve this problem, an identifier escape mechanism should be introduced so that the importing module can use the escape-notation when using an identifier from the imported module that is a keyword in the importing one.
A simple solution would be to allow the identifier to be put into single tick characters (same as octetstring etc):
'value'
.
This syntax can be used everywhere that an identifier can be used, e.g.
t.'value'
On the lexer-level there is unfortunately a prefix-overlap with octetstring and hexstring literals that start with digits above 9 (i.e. A B C D E F), but since the new syntax would not end in 'O or 'H, this lexical issue can be resolved.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0007683 | closed | Gyorgy Rethy | Keywords (from packages) should be reserved in the Core Standard.

Attached Files |

Issue History
Date Modified | Username | Field | Change
17-11-2016 16:30 | Jacob Wieland - Spirent | New Issue |
17-11-2016 16:30 | Jacob Wieland - Spirent | Status | new => assigned
17-11-2016 16:30 | Jacob Wieland - Spirent | Assigned To | => Jacob Wieland - Spirent
24-12-2016 15:03 | Jens Grabowski | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
24-12-2016 15:03 | Jens Grabowski | Target Version | => v4.10.1 (published 2018-05)
17-04-2017 15:13 | szabados | Note Added: 0014563 |
17-04-2017 15:13 | szabados | Note Deleted: 0014563 |
18-04-2017 15:21 | szabados | Note Added: 0014575 |
18-04-2017 15:24 | szabados | Note Added: 0014576 |
19-04-2017 11:53 | Jacob Wieland - Spirent | Note Added: 0014579 |
19-04-2017 11:54 | Jacob Wieland - Spirent | Note Added: 0014580 |
19-04-2017 11:54 | Jacob Wieland - Spirent | Note Added: 0014581 |
19-04-2017 11:54 | Jacob Wieland - Spirent | Note Added: 0014582 |
19-04-2017 11:55 | Jacob Wieland - Spirent | Note Added: 0014583 |
19-04-2017 11:56 | Jacob Wieland - Spirent | Note Added: 0014584 |
19-04-2017 11:56 | Jacob Wieland - Spirent | Note Added: 0014585 |
19-04-2017 14:39 | Jacob Wieland - Spirent | Note Added: 0014586 |
19-04-2017 14:39 | Jacob Wieland - Spirent | Note Deleted: 0014586 |
09-06-2017 15:39 | Jacob Wieland - Spirent | Relationship added | related to 0007683
26-07-2017 14:08 | Jacob Wieland - Spirent | Note Added: 0014783 |
26-07-2017 14:08 | Jacob Wieland - Spirent | Status | assigned => resolved
26-07-2017 14:08 | Jacob Wieland - Spirent | Resolution | open => no change required
24-10-2017 13:57 | Jens Grabowski | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
24-10-2017 13:57 | Jens Grabowski | Status | resolved => assigned
24-10-2017 13:58 | Jens Grabowski | Status | assigned => resolved
30-12-2017 15:41 | Gyorgy Rethy | Status | resolved => closed

Notes

(0014575)
szabados
18-04-2017 15:21

What was the original issue here? It sound like we need some mapping rules between the language versions in question. Like private to _private. I believe introducing a new sort of identifiers or way of writing identifiers could be an overkill if the actual issue only needs a transformation.

(0014576)
szabados
18-04-2017 15:24

Or it would be even better to ask users to upgrade their old modules.
Mixing different language versions in the same project can be dangerous if users do not check the language identifier in each module before they change it.
Also if users are not perfectly sure in the minute differences in each language version they are using.
Would it be a good idea to include support for very old language version into the list of features that can be deprecated?
What do you think, if the standard would only support old version only up to a specified time or version number difference - like usually done with software - would that be a good incentive for users to upgrade?

(0014579)
Jacob Wieland - Spirent
19-04-2017 11:53

I think I made the case pretty clear

(0014580)
Jacob Wieland - Spirent
19-04-2017 11:54

Module M1 that has package A with keyword X imports module M2 without package A e.g. just a normal XSD import. In the imported module, the identifier X will not be quoted as in that context, X is nothing special. But, in module M1 you cannot use X as identifier as it is a keyword.

(0014581)
Jacob Wieland - Spirent
19-04-2017 11:54

To still access the X, you need to quote it somehow. The proposed syntax for quoting X would be a normal quoting mechanism for identifiers that other languages allow. Prefixing with a dollar or a backslash could also work, but personally, I prefer the proposed option the most.

(0014582)
Jacob Wieland - Spirent
19-04-2017 11:54

Otherwise, there would need to be a mechanism that you can import an external language module with additional package options so that the mapping can take those into account.

(0014583)
Jacob Wieland - Spirent
19-04-2017 11:55

The same applies when you are using code you have no control over, like a library or a standardized test suite part that you are not allowed to change.

(0014584)
Jacob Wieland - Spirent
19-04-2017 11:56

Simply asking the user to change the problematic code isn't always an option.

(0014585)
Jacob Wieland - Spirent
19-04-2017 11:56

There is no actual real-life use-case for this, but the problem occurred to me at some point and I wanted to address it.

(0014783)
Jacob Wieland - Spirent
26-07-2017 14:08

With the solution that all keywords of packages shall also be reserved in the core document, this issue cannot happen anymore, so no change is required to address it.