Together with an index variable, the GOTO statement can also be used to implement DO loops, which are not yet available in PCOMP:
However, it is recommended to avoid GOTO statements whenever possible, and to replace them by SUM and PROD statements, if applicable.
A goto statement is referred to as forward referencing when the "labeled" statement being referenced appears textually after the goto statement.
The acyclic execution path complexity expression for the goto statement is difficult to define.
IF YOU CAN TAKE IT, MORE ON GOTOs Rubin's letter concerning the GOTO statement  provides an excellent example of the harm caused by the use of GOTOs in programming.
Although I agree that the presence of a GOTO statement does not necessarily make a program bad and program complexity metrics probably do penalie the GOTO excessively, I do not agree that GOTO s should be used routinely.
It seems that much attention has been devoted to demonstrating individual programming prowess at the expense of the author of the original program, while overlooking the problem--namely the relative merits of the GOTO statement.
In this situation it was clear that they should not be allowed to use the GOTO statement, given their lack of experience in making "mature programming decisions" about the use of control structures.
There were two factors whih contributed to a superficial desirability of GOTO statement in the solution o Rubin's problem.
In response to Frank Rubin's reopening the GOTO statement discussion, I'd like to show how the language used can play a significant part.
His position is that the GOTO statement
should be reinstated as a programming tool, reversing its banishment following Dijkstra's famous letter.
Fortran programmers could only simulate structured constructs by enforcing a discipline on the use of the goto statements