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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11684 invoked from network); 1 Dec 2020 21:26:01 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 1 Dec 2020 21:26:01 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 518079B620; Wed, 2 Dec 2020 07:25:57 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id E079D94915; Wed, 2 Dec 2020 07:25:23 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="k/0IjCuQ"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 3673294915; Wed, 2 Dec 2020 07:25:22 +1000 (AEST) Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by minnie.tuhs.org (Postfix) with ESMTPS id 8EC0394904 for ; Wed, 2 Dec 2020 07:25:21 +1000 (AEST) Received: by mail-qk1-f170.google.com with SMTP id n132so2848204qke.1 for ; Tue, 01 Dec 2020 13:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5egdBoED6Wu+UoKw5q40odIwNolrFOPmC+nuFHNZm3Q=; b=k/0IjCuQkap86Ags+6RdQoVYSY+rcjYLPep5RL/md+X66ep/GNk2ziLwhcw7aeLN3a OV98BkzfKVvmZ0/GGobJxV5OjO+iyb3bNlgjywbz6ZkoPK6eOLJUVckBajjTtUseqaFH DFo74VQqadDlHaZYYiqUCTwW7EsmRvb6xwBE7lfo3JOv3z1hdAA2ZjpSmtvFNPKhd3F/ QIuhwQSmmCCoqG+xxZOVve0RXVo9GHeG9jvjWM9wXpeqV4vrGIRjVVGiTfir7zl6OM8I 2F/HNbQwSl76Kc6NCM+KQ35eYmBQiVjzf6fr++RZejsdlwrEWZZvKGL3FJ2wZyziZu1U SFcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5egdBoED6Wu+UoKw5q40odIwNolrFOPmC+nuFHNZm3Q=; b=mRRHD8JYMSxV+JJkxeANcy72cVUABoiKZPSiM7Q3KR/0k/6MbJiGANUcgrzA688MYP L9OCXXaeSQr86oddmR62lXpHeOojyktIxl+MzBK8aBPtmJKatzYmUScMmRlXRFP9Y6lT H6JRDkNUn1a5fCwzafcgZofCV+pvGf6GwZ91MCQxuKa/0myf941j82lfHqeXzNxCw1iW e/IcFXO9YYdr29SrHiKmpzxLSzkU5sAhOyOM9z5eaLJK+HGEbswp9JcEqW+Q9WOvGXNb /oStwpB6vHrJk5IEzfQfY2iZ9nNpsXDNVCVWVIaHmuc5T/f+4veIWF/CWz1war24jADJ NHHQ== X-Gm-Message-State: AOAM531BxT5ncOAN/QOJucgRvQbhSp3KbiiZjQB1//wTOU92encLCtAo sKlyQXrjdQ6wT/g8lb9uso3nOtRnnLBL4aQwNdg= X-Google-Smtp-Source: ABdhPJytq5ujHN0cik1mMs9hamaMQrSy9QrfLz6Y9NqBnk5S5BlHk2A1KpgGs75Os3jeQfsde0wfmhnCfPjWjjX97Zs= X-Received: by 2002:a05:620a:15a8:: with SMTP id f8mr5031466qkk.346.1606857920515; Tue, 01 Dec 2020 13:25:20 -0800 (PST) MIME-Version: 1.0 References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> <202012011538.0B1FcLi5023858@freefriends.org> <202012011639.0B1GdjcD031722@freefriends.org> <20201201202012.-40Ur%steffen@sdaoden.eu> <67EE6390-7E60-442B-AEEA-17951ED759A5@iitbombay.org> In-Reply-To: <67EE6390-7E60-442B-AEEA-17951ED759A5@iitbombay.org> From: Dan Cross Date: Tue, 1 Dec 2020 16:24:43 -0500 Message-ID: To: Bakul Shah Content-Type: multipart/alternative; boundary="0000000000008e93cc05b56dc31d" Subject: Re: [TUHS] The UNIX Command Language (1976) X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000008e93cc05b56dc31d Content-Type: text/plain; charset="UTF-8" On Tue, Dec 1, 2020 at 3:40 PM Bakul Shah wrote: > On Dec 1, 2020, at 12:20 PM, Steffen Nurpmeso wrote: > > Never without my goto:, and if it is only to break to error > > handling and/or staged destruction of local variables after > > initialization failures. Traumatic school impression, finding > > yourself locked in some PASCAL if condition, and no way to go to. > > Pascal had goto. Pascal also had to go. (Thanks...I'm here all week.) You can even do a non-local goto! > > In Go you don't need goto for the sort of thing you and McVoy > talked about due to its defer statement and GC. Now granted > GC may be too big of a hammer for C/C++ but a future C/C++ > add defer gainfully as the defer pattern is pretty common. > For example, mutex lock and unlock. > C++ has had something analogous for some time: destructors that run when an object goes out of scope. Scope guards to do things like close files and auto-release locks on exiting a critical section are pretty common in that world, and in general, preferable to many of the alternatives (either deeply nested conditionals or banks of labels and `goto fail1;` `goto fail2;` etc, that successively release resources on return; the latter is basically hand-rolling what the language does automatically for you, and has been the cause of at least security-related bug: apple's "goto fail" bug in their SSL implementation). There's still no easy way to break out of nested loops, though. But I have mixed feelings about goto vs continue/break. A nested > loop with multiple continue/break can be as obscure. > I submit that it's in how you write it: if the set of conditions on which one would break/continue are explicit and early in the loop body, it can be a very expressive way to write something. But like any tool, it can be abused. Along those lines, it's always been interesting to me the way that Dijkstra's statement about goto must have influenced language design. The original "GOTO Statement Considered Harmful" note was quite damning, but I wonder if it meant to be: it strikes me that the really dangerous thing about "goto" isn't its mere existence or even its use, but rather, it's unconstrained use when better alternatives exist in the language. As one can observe in well-written C code, judicious use of `goto` can be quite elegant in comparison to the alternative. I've often wondered whether language designers, mindful of the pitfalls of `goto`, eventually took the most useful patterns of its usage and extracted them to stand on their own. Early returns from functions are an obvious example, but so are `break` and `continue` and one might argue exceptions fall into the same category. It strikes me that as we gain ever greater experience with languages, we find more and more examples of things one routinely does using a blunt instrument like goto, and we refine those to first-class features of the language. I think it's also illustrative of how social pressure can influence one to avoid "dangerous" patterns in favor of these language features. C isn't inherently more dangerous because it has a goto statement and labels; most of the time, one doesn't bother to use goto because alternatives exist that are more natural and fill the same role (continue, break, return, etc). - Dan C. --0000000000008e93cc05b56dc31d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Dec 1, 2020 at 3= :40 PM Bakul Shah <bakul@iitbomba= y.org> wrote:
On Dec 1, 2020, at 12:20 PM, Steffen Nurpm= eso <steffen@sda= oden.eu> wrote:
> Never without my goto:, and if it is only to break to error
> handling and/or staged destruction of local variables after
> initialization failures.=C2=A0 Traumatic school impression, finding > yourself locked in some PASCAL if condition, and no way to go to.

