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,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30976 invoked from network); 23 Nov 2022 09:44:11 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 23 Nov 2022 09:44:11 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1669196651; b=Rc2CB2UnVAMG81OXX0VDl1rUo9aJY8j+xhgem65NdWk/yVo8scLMGDq8z0Eku4V15ymkle80gj ApRIYYCwWiyf/eCZFO2/CimMCfiE97FOlnQ0hxU3Yl1PkQzMVbswDLuudvqyaN0neRVwKREP68 3yYDu9cnrnGZoRKyBRDh3cipbkQhjx4xZekiwHGn/Z2R6lBeqmdWxLVWcWvqlXPAYZDbhhFYWv 4yJZ3UUf+aAv/QHKIJkvh2f5gLbOJMmsSfXIwIQMIce9MS3Qscb1rQlNpEHm1XIAM9EWOY2kOo H4IADEsMeHhe/0VelN53bCTCPFEoH3WUZ5l8x7+zgb1+/A==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-vs1-f42.google.com) smtp.remote-ip=209.85.217.42; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1669196651; bh=Cb4Qvcpmaz+Pk9UK0ZVPHGYliD7Xz4sGBmquD9z/9CA=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=Ft6Jf9dv39HAgHYgU1bmdIjEnixdRJZ3AVsM2Z/tbLZODnXrJqUdIvr7iQqx7MHAvB+IOiv0aC YXB29lFH4hXACusKWScvhP7JkG/xUYZB+4ADDCQAUAYH83wWXm1WZjJ2Rg+MrNGd/qKrCvRx90 3QQs1dCd0WGRCH+/0OSpbDEa01n/Y/HCl5elTjFYayT6AO7FRbkFueIP/ErOTYv7NxZGAZdOsj pX7d4nGRRH7cRKfqwo44qm9O6WgfkhrDye0PyHZtgtsKJvmig1h2faYfEOxWB5LRNfrmyZLeDj yXV3LRHpU1Hpqi+c+iB53EnfBaGyRMBV8PnkWUfOSMAVSA==; 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:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References: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=OYG4EqaBfp7lTZPWHYI6oMVdV1dHota1PFxR6NTpL8o=; b=n33WLWZ5AcQeFBANnL96PVxDSG ltDUm/rdIdVww/Bav+7qlQjxl4tKofKTbae/UEQpaWUIdht+use5gpMeMLR5cg6+gqt/RRaFIyTxy 9Sw0SgLSMEPRgHr1t5OO5oLLmuiO1uDrlSE18BfCDu85ewOEOjgrbbKSuc1tAxSsKO7YcBZwnxKvc gYjI414f5UUiSOzliWG4heshTHMO8B7egKCUhP7TR7IULQPD5tbqmXm1HM7ZKdbdTtORfnaVR/+6H XsHbNXA6I9YgpuN85jDlDZc6DRj/9V0gV/JlF4/Zflrx1K9nNUQllrMs7YSmh2VlE+mZnCL6RjdRK Iy9EvYSg==; Received: by zero.zsh.org with local id 1oxmIc-0004jN-Ew; Wed, 23 Nov 2022 09:44:10 +0000 Authentication-Results: zsh.org; iprev=pass (mail-vs1-f42.google.com) smtp.remote-ip=209.85.217.42; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-vs1-f42.google.com ([209.85.217.42]:33572) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1oxmII-0004Q5-86; Wed, 23 Nov 2022 09:43:50 +0000 Received: by mail-vs1-f42.google.com with SMTP id d185so16978336vsd.0; Wed, 23 Nov 2022 01:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OYG4EqaBfp7lTZPWHYI6oMVdV1dHota1PFxR6NTpL8o=; b=TKleQ/T0BbqlY6UEAtVL8Wsmkp+h2CfGD6LPrLTW8RoS3wm/egniqWkZDSEC0x0R0u OnUMrIY+kCul94vDwHpHhBdZf5my95RN1D2n8SUeGbTqMsAZilFUiL0x2Ns5S9D2dnNj NmIwsZnte7XZBU2Q+fOMhqT1BpeJWEXBNKa2kJcHuRPVbzCdxCpaYTVHwPTeUnTFPHcI 8VXHVAxicushUucvsN1lP9qrh6H7MYd4+0YmtT6hclqJ3Y0FKmFJ4WUtGipf2GRQ0yzV zba2ldH0q62uXJ0slQhC/E600s63TKhGYyhWsEZin1EO/vrtEcf7Fh81uaMq1n2yyaek pnAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OYG4EqaBfp7lTZPWHYI6oMVdV1dHota1PFxR6NTpL8o=; b=edd4SbNFCiSX4lweZASJxFkvw5bLBCpedENHquOxBvb/0+LCwdxbjp8IFeOnKWFcjK OA7tHWjbb6rt4nk5gJSQULfHs519nh/CEb5iu/T5VfzozD+EakgeDVuaVUB7xyC7+8j0 iSkx477mV6qxJKAvdLgBujlqODWnXgK+Ln5c8PtcIlTr9HIwKG0qkis+fav85E97IJJj yJrXnFdzlJki4PWxwyxzWyZpPD6+ZQNyraCUY5EHL6aY6q9wuMbDOZIaoC9dXPneUqqz HLEwmlofXImJKCwWMAPrcq/RBdzUbWTKspvonozVg/H2Dk5CJSq2N5k8cf+mlLNrmdf3 AGjw== X-Gm-Message-State: ANoB5pnHhgOC67aEmkn43RfO9d16GUO0a4GRosOJpQL405R9MoL9eLhG EMsIkQA2DRlRXXkMbvJb91sEdFYasfK6n3AcVYcVYQhLfEg= X-Google-Smtp-Source: AA0mqf61CCr/kdUZI0hUQRjDvYfVsP2uupSnq+Tb5r2hsz/RrmWv6z9vlfzhCbx0AWajdzgMWUPboHcl8vYQVyrRLEA= X-Received: by 2002:a05:6102:3e1c:b0:3af:2ddf:32a1 with SMTP id j28-20020a0561023e1c00b003af2ddf32a1mr4880339vsv.81.1669196628158; Wed, 23 Nov 2022 01:43:48 -0800 (PST) MIME-Version: 1.0 References: <230a78bb-fa97-4f3a-94a2-86982316274b@app.fastmail.com> In-Reply-To: From: Philippe Altherr Date: Wed, 23 Nov 2022 10:43:36 +0100 Message-ID: Subject: Re: [PATCH] Fix ERR_EXIT behavior in function calls and "always" statements To: =?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= Cc: zsh-workers@zsh.org Content-Type: multipart/alternative; boundary="00000000000014ed1405ee2020cf" X-Seq: 51032 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: --00000000000014ed1405ee2020cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > POSIX does not mandate any behavior for case F unless one treats anonymous functions as compound commands 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 POSIX mandates the behavior for both, function calls and compound commands. Therefore, if we opt for one of these two specifications, POSIX also indirectly mandates the behavior of anonymous functions. 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. You propose to specify anonymous functions as a kind of compound command. This is of course possible but it's not how anonymous functions currently behave. As far as I can tell, they currently behave in all aspects, including ERR_EXIT, as function calls. For ERR_EXIT, see case E, which behaves like the equivalent function call (case H) and not like the equivalent compound command (case B). Note that this is true with and without my patch. Beside the new behavior for ERR_EXIT are there other aspects of anonymous functions that would/should change? If not, is that change of specification really worth it? 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 My feeling is that changing anonymous functions to behave like compound commands adds complexity for little benefit. If it's all about the ERR_EXIT behavior, does that really matter that much? Is there a use case for anonymous functions where the compound command ERR_EXIT behavior is significantly better than the function call ERR_EXIT behavior? I'd also prefer to post all your patches at once because you attached > them all to the same zsh-workers article. Convention has been that a > series of patches should be sent as a series of articles. OK, then I will resend my patches in separate emails. This way I can better document what each one is doing. It will also be easier for you (or whoever submits patches) to sooner submit the less controversial ones while the more controversial ones remain open for discussion. I don't think there's any requirement that the NEWS item arrive at the > same time as the other three patches. We sometimes don't add NEWS > until the time of a release, months (years) after a patch was pushed > to sourceforge git. I see. In that case I will start another thread with a patch for the NEWS item where we can discuss the exact wording. Philippe On Wed, Nov 23, 2022 at 7:59 AM Lawrence Vel=C3=A1zquez wr= ote: > On Mon, Nov 21, 2022, at 9:52 PM, Philippe Altherr wrote: > > To help decide what to do, here is a table that lists all the different > > cases and how they behave in the current Zsh, in a patched Zsh, and in > > a patched Zsh where anonymous functions behave as compound commands: > > > > Code Current Zsh Patched Zsh > > Compound command (and patches) > > A) false Exit Exit Exi= t > > B) false && true No exit No exit No > > exit > > C) { false && true } No exit No exit No > > exit > > D) () { false } Exit Exit Exi= t > > E) () { false && true } Exit Exit *No > > exit* > > F) () { { false && true } } No Exit *Exit* > > No exit > > G) f() { false }; f Exit Exit Exi= t > > H) f() { false && true }; f Exit Exit > > Exit > > I) f() { { false && true } }; f No Exit *Exit* > > *Exit* > > > > Currently anonymous functions behave like function calls. My patches > > don't change that but they change/fix cases F and I to behave as > > mandated by POSIX. > > POSIX does not mandate any behavior for case F unless one treats > anonymous functions as compound commands, in which case the new > behavior actually violates the standard. > > -- > vq > --00000000000014ed1405ee2020cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
POSIX do= es not mandate any behavior for case F unless one treats
anonymous functions as compound= commands

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 defin= ed on the spot and undefined right after the call)
B) a compound = command

