From: Sebastian Gniazdowski <sgniazdowski@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [PATCH] Support the mksh's ${|func;} substitution
Date: Thu, 12 Sep 2019 02:08:49 +0200 [thread overview]
Message-ID: <CAKc7PVBoDMFNiQ8jW2uh9tw5axeLpj=MyPiYD_umpqeBsOi9zQ@mail.gmail.com> (raw)
In-Reply-To: <CAH+w=7Y1Mcy+rrn7CGV+Befo-5PeX-gaHU19yErhCsw=2PCH+A@mail.gmail.com>
On Tue, 10 Sep 2019 at 21:38, Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Tue, Sep 10, 2019 at 11:21 AM Sebastian Gniazdowski
> <sgniazdowski@gmail.com> wrote:
>
> > 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.
So you've implemented ${|code;} for mksh?
> > > ${(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
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?
> 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[@]}")
Ahso. So the ${(x^'eval $REPLY'^)var} in the end could be ${(x^'eval
func^):-} ? I.e. the code to evaluate would be provided within the (x)
delimiters, and the connection with REPLY <-> substitution value (i.e.
$var or :-string) would be additional?
> > 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.
Ok, I've did hurry too much. The :- is point 7.:
7. Modifiers
Any modifiers, as specified by a trailing `#', `%', `/' (possi‐
bly doubled) or by a set of modifiers of the form `:...' (see
the section `Modifiers' in the section `History Expansion'),
are applied to the words of the value at this level.
It seems to be a good place for the (x) to be put, but with the point
broke down into :- and the other modifiers – they modify the value and
it makes more sense to modify the output of the evaluated code than
the code itself.
All the following points seem to operate in on-value like fashion, so
they should go after (x). The preceding ones OTOH operate in an
select-value like fashion, e.g.:
- subscripting, ${(x)arr[2]} makes sense to operate on the $arr than
on the $REPLY (evaluation result),
- (P), in ${(xP)var} the P makes more sense to operate on $var rather
than on the result of the evaluation – what would it be, to provide a
parameter name for P through an evaluation of code? it does sound
tempting, but the clear-situation that comes from P being always first
is more safe. The programmer that would want to provide a parameter
name through evaluation can do the evaluation manually before the
${(P)var}. It will be possible even in an on-array mapping situation:
arr=( "REPLY=param1" "REPLY=param2" )
: ${a[@]/(#m)*/${${param::=${(x)MATCH}:+}${(P)param}}
- the same exception as for (P) in point "2. Internal parameter flags"
seems to make sense also for (x)
--
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org
next prev parent reply other threads:[~2019-09-12 0:10 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-06 0:52 Sebastian Gniazdowski
2019-09-06 0:54 ` Sebastian Gniazdowski
2019-09-06 23:16 ` Sebastian Gniazdowski
2019-09-07 12:16 ` Daniel Shahaf
2019-09-07 15:07 ` Stephane Chazelas
2019-09-07 18:09 ` Sebastian Gniazdowski
2019-09-07 20:19 ` Stephane Chazelas
2019-09-07 21:19 ` Sebastian Gniazdowski
2019-09-10 2:20 ` Sebastian Gniazdowski
2019-09-10 5:29 ` Bart Schaefer
2019-09-10 18:21 ` Sebastian Gniazdowski
2019-09-10 19:38 ` Bart Schaefer
2019-09-12 0:08 ` Sebastian Gniazdowski [this message]
2019-09-12 1:03 ` Bart Schaefer
2019-09-12 2:06 ` Sebastian Gniazdowski
2019-09-12 5:35 ` Bart Schaefer
2019-09-12 6:00 ` Sebastian Gniazdowski
2019-09-12 6:55 ` Bart Schaefer
2019-09-13 20:28 ` Sebastian Gniazdowski
2019-09-13 21:33 ` Bart Schaefer
2019-09-13 21:36 ` Bart Schaefer
2019-09-14 0:41 ` Sebastian Gniazdowski
2019-09-14 0:44 ` Sebastian Gniazdowski
2023-05-03 14:46 Sebastian Gniazdowski
2023-07-04 1:55 ` Bart Schaefer
2023-07-04 18:53 ` Lawrence Velázquez
2023-07-05 5:32 ` Bart Schaefer
2023-07-05 6:30 ` Bart Schaefer
2023-07-06 1:39 ` Bart Schaefer
2023-07-06 2:27 ` Mikael Magnusson
2023-07-06 4:00 ` Bart Schaefer
2023-07-18 3:14 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKc7PVBoDMFNiQ8jW2uh9tw5axeLpj=MyPiYD_umpqeBsOi9zQ@mail.gmail.com' \
--to=sgniazdowski@gmail.com \
--cc=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).