10 Mar
2023
10 Mar
'23
2:31 a.m.
On Mar 9, 2023, at 15:18, segaloco via TUHS
<tuhs(a)tuhs.org> wrote:
GOTO is one of those paradoxical things where I would only trust the most sophisticated
engineer to know when it's acceptable to use a GOTO but on the flip side would be
suspicious of anyone claiming to be an engineer that uses any amount of GOTOs...
Were any of the various GOTOs in languages ever meant to be any more than providing the
same level of control that branch statements in assembly do? Was there ever some vision
anyone's aware of concerning a sophisticated, dependable use of GOTOs? Since my
first days poking around learning C GOTO has been mentally filed away as an assembly
vestige for folks in transition, not a dependable construct in its own right. Any
alternative camps out there?
COBOL's ALTER statement is kind of analogous to a computed GOTO, but it adds a
dangerous aspect of "action at a distance" (i.e., monkey-patching which
invisibly modifies the control flow of the original code):
"The ALTER statement changes the transfer point specified in a GO TO
statement"
https://www.mainframebug.com/tuts/COBOL/module7/Top18_COBOL_ALTER_statement…
"The ALTER Statement"
https://www.microfocus.com/documentation/visual-cobol/vc60/DevHub/HRLHLHPDF…
The problem, IMO, is that the compile-time program flow can be invisibly altered at run
time, by code anywhere else in the program. So, there is no requirement that a given
branch, GOTO, or noop statement will have its compile-time semantics. If used with
restraint, this be used to optimize code paths, but it can easily be overused.
Just as a GOTO is a surfacing of the assembler branch instruction(s), the ALTER is
analogous to an old assembly-language trick (aka hack): dynamically modifying
"br*/noop foo" commands. FWIW, I didn't use either the ALTER or the trick
in my own code, but I did keep them in reserve (:-).
In one of my earliest COBOL projects, the code came to me with an infestation of ALTER
statements: specifically, a hierarchy of IF statements with ALTER statements at various
levels. This was used at startup time, to configure the remainder of the program. All
very elegant, but really overkill for the task at hand.
As I explained to my boss, the ALTER statements made the code really difficult to
understand. With his permission, I removed the nest of ALTERs and reworked the remaining
control flow as needed. I was greatly assisted in this by the fact that I could retain
the DATA DIVISION as-is, and merely implement the (rather prosaic) control flow that we
actually used.
And no, I don't want to return to either assembler or COBOL (:-).
-r