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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Tue, Sep 10, 2019 at 11:21 AM Sebastian Gniazdowski
<sgniazdowski@xxxxxxxxx> wrote:
>
> On Tue, 10 Sep 2019 at 07:29, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> >
> > parser tokens, so the stuff that follows them can be parsed at the
> > statement level rather than gobbled up by the parameter substitution
> > code.
>
> Would it be hard to accomplish?

Probably not -- it could mostly share the code for $(...), it would
just have to have different opening and closing tokens.  Without
having given it a huge amount of thought, I suspect I might have
chosen $(|...) instead of ${|...} had I been implementing for mksh ...
but I suppose the idea is that parens imply a subshell where braces
imply the current shell.

> > 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
> > }}
>
> I'm not following the example. Why there's reply= and not reply+=? Why
> in the :- it's reply that's altered, while in (x) there's REPLY?

I'm writing by analogy to the (e) glob qualifier.  Consider:

% touch 'echo HELLO WORLD; reply=HERE'
% print e*(e^'eval $REPLY'^)
HELLO WORLD
HERE

So ${(x^'eval $REPLY'^)var} would be analogous to (minus the implied fork)
  $(REPLY="$var"
    eval $REPLY
    print -r -- "${reply[@]}")

If you change ${var} to ${:-string} then you get
  $(REPLY="string"
    eval $REPLY
    print -r -- "${reply[@]}")

> > 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.
>
> I think that the (x) flag should be at the top of the list, first.

That can't be right.  It's got to at least be after nested
substitution or the parsing for ${...:-...} and similar doesn't make
sense, and it's probably got to be after (P) flag handling if not also
after double-quoted joining.