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=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3500 invoked from network); 24 Nov 2022 04:29:02 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 24 Nov 2022 04:29:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:Subject:Cc:To:From:Date: References:In-Reply-To:Message-Id:Mime-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=nH4GaQCBd74aPE1iD+d2Xg7rZdLtNonwwXFQ4ZYweyQ=; b=AsD4/oCYFJZQtSFmDK6z1OJTIg k3oUjgP3Gt2B2VprTauQEpIAtcBGf8JeI57rjw2pGtKFMD/R763hfqD4y9Xsam5PbyTJUikerkcMT MllDcYszMZJhtnEaVahZaFGIhxx5odWZYoZ0aXKw/gntX8odtn5S+c8OhbeVTotN5XlNjgaqSCIcq DlHAyUfzBPwTsRlLx8tsv9rgFXExber01jHVethE4L2wFEiBeM673InAbAgV3U/fEcTCjAai0HHq7 4L7aNVIs0XTD2sEZ1Z36LbPsoqYX6lUfCUX5d6kZWlN7gExrSYaKBejiggY6m5YJ7TBMuNdqz8z2K PSFPcwHg==; Received: by zero.zsh.org with local id 1oy3rC-000Ky4-7Y; Thu, 24 Nov 2022 04:29:02 +0000 Received: by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1oy3qt-000KdZ-3H; Thu, 24 Nov 2022 04:28:43 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id D3B8D27C0054; Wed, 23 Nov 2022 23:28:38 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute2.internal (MEProxy); Wed, 23 Nov 2022 23:28:38 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedriedvgdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreerjeenucfhrhhomhepnfgrfihr vghntggvucggvghljoiiqhhuvgiiuceolhgrrhhrhihvseiishhhrdhorhhgqeenucggtf frrghtthgvrhhnpeelkeehjefgudefgeekueegudeghfevvdeljeehieeuffehveejgfeh tefhudevhfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehlrghrrhihvhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduhedu keejjedtgedqudduledvjeefkeehqdhlrghrrhihvheppeiishhhrdhorhhgsehfrghsth hmrghilhdrtghomh X-ME-Proxy: Feedback-ID: iaa214773:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 905FD31A0063; Wed, 23 Nov 2022 23:28:38 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead Mime-Version: 1.0 Message-Id: <2c3123e7-3364-4fb7-8ad5-cc1d5816ccfa@app.fastmail.com> In-Reply-To: References: <230a78bb-fa97-4f3a-94a2-86982316274b@app.fastmail.com> Date: Wed, 23 Nov 2022 23:28:18 -0500 From: =?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= To: "Philippe Altherr" Cc: zsh-workers@zsh.org Subject: Re: [PATCH] Fix ERR_EXIT behavior in function calls and "always" statements Content-Type: text/plain X-Seq: 51059 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: On Wed, Nov 23, 2022, at 4:43 AM, Philippe Altherr wrote: > I think POSIX indirectly mandates the behavior. So far, there are two > proposals on how to specify anonymous functions: > > A) a function call (to a function defined on the spot and undefined > right after the call) > B) a compound command Anonymous functions are complex commands regardless; they are parsed much like function definitions. The question here is only about how they should interact with ERR_EXIT. > In my opinion, the name and the description of anonymous functions > strongly suggests that anonymous functions are a shorthand for defining > a function, calling it with the provided arguments, and undefining the > function. I have always assumed that "() { } " is > syntactic sugar for "anon() { }; { anon } always { > unfunction anon }". As far as I can tell, Zsh effectively implements > anonymous functions with function calls. If this is indeed the case and > one agrees with the specification described here, then everything is > consistent; anonymous functions look, feel, and behave like function > calls, including when it comes to ERR_EXIT, and this with and without > my patches. This "syntactic sugar" argument is flawed in its very conception because the POSIX specification for "set -e" is *all about syntax*. It addresses the early-exit behavior of various *syntactic* command forms -- pipelines, compound commands, AND-OR lists. It does not know or care about function calls; it does not mention them even once. They are just simple commands as far as POSIX "set -e" is concerned. To be clear, there is nothing wrong with considering anonymous functions to be syntactic sugar for defining, calling, and removing a function, but that does not change their syntax. They *are* complex commands. It doesn't matter how they're implemented or how you want to think about them -- you cannot reasonably use POSIX to justify giving them the same early-exit behavior as vanilla function calls. Of course, that need not stop us from doing so. POSIX compliance is not a requirement for zsh, anonymous functions are already well outside the POSIX spec, and carving out a (...)-like exception for them (as Bart originally suggested) has a lot to recommend it (as I agreed with in my response to Peter). But at this point POSIX is more or less out of the picture. Which is fine. > You propose to specify anonymous functions as a kind of compound > command. No, I did not propose that. I presented two possibilities for anonymous functions' behavior with respect to ERR_EXIT, elaborated on "like other complex commands" because I thought the argument for "like regular function calls" was self-evident, and explicitly expressed ambivalence about which was best. Plus, they already are complex commands. > I fear that anonymous functions as compound commands require a more > complicated mental model than anonymous functions as function calls. > For example, if anonymous functions are compound commands then I would > expect that the "return" in the code below exits the function "foo" but > that's not what it does. > >> foo() { >> echo foo-start; >> () { echo args: $@; return } 1 2 3 >> echo foo-end; >> } >> foo Why would you expect that? "Complex command" is a syntactic classification that doesn't imply any particular behavior. It includes {...}, (...), function definitions, the various loops and conditionals, etc., but these all behave differently. -- vq