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

[Robert Elz]

    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, I have considered it from time to time (not for bash which I have
nothing to do with except as a user) - but needs no special syntax, just the
implementation, and removal of the restriction on the local builtin (or
whatever underlies that in bash) that only permits it when a function is
active.   I don't know about bash, but in the shell I maintain the
implementation would be trivial.

But I suspect that you want this to be more like (what I think is called)
a lambda expression - that is, a essentially a function definition that
is immediately called, and then forgotten, but it isn't clear if you want
it to be able to have parameters or not.

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

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?

The last part of that is very unlikely - I have toyed with (and actually 
implemented a few times) new special parameters, but never released a
version with a new one in it - aside from (perhaps, and only perhaps) zsh
I don't think there's ever been a new special parameter added to any
shell, ever, since the original set in the first Bourne sh from 1979 (or
before).   For some reason that list is considered set in stone.

A more normal approach (more common approach for modern shell extensions)
would be to use a traditional, but special, variable name (kind of like
bash/ksh uses REPLY for read, and shells use OPTIND OPTARG etc with getopts).

But of course, if you do it that way, then instead of

        return n x

you can already do

        MAGIC_VAR=x
        return n

and not have to alter the syntax of return.

  | ${{ }} - Executes like {{ }} but also expands to the value of $:

That would need a lot more specification.   Is there a subshell involved?
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?

  | $: 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.

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

  | 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.   Then it just becomes a question of whether those benefits
are worth the cost and complexity of the implementation.

  | Second
  | would be so I'm sure I don't unset a global variable when unsetting an
  | iterator in an initialization script to keep the variables clean, even
  | just by theory.

The local variables in blocks part of your proposal is the one part that
is both realistic and potentially useful (and probably fairly easy).

kre