From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10741 invoked from network); 10 Mar 2023 01:31:29 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 10 Mar 2023 01:31:29 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 884434139E; Fri, 10 Mar 2023 11:31:24 +1000 (AEST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) by minnie.tuhs.org (Postfix) with ESMTPS id D30D341396 for ; Fri, 10 Mar 2023 11:31:19 +1000 (AEST) Received: by mail-pg1-x532.google.com with SMTP id h31so2209908pgl.6 for ; Thu, 09 Mar 2023 17:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cfcl.com; s=google; t=1678411879; h=to:references:message-id:content-transfer-encoding:date:in-reply-to :from:subject:mime-version:from:to:cc:subject:date:message-id :reply-to; bh=y9kDDVJKx+Ov21+P8SXSyDG6NRtmnh/QfHTv46c6oBA=; b=VHOBlTSUdYe18AMM7Fdasrw+N9MZqeLq8P7QlvHXYwA2SfhtX7lXcoGZh0SgAfbn9o y5I09v6jvAMXoyaz3STVX0aXDrrcR+OwTkV4uYkWhEVaBslOOAxMfkd9j1aSd43HJNW4 JokxfeKl+bkBF1H8C/MMaKIPAZ+MqNWnz4JTtezFQk3oGwdyr5PpKJmbQrdb9cKG0JGz UWaZGEiKHlWFfdd8H0xTcnBX6YchsnmhNiNYI8MoMW958T86BrY2v1div4rDGb1mxjN1 dzVk1zrc3afuV5iIxNHO+SD01aaiD09Gc6lMiMvcEJ+27ZT8eQkX2BfCvokG9liPHQ70 vQDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678411879; h=to:references:message-id:content-transfer-encoding:date:in-reply-to :from:subject:mime-version:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=y9kDDVJKx+Ov21+P8SXSyDG6NRtmnh/QfHTv46c6oBA=; b=ruelvkwLC/CV6rKSagFISd1l02Y1CtHBSs/6fTLkyK2maS97UnxzY+6GD99+ISrGZe mFYnuVmh/NBu92GK6Q/G2qIcW/Z864ETjJoSyoz0xMGa307zxDzUDRWqlXEYhV/e/DZ3 Om2xhbrkm8grwgoOkdxegHsxqW2jCKqF5Ccn0Vi/4aojQWFMMf6jYg/nKWAh7N9Pf1jb FJDGQmmLdPsJ/BCS04p4kYASr64Yqyxwdr8wS63NCUP4fwvkI5kKG5xabCgpzK2zdber nQ2U7rx8Qkf90XXhTtsGo+0WWeIlsycR94/eR+lnM4+crkk0GldUpcEvWc0fQ0WpF1iG En4g== X-Gm-Message-State: AO0yUKWmWydp87E1yhI987TnC89JQ7h/uXuZXePNLGdbhkW18kpMHllp iPQ3XURUNP8B7+PFFuAojnc8c+8dBL7ALeR+MZs= X-Google-Smtp-Source: AK7set85XGreywtETKdbvOBzv6G/MSSadiu1bQMgsozPNC1qC6x27ajrBJ3fNTcgZsDJvH4Y3yp4yg== X-Received: by 2002:aa7:9629:0:b0:594:15fd:895e with SMTP id r9-20020aa79629000000b0059415fd895emr22547826pfg.31.1678411878800; Thu, 09 Mar 2023 17:31:18 -0800 (PST) Received: from smtpclient.apple ([50.125.55.227]) by smtp.gmail.com with ESMTPSA id 23-20020aa79157000000b005921c46cbadsm207058pfi.99.2023.03.09.17.31.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2023 17:31:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) From: Rich Morin In-Reply-To: Date: Thu, 9 Mar 2023 17:31:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3F175E13-65E1-420C-B005-24C1A1F47482@cfcl.com> References: <20230309230130.q4I-f%steffen@sdaoden.eu> To: Tautological Eunuch Horticultural Scythians X-Mailer: Apple Mail (2.3696.120.41.1.1) Message-ID-Hash: J3EWSHAKEIAP6FHI6IGENUQADSWZGLZE X-Message-ID-Hash: J3EWSHAKEIAP6FHI6IGENUQADSWZGLZE X-MailFrom: rdm@cfcl.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: > On Mar 9, 2023, at 15:18, segaloco via TUHS wrote: >=20 > 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... >=20 > 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_statemen= t.php "The ALTER Statement" = https://www.microfocus.com/documentation/visual-cobol/vc60/DevHub/HRLHLHPD= F803.html 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. =20 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