Re: [PATCH] Support the mksh's ${|func;} substitution

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mon, Sep 9, 2019 at 7:21 PM Sebastian Gniazdowski
<sgniazdowski@xxxxxxxxx> wrote:
>
> The feature would be: a new substitution flag (x for execute, or | to
> mark similarity to mksh's ${|code;}) that would execute the provided
> code and substitute the value of $REPLY.
[...]
> The usefulness is the ability to map code onto array elements (with
> (#m) or (#b) flags) and general lambda-like use-case.

I've been kinda-sorta following this thread amidst a bunch of other
"real life" distractions.  Is the deep meaning here the desire to have
a $(...) that doesn't fork?

I don't particularly like either mksh's or ksh93's choice of syntax
for these variations, but they do have the advantage of being real
parser tokens, so the stuff that follows them can be parsed at the
statement level rather than gobbled up by the parameter substitution
code.  That is, ideally these two examples --

> - echo ${(x):-REPLY=test2} -> test2
> - noglob print -rl ${(x):-for val (test test3) {
> REPLY=\$val
> }}
> -> test3

-- would be parsed more like $(...) is parsed (and at roughly the same
place in the parser), so that (among other things) you would not have
to quote \$val like that.

On the other hand the "var='...'; echo ${(x)var}" example seems
reasonable and would enable those other two uses as a side-effect.

I still have a nagging feeling that it should be more like the
(e^...^) globbing flag, in particular the part about returning arrays
through reply=(...) but also whether it might look like
${(x^code^)var} where "code" would receive the current value of the
substitution as $REPLY and return the new value in $reply.  Your "for"
example could still I think come out like:

${(x^eval $REPLY^):-for val (test test3) {
reply=\$val
}}

Other things that need to be thought about before this gets a go/no-go
are nested substitutions and how to fit (x) into the order-of-events
subsect(Rules) as laid out in expn.yo.