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

ID | Project | Category | View Status | Date Submitted | Last Update
0008153 | Part 01: TTCN-3 Core Language | New Feature | public | 11-12-2022 19:21 | 16-12-2024 10:26

Reporter | Matthias Simon |
Assigned To | Jens Grabowski |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | resolved | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version |  | Fixed in Version |  |
Clause Reference(s) | 19.2, 19.3
Source (company - Author) | Nokia - Matthias Simon

Summary | 0008153: Extend usage of break and continue statements
Description | * Allow break statements in select statements. * Allow optional label to break/continue from nested loops
Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR8153.docx (114,777) 11-12-2022 20:07 http://oldforge.etsi.org/mantis/file_download.php?file_id=4093&type=bug

Issue History
Date Modified | Username | Field | Change
11-12-2022 19:21 | Matthias Simon | New Issue |
11-12-2022 20:07 | Matthias Simon | Summary | Add optional label to break and continue => Extend usage of break and continue statements
11-12-2022 20:07 | Matthias Simon | Description Updated | bug_revision_view_page.php?rev_id=607#r607
11-12-2022 20:07 | Matthias Simon | File Added: CR8153.docx |
20-12-2022 12:49 | Jens Grabowski | Note Added: 0016441 |
20-12-2022 12:49 | Jens Grabowski | Assigned To | => Jens Grabowski
20-12-2022 12:49 | Jens Grabowski | Status | new => assigned
07-11-2023 17:01 | Jens Grabowski | Note Added: 0016542 |
09-11-2023 21:15 | Gusztáv Adamis | Note Added: 0016570 |
10-11-2023 12:03 | Gusztáv Adamis | Note Added: 0016581 |
26-01-2024 16:27 | Olivier Genoud | Note Added: 0016608 |
21-11-2024 18:33 | Matthias Simon | Note Added: 0016700 |
21-11-2024 18:37 | Matthias Simon | Note Edited: 0016700 | bug_revision_view_page.php?bugnote_id=16700#r625
16-12-2024 10:26 | Jens Grabowski | Note Added: 0016718 |
16-12-2024 10:26 | Jens Grabowski | Status | assigned => resolved
16-12-2024 10:26 | Jens Grabowski | Resolution | open => fixed

Notes

(0016441)
Jens Grabowski
20-12-2022 12:49

Additional idea: Add label to loop header. TTF discussion: To be discussed in the scope of the next TTF. Proposal cannot be implemented as proposed for select case statement. It would lead to a backwards incompatible change.

(0016542)
Jens Grabowski
07-11-2023 17:01

TTF discussion: Break and Continue shall be analysed in the scope of the major release. Additional ideas include the deprecation of Goto as well as introduction of breaks/continue across several scope units.

(0016570)
Gusztáv Adamis
09-11-2023 21:15

After diiscussions within TTF:
Possible solution can be "named cycles"
while (...) {
while (...){
break w1; //or continue w1;
}
} : w1
break w1; will terminate both cycles, execution continues with the next instruction after w1.
continue w1; will terminate the innermost cycle and takes the next iteration of the "w1" cycle.
Similar construct can be applied for nested alt instructions with break/repeat "named alt").
alt {
[] ...{
alt {
[] ... {break a1;}
...
}
...
[] ....
}
}: a1;
"altlabels" and "cyclelabels" can be mixed, until they do not "jump" out of the scope.
alt {
[] ... { while (...) { break a2;}}
...
}: a2
If this construct is implemented it may cause to deprecate the goto/label.

(0016581)
Gusztáv Adamis
10-11-2023 12:03

The resolution of the ticket shall be postponed to the next major revision.

(0016608)
Olivier Genoud
26-01-2024 16:27

It seems to be another flavour of "goto", so we do not see the benefit. On the other hand, it is increasing the complexity of the language allowing further flavours of code writing. Also, we are not aware that code cannot be written using existing means.

(0016700)
Matthias Simon
21-11-2024 18:33 (edited on: 21-11-2024 18:37)

I think you are right. A goto to break a loop is perfectly fine, even for Dijkstra's standards.
However, breaking out of loops without using any kind of goto is possible, but cumbersome and inefficient. For example compare this linear search algorithm.
// Using goto
var integer x,y,z;
for (x := 0; x < width; x++) {
for (y := 0; y < height; y++) {
for (z := 0; z < depth; z++) {
if (space[x][y][z] == RedDwarf) {
goto end;
}
}
}
}
label end;
log("found red dwarf at coords", x,y,z)
// Using named loops
var integer x,y,z;
L1:
for (x := 0; x < width; x++) {
for (y := 0; y < height; y++) {
for (z := 0; z < depth; z++) {
if (space[x][y][z] == RedDwarf) {
break L1;
}
}
}
}
log("found red dwarf at coords", x,y,z)
// Without Goto using booleans
var integer x,y,z;
var boolean found;
for (x := 0; x < width && not found; x++) {
for (y := 0; y < height && not found; y++) {
for (z := 0; z < depth && not found; z++) {
if (space[x][y][z] == RedDwarf) {
found := true;
}
}
}
}
log("found red dwarf at coords", x-1,y-1,z-1)
// Without Goto using functions
var integer x, y, z;
searchSpaceXYZ(space, x, y, z);
log("found red dwarf at coords:, x, y, z);
function searchSpaceXYZ(record of record of record of Obj space, inout integer x, inout integer y, inout integer z) boolean {
for (x := 0; x < lengthof(space); x++) {
if (searchSpaceYZ(space, x, y, z)) {
return true;
}
}
return false;
}
function searchSpaceYZ(record of record of record of Obj space, inout integer x, inout integer y, inout integer z) boolean {
for (y := 0; y < lengthof(space[x]); y++) {
if (searchSpaceZ(space, x, y, z)) {
return true;
}
}
return false;
}
function searchSpaceZ(record of record of record of Obj space, inout integer x, inout integer y, inout integer z) boolean {
for (z := 0; z < lengthof(space[x][y]); z++) {
if (space[x][y][z] == RedDwarf) {
return true;
}
}
return false;
}
If I had to rate existing means for readability and code-quality I'd say:
1. Goto
2. Named-loop
3. Boolean-loop
4. Function-loop
Place 2 and 3 are very close, because for simple loops boolean-loops are easier to comprehend. But they can become very ugly and inefficient very fast.
After reviewing available options, I personally would stick with the goto.

(0016718)
Jens Grabowski
16-12-2024 10:26

Discussion will be continued in Gitlab.