From: "Lawrence Velázquez" <larryv@zsh.org>
To: "Philippe Altherr" <philippe.altherr@gmail.com>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCH] Fix ERR_EXIT behavior in function calls and "always" statements
Date: Wed, 23 Nov 2022 23:28:18 -0500 [thread overview]
Message-ID: <2c3123e7-3364-4fb7-8ad5-cc1d5816ccfa@app.fastmail.com> (raw)
In-Reply-To: <CAGdYchs51eibiNVmf_k=tpyfFJz3m0W2aGme=5hnA8oS70ps=w@mail.gmail.com>
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 "() { <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.
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
prev parent reply other threads:[~2022-11-24 4:29 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
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 [this message]
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=2c3123e7-3364-4fb7-8ad5-cc1d5816ccfa@app.fastmail.com \
--to=larryv@zsh.org \
--cc=philippe.altherr@gmail.com \
--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).