POSIX mandates the behavior for both, func= tion calls and compound commands. Therefore, if we opt for one of these two= specifications, POSIX also indirectly mandates the behavior of anonymous f= unctions.

In my opinion, the name and the desc= ription of anonymous functions strongly suggests that anonymous functions a= re a shorthand for defining a function, calling it with the provided argume= nts, and undefining the function. I have always assumed that "() { <= ;body> } <args>" is syntactic sugar for "anon() { <bo= dy> }; { anon <args> } always { unfunction anon }". As far as= I can tell, Zsh effectively implements anonymous functions with=C2=A0funct= ion calls. If this is indeed the case and one agrees with the specification= described here, then everything is consistent; anonymous functions look, f= eel, and behave like function calls, including when it comes to ERR_EXIT, a= nd this with and without my patches.

You propose t= o specify anonymous functions as a kind of compound command. This is of cou= rse possible but it's not how anonymous functions currently behave. As = far as I can tell, they currently behave in all aspects, including ERR_EXIT= , as function calls. For ERR_EXIT, see case E, which behaves like the equiv= alent function call (case H) and not like the equivalent compound command (= case B). Note that this is true with and without my patch. Beside the new b= ehavior=C2=A0for ERR_EXIT are there other aspects of anonymous functions th= at would/should change? If not, is that change of specification really wort= h it? I fear that anonymous functions as compound commands require a more c= omplicated mental model than anonymous functions as function calls. For exa= mple, if anonymous functions are compound=C2=A0commands then I would expect= that the "return" in the code below exits the function "foo= " but that's not what it does.

