Re: Add {{ }}, ${{ }}, return n [x], and $:

[konsolebox]

On Fri, Apr 30, 2021 at 4:09 PM Robert Elz <kre@munnari.oz.au> wrote:
>
>     Date:        Fri, 30 Apr 2021 14:53:58 +0800
>     From:        konsolebox <konsolebox@gmail.com>
>     Message-ID:  
> <CAJnmqwaE5On6kPJoOb=yAC3UM=8jErm=NHuXtgj=V9uE5YiZpQ@mail.gmail.com>
>
>   | {{ }} - Similar to { }, but runs like a function so variables can be
>   | declared local
>
> From below, I suspect you mean more, though you haven't fully defined what you
> mean, but extending local to be able to apply in a block is not a terrible
> idea,

That was my initial idea too, but I think it's better to just leave {
} alone as modifying its behavior still has a chance of breaking
scripts.

But maybe a shell option can be introduced.

In that case {} will almost be similar to {{ }} except that calling
return inside would exit the function.

> but it isn't clear if you want
> it to be able to have parameters or not.

It will inherit or access the parent context's arguments just like in
{ } and ( ), virtually.

>   | return n [x] - Assigns n to $? and x to $: if specified

> I think there are two aspects to that.  First, you want return to work
> inside the proposed {{ }} syntax - that would need the new syntax, it cannot
> be done with a regular { } block without breaking backwards compat.

I don't think it would break compatibility.  `return n` will still
work.  Is there something I missed?

> And second to have two (just 2, or can the 'x' be anything?) return
> values, one being the exit status, and the other becoming the value of
> a magic new special parameter.   Does this variant of return work in
> regular functions as well?

Yes that's the plan.

>   | ${{ }} - Executes like {{ }} but also expands to the value of $:
>
> That would need a lot more specification.   Is there a subshell involved?

There won't be, just like in {{ }}.

> what's the syntax for the enclosed (missing here) piece, and how is it
> supposed to be parsed?   One assumes that everything there is intended to
> be a part of a word, are the results subject to later expansions?

${{ }} would be parsed and expanded just like $() but commands within
it will run in the context of a temporary anonymous function.

>   | $: will be reset to an empty string at the beginning of any
>   | non-assignment execution context.
> I'm not sure exactly what that means, but regardless, why?   Whether it
> is a special parameter, or just a variable (with a value used by magic in
> some cases) I'd expect it to work more like $! - something causes it
> to be set, then it simply retains its value until something else happens
> that makes it change value - in the interim it can be referenced as
> many times as you want.

It's to emulate how $? behaves, and also so people would write more
readable code.  The value of $: should be perceived as temporary.
Keeping it unchanged for a long time makes it difficult to find the
source that assigned it unless you wrote the code yourself.  I believe
each function should also have its formal default return value so an
old value won't be returned if a command fails to execute.

>
>   | The string can be a constant static for the sake of efficiency.
>
> I don't know about in the internals of bash, but it almost certainly
> can't.  I also wouldn't worry about efficiency for something as trivial
> as this (saving a string value) - shells do a LOT of that.

It's an optional enhancement to implementation.

>   | The greatest goal of these features is to help eradicate the
>   | inefficient var=$(echo "returned value") practice people do.
>
> So, an alternative would simply be to make that efficient...   In cases
> like that there's no need for the shell to fork (though most do).
> Doing this is just a matter of careful coding, it requires no new syntax
> or anything else that affects any existing scripts (where {{, though
> not ${{ might) and has the benefit that everyone benefits, without needing
> to rewrite code.

This optimization can be done as well as a separate target but $() can
never be optimized enough as it almost would always rely on an opened
pipe.  It would also be difficult to tell if one of the commands
within it would send a message to &1 or not, or if one of them would
execute `exec`.  You also would almost always want to enable the
subshell to avoid the parent from getting its parameters altered.

> Then it just becomes a question of whether those benefits
> are worth the cost and complexity of the implementation.

Not sure about the complexity but I  think the benefits would be worth it.


--
konsolebox