Pascal had goto.

Pascal also had to go. (Th= anks...I'm here all week.)

You can even do a non-local goto!

In Go you don't need goto for the sort of thing you and McVoy
talked about due to its defer statement and GC. Now granted
GC may be too big of a hammer for C/C++ but a future C/C++
add defer gainfully as the defer pattern is pretty common.
For example, mutex lock and unlock.

C++= has had something analogous for some time: destructors that run when an ob= ject goes out of scope. Scope guards to do things like close files and auto= -release locks on exiting a critical section are pretty common in that worl= d, and in general, preferable to many of the alternatives (either deeply ne= sted conditionals or banks of labels and `goto fail1;` `goto fail2;` etc, t= hat successively release resources on return; the latter is basically hand-= rolling what the language does automatically for you, and has been the caus= e of at least security-related bug: apple's "goto fail" bug i= n their SSL implementation).

There's still no = easy way to break out of nested loops, though.

But I have mixed feelings about goto vs continue/break. A nested
loop with multiple continue/break can be as obscure.
<= br>
I submit that it's in how you write it: if the set of con= ditions on which one would break/continue are explicit and early in the loo= p body, it can be a very expressive way to write something. But like any to= ol, it can be abused.

Along those lines, it's = always been interesting to me the way that Dijkstra's statement about g= oto must have influenced language design. The original "GOTO Statement= Considered Harmful" note was quite damning, but I wonder if it meant = to be: it strikes me that the really dangerous thing about "goto"= isn't its mere existence or even its use, but rather, it's unconst= rained use when better alternatives exist in the language. As one can obser= ve in well-written C code, judicious use of `goto` can be quite elegant in = comparison to the alternative.

I've often wond= ered whether=C2=A0 language designers, mindful of the pitfalls of `goto`, e= ventually took the most useful patterns of its usage and extracted them to = stand on their own. Early returns from functions are an obvious example, bu= t so are `break` and `continue` and one might argue exceptions fall into th= e same category. It strikes me that as we gain ever greater experience with= languages, we find more and more examples of things one routinely does usi= ng a blunt instrument like goto, and we refine those to first-class feature= s of the language.

I think it's also illustrat= ive of how social pressure can influence one to avoid "dangerous"= patterns in favor of these language features. C isn't inherently more = dangerous because it has a goto statement and labels; most of the time, one= doesn't bother to use goto because alternatives exist that are more na= tural and fill the same role (continue, break, return, etc).

=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.

--0000000000008e93cc05b56dc31d--