foo() {
=C2=A0 echo foo-start;
=C2= =A0 () { echo args: $@; return } 1 2 3
=C2=A0 echo foo-end;
}
foo<= /blockquote>

My feeling is that changing anonymous funct= ions to behave like compound commands adds complexity for little benefit. I= f it's all about the ERR_EXIT behavior, does that really matter that mu= ch? Is there a use case for anonymous functions where the compound command = ERR_EXIT behavior is significantly better than the function call ERR_EXIT b= ehavior?

I'd also prefer to post all your patches at once because you attach= ed
them all to the same zsh-workers article.=C2=A0 Convention has been t= hat a
series of patches should be sent as a series of articles.

OK, then I will resend my patches in separate email= s. This way I can better document what each one is doing. It will also be e= asier for you (or whoever submits patches) to sooner submit the less contro= versial ones while the more controversial ones remain open for discussion.<= /div>

I don= 't think there's any requirement that the NEWS item arrive at thesame time as the other three patches.=C2=A0 We sometimes don't add NE= WS
until the time of a release, months (years) after a patch was pushed<= br>to sourceforge git.

I see. In that case = I will start another thread with a patch for the NEWS item where we can dis= cuss the exact wording.

Philippe


On Wed, Nov 23, 2022 at 7:59 AM Lawrence Vel=C3=A1zquez <larryv@zsh.org> wrote:
On Mon, Nov 21, 2022, at 9:52 PM, Phili= ppe Altherr wrote:
> To help decide what to do, here is a table that lists all the differen= t
> cases and how they behave in the current Zsh, in a patched Zsh, and in=
> a patched Zsh where anonymous functions behave as compound commands: >
>=C2=A0 =C2=A0 Code=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Current Zsh=C2=A0 =C2= =A0 =C2=A0Patched Zsh=C2=A0 =C2=A0 =C2=A0
> Compound command (and patches)
> A)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0false=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit
> B)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0false && true=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 No exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0No ex= it=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0No
> exit
> C)=C2=A0 =C2=A0 =C2=A0{=C2=A0 =C2=A0false && true=C2=A0 =C2=A0= }=C2=A0 =C2=A0 =C2=A0 =C2=A0 No exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0No ex= it=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0No
> exit
> D)=C2=A0 () {=C2=A0 =C2=A0false=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0}=C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit
> E)=C2=A0 () {=C2=A0 =C2=A0false && true=C2=A0 =C2=A0}=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *No
> exit*=C2=A0 =C2=A0
> F)=C2=A0 () { { false && true } }=C2=A0 =C2=A0 =C2=A0 =C2=A0 N= o Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Exit*=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0
> No exit
> G) f() {=C2=A0 =C2=A0false=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}; = f=C2=A0 =C2=A0 =C2=A0Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit
> H) f() {=C2=A0 =C2=A0false && true=C2=A0 =C2=A0}; f=C2=A0 =C2= =A0 =C2=A0Exit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Exit=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0
> Exit=C2=A0 =C2=A0
> I) f() { { false && true } }; f=C2=A0 =C2=A0 =C2=A0No Exit=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Exit*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0
> *Exit*
>
> Currently anonymous functions behave like function calls. My patches <= br> > don't change that but they change/fix cases F and I to behave as <= br> > mandated by POSIX.

POSIX does not mandate any behavior for case F unless one treats
anonymous functions as compound commands, in which case the new
behavior actually violates the standard.

--
vq
--00000000000014ed1405ee2020cf--