zsh-workers
 help / color / mirror / code / Atom feed
From: Philippe Altherr <philippe.altherr@gmail.com>
To: "Lawrence Velázquez" <larryv@zsh.org>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCH] Fix ERR_EXIT behavior in function calls and "always" statements
Date: Wed, 23 Nov 2022 10:43:36 +0100	[thread overview]
Message-ID: <CAGdYchs51eibiNVmf_k=tpyfFJz3m0W2aGme=5hnA8oS70ps=w@mail.gmail.com> (raw)
In-Reply-To: <db62b2d2-b2db-47c1-b20c-2a30c7eee088@app.fastmail.com>

[-- Attachment #1: Type: text/plain, Size: 5105 bytes --]

>
> 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 "() { <body> } <args>" is syntactic sugar for "anon() {
<body> }; { anon <args> } 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ázquez <larryv@zsh.org> wrote:

> 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            Exit
> > B)         false && true            No exit         No exit         No
> > exit
> > C)     {   false && true   }        No exit         No exit         No
> > exit
> > D)  () {   false           }        Exit            Exit            Exit
> > E)  () {   false && true   }        Exit            Exit            *No
> > exit*
> > F)  () { { false && true } }        No Exit         *Exit*
> > No exit
> > G) f() {   false           }; f     Exit            Exit            Exit
> > 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
>

[-- Attachment #2: Type: text/html, Size: 6815 bytes --]

  reply	other threads:[~2022-11-23  9:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16 14:40 Philippe Altherr
2022-11-19 13:39 ` Philippe Altherr
2022-11-21  0:43   ` Bart Schaefer
2022-11-21  7:22     ` Lawrence Velázquez
2022-11-22  2:52       ` Philippe Altherr
2022-11-22  4:51         ` Bart Schaefer
2022-11-22 10:17         ` Peter Stephenson
2022-11-23  8:11           ` Lawrence Velázquez
2022-11-23  6:59         ` Lawrence Velázquez
2022-11-23  9:43           ` Philippe Altherr [this message]
2022-11-23 16:11             ` Bart Schaefer
2022-11-23 20:57               ` Submitting multiple patches (was: Re: [PATCH] Fix ERR_EXIT behavior in function calls and "always" statements) Daniel Shahaf
2022-11-23 21:11                 ` Bart Schaefer
2022-11-23 21:22                   ` Bart Schaefer
2022-11-23 21:54                   ` Bart Schaefer
2022-11-24  2:21                     ` Philippe Altherr
2022-11-26  2:28                       ` Bart Schaefer
2022-11-26  4:02                         ` Philippe Altherr
2022-11-24  1:47               ` [PATCH] Fix ERR_EXIT behavior in function calls and "always" statements Philippe Altherr
2022-11-24  4:28             ` Lawrence Velázquez

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to='CAGdYchs51eibiNVmf_k=tpyfFJz3m0W2aGme=5hnA8oS70ps=w@mail.gmail.com' \
    --to=philippe.altherr@gmail.com \
    --cc=larryv@zsh.org \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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. 
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

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