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

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

On Thu, 12 Sep 2019 at 03:03, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Wed, Sep 11, 2019 at 5:09 PM Sebastian Gniazdowski
> <sgniazdowski@xxxxxxxxx> wrote:
> >
> > So you've implemented ${|code;} for mksh?
>
> Good grief, no.  I have never even (knowingly) USED mksh.  I just said
> that IF it had been me, I probably would have made a different syntax
> choice.

Ah, I've misread it then.

> > Ok, but this could use ...RLD; REPLY=HERE'. The use of reply is just
> > to simplify, i.e. to use different vars for the (x) embedded code and
> > for the substitution code?
>
> Again, by analogy to the glob qualifier -- the input ($REPLY) is a
> scalar, the output ($reply) is an array (which might or might not get
> string-ified by double-quoting).
>
> In an (e) glob, REPLY is set to each possible file name in turn, but
> $reply can provide multiple names to the final result.  I'm assuming
> you want ${(x...)array} to apply to each array element in turn, not to
> the entire array at once, so again REPLY is a scalar (each array
> element) but could be replaced by multiple elements in $reply.

That's interesting. The mapping could then look like:

array( "a" "b c" "d" )
func() { reply=( ${=REPLY} ); }
array=( ${(x^func^)array} )

and it would result in FOUR array elements, not three. This is a
concrete extension from the mapping via //(#m)*/${(x):-func}, which
cannot extend the array (nor contract it). I think that in order to
allow contraction of the result, the (x) flag could use only reply,
without REPLY as opposed to the (e), unless we do that reply being
just set invalidates REPLY and allows the empty result.

But also, the advanced (x) flag is quite complex. It might be a good
reason to lower the complexity by making the flag substitute only
reply contents.

> I think you grasped it, yes.
>
> Whether the syntax ${(x+func)...} would call "func" once for each
> array element (again by analogy to glob (e+func)) would be an
> implementation choice.  Too bad (x) for globs and (e) for parameters
> already have other meanings, so there's no way to make them use the
> identical key character.

Why only one + in the examples? (I've tried this syntax with (e), it
doesn't seem to support it).

I think that yes, it should call the func per each array element, to
allow the expanding / contracting featured mapping. Also, I wonder
what other interesting things can result from the 2-step code/data
providing to the substitution.

> > > > I think that the (x) flag should be at the top of the list, first.
> > >
> > > That can't be right.
> >
> > Ok, I've did hurry too much. The :- is point 7.
>
> This sounds more sensible.

Great. It seems that we're getting close to a final "draft".

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