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

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

On Tue, 10 Sep 2019 at 07:29, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Sep 9, 2019 at 7:21 PM Sebastian Gniazdowski
> <sgniazdowski@xxxxxxxxx> wrote:
> 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?

Yes. this was a founding of the idea, but it then did come to me again
when wanting to apply function to array elements.

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

Would it be hard to accomplish? Because currently the ${...} contents
gets fairly unparsed into stringsubst or paramsubst.

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

I also like that method. I think that the need for the quoting would
be natural because of the way :- works. It would even be less natural
to not need to quote.

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

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

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org