Re: feature request: new builtin `defer`, scope delayed eval

[Cynthia Coan]

Hi Koichi,

> I did notice your link to the Gist example, but I have to say that it
> misuses the RETURN trap. As I have written in the previous reply, the
> RETURN trap is already designed to be function-local so that it suits
> your use cases. However, the Gist version somehow disables the
> function-local nature of the RETURN trap by running `set -o functrace'
> and instead tries to implement the function-local behavior by itself.
> I also have implemented a wrapper (and the generalized mechanism) of
> the trap in my project [1], but I admit that this is overcomplicated
> for the general advice in the Bash mailing list (the entire code has
> about 1000 lines). But if you are interested in a larger framework,
> you might be interested in it.
>
> [1] 
> https://github.com/akinomyoga/ble.sh/blob/a144ffa807b40baa2b58f558cdd3b22bca44d38e/src/util.hook.sh#L42-L61
> I agree the proper implementation of `defer' by the RETURN trap could
> be tricky (as described in "notes" in my previous reply), but it's
> definitely not as hard as you initially posted (one 12-line function
> vs 244-line defer.sh).

This is definitely where the PoC nature comes in. I agree there are
many different ways of implementing this. To point out where the lines
come from, out of those "224" lines, removing all the comments (and
extra functionality that is included in the same file) gets us down to
< 60 lines, and the reason it implements the "function local" state
itself is because for quickness of a PoC it was copied from an "error
mode" example which does need to implement function local checks
itself (with functrace), as if  the function "sets error mode", and
than calls another function which changes the error mode not through a
wrapper you'd be in the wrong state for the rest of the function. So
you always need to check where you are. That being said, I'm sure
those PoC's could be tuned much better and be created in much smaller
line amounts! I don't think we need to spam the mailing list with
potential implementations of either of these though.

I'd prefer we don't focus on any particular implementations, or how
many lines they end up being. After all, again what is a local
variable if not a variable with a deferred unset/set to old value?
That could be just as easily implemented, yet we still found its
utility, and brevity worthy enough of adding to bash. I'm not saying
defer necessarily meets the same bar as usefulness, but I think it'd
be wrong to dismiss new features just because they can be accomplished
today, with relatively few lines. If we find something lots of people
are doing, it might be worth discussing adding it in (and again: I'm
totally willing to admit defer/defer-like might not meet that bar)!

> Could you describe it in more detail or could you provide an example
> of how this can mess up? For example, the quoting of the trap string
> in the output of `trap -p' is processed by "eval" in the second line
> of the function body. I currently don't see any other parts where the
> quoting is relevant.

Yep that's on me, I totally missed the eval. Apologies!

> I actually don't see sufficient reasons to add a builtin command or
> add `append/prepend' options to trap.
> The suggested `builtin' can be implemented by a short shell function
> of about 10 lines. If we finally conclude that the suggested `defer'
> is useful for the general Bash scripting, we can just include it in
> /examples/functions in the Bash source tree.

Interesting, is this purely about lines of code? I don't think we'll
agree on that point, but I'm curious if you think this is something
that is used a lot vs. just easy enough in terms of lines. I'm
certainly not opposed to adding things to bash examples, if they're
not generally usable!

> As for the `append/prepend' option, I think they would be very useful,
> but I think it requires more careful and comprehensive discussions.
> For example, it is non-trivial to find well-defined semantics for the
> multiple separate trap handlers containing the commands that affect
> the control flow outside the trap (such as continue, return, break,
> etc.). It might also conflict with the existing idioms of trap/signal
> handlers that assume the single trap handler such as `trap - INT &&
> kill -INT "$BASHPID"' for SIGINT. How to choose a single exit status
> of the DEBUG trap which would be used to determine the next action by
> Bash? etc.
>
> On the other hand, I think `trap -P' suggested by Oğuz can be safely
> added without conflicting existing behaviors, but this is more general
> and can be considered separately from the defer implementation.

I'm certainly hopeful to have those discussions, I opened this wanting
to get feedback/drive discussion, and if it requires more discussion
I'd love to do that. I think either way in general the mailing list
seems to agree that "defer" as a built-in probably not the way to go,
so I think we can drop that mostly (or just add it to the examples
like you mentioned)! On the traps append/prepend point I will have to
do some thinking on that, I'll take the weekend/beginning of the week
to think of what I can, but if someone else has ideas I would love to
hear those too.

Appreciate all your feedback,
Cynthia