From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id a9953649 for ; Tue, 10 Sep 2019 18:22:26 +0000 (UTC) Received: (qmail 9061 invoked by alias); 10 Sep 2019 18:22:17 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44748 Received: (qmail 6731 invoked by uid 1010); 10 Sep 2019 18:22:17 -0000 X-Qmail-Scanner-Diagnostics: from mail-ua1-f67.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25566. spamassassin: 3.4.2. Clear:RC:0(209.85.222.67):SA:0(-2.0/5.0):. Processed in 2.561993 secs); 10 Sep 2019 18:22:17 -0000 X-Envelope-From: sgniazdowski@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.222.67 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vw7AwzazZlcGRtGvDqu+Sq0TX9sk6iYG3UNthPiTl2U=; b=Ox0MSrek1jXP/2+8Ws5MugzigUnwu2lGJpDqy7OuJr9OzTYKB/MrJGDkZpq3m+oZiZ sqsCtS1/QEBM6ZvHvvo4wO5VvYRud1zzEgyyFN4eFIl1PojavC0gVruvr67WXRxeyl4l obeMFRY114bJ8A9aj2+SwJp6TqGxmkBWmXN6cccS/VNbGQNHdxDWMMguSmf9hANWr6/L Uq1HvVK+LbWB+vijihwz8Ke8W1FNPWaBoLBoGo148nzulBzcMvG4ExUoXWgh5OHt2PEk Q5xrKFX69O++0PSbeMYNYc7xD+KmsDDUCX3/AjkIMTPkPhSKoUBKGTq3l8WX4TCKxPLf 402w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vw7AwzazZlcGRtGvDqu+Sq0TX9sk6iYG3UNthPiTl2U=; b=oTGA9c9w6JjVRBBN5fm8hsQqxBuArTwYGO/A1MlIJbihwv+BXEnXqcUYfkK4vBF/mt v181sOjUrAFOpdih6qjFUqYalLQCdZUrIarmMt33Rr9ANpzJPAce7f1ltUILkAT13KL3 o3XuJsWXNagxP0w5/W9lzhnUn5eRDZGE8QDr+GdoLlzt+e4EvSwibfHDkozxhkHlnlDx TxgmI6N7355vZ8e4k/PqGPM8sXkUH0bGlOQtoKQJqXo2mr4FmMRZKqtdvOsacShreoEX DLqnUbsgVsJ5wxObRZUZIdBsjPl3o3IbyQXMmCnr4M42IEQ6DaM2yVMBM8a8ZE86Zxry QDTQ== X-Gm-Message-State: APjAAAVvX3RcjNL0p6YhaPDir3527zBmRhXUGGcpSLcMx7jq6SVFu9dP yYQEpibpXxzytr3l6YdXRDlX3ali1GgZ/SgwUMw= X-Google-Smtp-Source: APXvYqwYpZ1RKS1/lcPThWGxjyBQ59fj5FevJi5rykFp29sSB10DEVGoYchJFp93cLjOeQKUwsue6V5Y9TN1ZXniUCw= X-Received: by 2002:ab0:602b:: with SMTP id n11mr14239394ual.28.1568139700713; Tue, 10 Sep 2019 11:21:40 -0700 (PDT) MIME-Version: 1.0 References: <20190907150741.jwztdoslrvk5j7nk@chaz.gmail.com> <20190907201954.dn2nve65wqk4muvc@chaz.gmail.com> In-Reply-To: From: Sebastian Gniazdowski Date: Tue, 10 Sep 2019 20:21:01 +0200 Message-ID: Subject: Re: [PATCH] Support the mksh's ${|func;} substitution To: Bart Schaefer Cc: Zsh hackers list Content-Type: text/plain; charset="UTF-8" On Tue, 10 Sep 2019 at 07:29, Bart Schaefer wrote: > > On Mon, Sep 9, 2019 at 7:21 PM Sebastian Gniazdowski > 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