The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Rich Morin <>
To: Tautological Eunuch Horticultural Scythians <>
Subject: [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
Date: Thu, 9 Mar 2023 17:31:17 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> On Mar 9, 2023, at 15:18, segaloco via TUHS <> 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"

	"The ALTER Statement"

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 (:-).


  parent reply	other threads:[~2023-03-10  1:31 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-09 23:01 [TUHS] " Steffen Nurpmeso
2023-03-09 23:18 ` [TUHS] " segaloco via TUHS
2023-03-09 23:21   ` Warner Losh
2023-03-09 23:31     ` Luther Johnson
2023-03-09 23:44       ` josh
2023-03-09 23:54       ` Warner Losh
2023-03-10  0:54         ` segaloco via TUHS
2023-03-10  1:08           ` Warner Losh
2023-03-10 10:08             ` Ralph Corderoy
2023-03-10 11:37               ` arnold
2023-03-10 11:56                 ` Ralph Corderoy
2023-03-10 11:59                   ` arnold
2023-03-10 12:11                     ` Ralph Corderoy
2023-03-10  6:15     ` Dave Horsfall
2023-03-10 16:55       ` Steffen Nurpmeso
2023-03-10 17:02         ` Bakul Shah
2023-03-12 20:47         ` Dave Horsfall
2023-03-12 21:50           ` Warner Losh
2023-03-12 22:27             ` Steffen Nurpmeso
2023-03-13  3:09               ` [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55thanniversary Dave Horsfall
2023-03-14 19:54                 ` Steffen Nurpmeso
2023-03-10  1:31   ` Rich Morin [this message]
2023-03-10 11:37 [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary Noel Chiappa
2023-03-10 15:54 ` Dan Cross
2023-03-12  7:39   ` Anthony Martin
2023-03-12 11:40     ` Dan Cross
2023-03-12 16:40       ` Paul Winalski
2023-03-13  3:25       ` John Cowan
2023-03-13 10:40         ` Alejandro Colomar (man-pages)
2023-03-13 12:19           ` Dan Cross
2023-03-10 11:51 Noel Chiappa
2023-03-10 14:16 ` Ronald Natalie
2023-03-10 14:39   ` John Cowan
2023-03-10 16:30   ` Phil Budne
2023-03-10 17:50     ` Steffen Nurpmeso
2023-03-10 17:57       ` Paul Winalski
2023-03-10 18:12         ` Lawrence Stewart
2023-03-10 17:28   ` Clem Cole
2023-03-10 17:54     ` Paul Winalski
2023-03-10 15:37 Noel Chiappa
2023-03-10 15:46 ` Larry McVoy
2023-03-10 16:04 ` Dan Cross
2023-03-10 18:55 ` Ron Natalie
2023-03-10 19:04   ` Dan Cross
2023-03-10 19:35     ` segaloco via TUHS

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).