From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10845 invoked by alias); 14 Jan 2013 01:50:43 -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: X-Seq: 30962 Received: (qmail 4388 invoked from network); 14 Jan 2013 01:50:41 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <130113175023.ZM5855@torch.brasslantern.com> Date: Sun, 13 Jan 2013 17:50:23 -0800 In-reply-to: <20130113185141.4394d532@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: array prepend" (Jan 13, 6:51pm) References: <50EFB80D.30002@sergio.spb.ru> <22417.1357954693@thecus.kiddle.eu> <20130113185141.4394d532@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: array prepend MIME-version: 1.0 Content-type: text/plain; charset=us-ascii [redirected to -workers] On Jan 13, 6:51pm, Peter Stephenson wrote: } Subject: Re: array prepend } } On Sat, 12 Jan 2013 02:38:13 +0100 } Oliver Kiddle wrote: } > If you dig out the mailing list discussion from when += was added } > you'll see that the main reason there isn't a prepend is that we } > couldn't think of suitable syntax that would be backward compatible. } } I was thinking about /=. I started looking at it once but got bored } with all the varieties of parameter type. Hrm, I'm not exactly excited by that choice, /= implies some sort of division rather than union. } > -= for example } > isn't possible because a - character is valid in an identifier. Thinking again, I'm not sure that's the reason. There doesn't seem to be any syntactic reason to exclude -= (it doesn't parse now); rather, =+ doesn't work because a + character is valid in the parameter value, but I think -= was rejected on the same implied-semantics grounds that I just raised for /=. What about a special case for empty brackets? VAR[] is not currently a valid identifier even though e.g. VAR[*] is. VAR[]=(this is prepended) VAR[]+=(this is appended) VAR+=(short for 'VAR[]+=')