Re: [PATCH] Fix ERR_EXIT behavior in function calls and "always" statements

[Philippe Altherr <philippe.altherr@gmail.com>]

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

>
> Each time though, you've removed the NEWS item.  Although we've
> established that the behavior it describes was not actually
> appropriate, there still has been a change in ERR_EXIT behavior that
> probably warrants a mention.  What's the best description of that?


Good point. There is indeed a behavior change but it's more complicated
than what you described. I will try to come up with something. Actually my
3 fix patches address 3 different issues. In my opinion, at least 2 of them
qualify as bugs but it still makes sense to describe what changes.

This suggests that anonymous
> functions should *not* behave like normal function calls here.


That's debatable. If, like me, you see anonymous functions as some kind of
syntactic sugar, then it makes sense that they behave like function calls
and exit. However, I can also understand that others rather see them as
another type of compound command. In that case, they should not exit.

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. If anonymous functions are changed to behave like compound commands
then anonymous functions behave as if the code was inlined. This changes
the behavior of case E, which currently exits.

Is the compound command behavior a reasonable one? Certainly yes. Is it
desirable? I guess that's more debatable. Personally, I am leaning towards
the current behavior. I could be convinced otherwise and for sure I could
live with the alternative.

If you care about code complexity (of the Zsh implementation), then that
would be an argument against the compound command option as it requires
additional code. However, in my opinion, languages should in general NOT be
designed to simplify their implementation but rather to simplify their
usage.

Does it?  These seem to behave identically with Philippe's latest
> patches; am I overlooking something?


No, with my patch "false && true" and "{ false && true}" now always behave
the same.

Frankly I'm
> still not certain that the extra level of { } should matter in the
> function example.


With my patches, they no longer do. Note however that the behaviors of the
following examples, which are unaffected by my patches:

set -e
> { false && true } # does not exit
> () { false && true } # exits


As you can see, with my patches, an extra level of { } no longer changes
any behavior. However, already today, anonymous functions don't always
behave the same as the inlined code.

FYI: Here are my next steps
- Write NEWS for my 3 fixes.
- Better document the role and usage of noerrexit and this_noerrexit.
- Try to fix "eval", "source", and possibly a bunch of other related cases.

Unless anyone sees a reason not to, it would be nice to submit my first
pacth, which reverts Bart's changes. For the other patches, I have at the
very least to first add a NEWS item.

Philippe

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