* Re: array prepend [not found] ` <20130113185141.4394d532@pws-pc.ntlworld.com> @ 2013-01-14 1:50 ` Bart Schaefer 2013-01-14 15:48 ` Oliver Kiddle 2013-01-14 18:36 ` Greg Klanderman 0 siblings, 2 replies; 10+ messages in thread From: Bart Schaefer @ 2013-01-14 1:50 UTC (permalink / raw) To: zsh-workers [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 <okiddle@yahoo.co.uk> 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[]+=') ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: array prepend 2013-01-14 1:50 ` array prepend Bart Schaefer @ 2013-01-14 15:48 ` Oliver Kiddle 2013-01-17 5:02 ` Bart Schaefer 2013-01-14 18:36 ` Greg Klanderman 1 sibling, 1 reply; 10+ messages in thread From: Oliver Kiddle @ 2013-01-14 15:48 UTC (permalink / raw) To: zsh-workers Bart wrote: > Hrm, I'm not exactly excited by that choice, /= implies some sort of > division rather than union. I was thinking of ^= (given the meaning of ^ in a regex) but that also implies a mathematical operation. Also note that the current += does do addition given integer variables much as i=foo is also sensitive to an existing integer i variable. > 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 /=. You're right, with -= it looks for a matching command name. Digging back in the mail archives it seems I've remembered the reasons wrongly. > 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[]+=') That seems reasonably logical. Would the following be possible to prepend to an array element? VAR[1][]="first" Oliver ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: array prepend 2013-01-14 15:48 ` Oliver Kiddle @ 2013-01-17 5:02 ` Bart Schaefer 0 siblings, 0 replies; 10+ messages in thread From: Bart Schaefer @ 2013-01-17 5:02 UTC (permalink / raw) To: zsh-workers On Jan 14, 4:48pm, Oliver Kiddle wrote: } } > VAR[]=(this is prepended) } > VAR[]+=(this is appended) } > VAR+=(short for 'VAR[]+=') } } That seems reasonably logical. Would the following be possible to prepend } to an array element? } VAR[1][]="first" If we were also to define var[] for scalars to allow prepend, then yes. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: array prepend 2013-01-14 1:50 ` array prepend Bart Schaefer 2013-01-14 15:48 ` Oliver Kiddle @ 2013-01-14 18:36 ` Greg Klanderman 2013-01-17 5:00 ` Bart Schaefer 1 sibling, 1 reply; 10+ messages in thread From: Greg Klanderman @ 2013-01-14 18:36 UTC (permalink / raw) To: zsh-workers >>>>> On January 13, 2013 Bart Schaefer <schaefer@brasslantern.com> wrote: > 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) So that's the same as VAR[1,0]=(...) ? It doesn't really "look" very much like prepend to me. > VAR[]+=(this is appended) > VAR+=(short for 'VAR[]+=') Does VAR+=($x) differ at all from VAR+=$x if VAR is an array? I was thinking of maybe '++=' for prepend, the double '+' weighting towards the front. Greg ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: array prepend 2013-01-14 18:36 ` Greg Klanderman @ 2013-01-17 5:00 ` Bart Schaefer 2013-01-17 14:52 ` Greg Klanderman 0 siblings, 1 reply; 10+ messages in thread From: Bart Schaefer @ 2013-01-17 5:00 UTC (permalink / raw) To: zsh-workers On Jan 14, 1:36pm, Greg Klanderman wrote: } Subject: Re: array prepend } } > VAR[]=(this is prepended) } } So that's the same as VAR[1,0]=(...) ? Well, no, because VAR[] would work regardless of KSH_ARRAYS. But I confess I'd forgotten about reversing the indices like that. For those in the audience, Greg has just reminded me that you can in fact "splice to the left" by using indices in decreasing order; and for zsh-mode arrays there is an empty slot at zero, which you can't reference by itself, but which is allowed in a range expression. So in those circumstances VAR[1,0]=(this is prepended) } It doesn't really "look" very much like prepend to me. I chose it to "look like" splicing something into an "empty" index. If we pretend there's an empty index at each end of the array, ... } > VAR[]+=(this is appended) } > VAR+=(short for 'VAR[]+=') } } Does VAR+=($x) differ at all from VAR+=$x if VAR is an array? Only when $x substitutes more than one word. } I was thinking of maybe '++=' for prepend, the double '+' weighting } towards the front. That would be OK as well. However, it occurs to me that we could allow VAR[] to work for associative arrays; a special case in which you *are* permitted to set a so-called slice, because there's nothing to replace and no order required. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: array prepend 2013-01-17 5:00 ` Bart Schaefer @ 2013-01-17 14:52 ` Greg Klanderman 2013-01-17 15:49 ` Bart Schaefer 2013-01-19 7:53 ` Han Pingtian 0 siblings, 2 replies; 10+ messages in thread From: Greg Klanderman @ 2013-01-17 14:52 UTC (permalink / raw) To: zsh-workers >>>>> On January 17, 2013 Bart Schaefer <schaefer@brasslantern.com> wrote: > } So that's the same as VAR[1,0]=(...) ? > Well, no, because VAR[] would work regardless of KSH_ARRAYS. But I > confess I'd forgotten about reversing the indices like that. right, though pretty much any script using arrays is going to break if you flip KSH_ARRAYS.. :-) > } It doesn't really "look" very much like prepend to me. > I chose it to "look like" splicing something into an "empty" index. > If we pretend there's an empty index at each end of the array, ... yeah, I like the '[]' to indicate splicing into an "empty" index, I was thinking VAR[]= vs VAR[]+= don't really clues me in to which is prepend vs append. But thinking about it more, I guess since += already means append, you chose to keep that meaning, so it does make sense to me now. > } Does VAR+=($x) differ at all from VAR+=$x if VAR is an array? > Only when $x substitutes more than one word. Ahh OK, I see when SHWORDSPLIT is on, VAR+=$x does not perform splitting on $x but VAR+=($x) does. > } I was thinking of maybe '++=' for prepend, the double '+' weighting > } towards the front. > That would be OK as well. However, it occurs to me that we could allow > VAR[] to work for associative arrays; a special case in which you *are* > permitted to set a so-called slice, because there's nothing to replace > and no order required. You lost me there.. you can already use += on associative arrays AFAICT, what does [] give you? How do prepend and append differ, just the precedence when one a new key already has a value in the associative array? Greg ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: array prepend 2013-01-17 14:52 ` Greg Klanderman @ 2013-01-17 15:49 ` Bart Schaefer 2013-01-19 7:53 ` Han Pingtian 1 sibling, 0 replies; 10+ messages in thread From: Bart Schaefer @ 2013-01-17 15:49 UTC (permalink / raw) To: zsh-workers On Jan 17, 9:52am, Greg Klanderman wrote: } } Ahh OK, I see when SHWORDSPLIT is on, VAR+=$x does not perform } splitting on $x but VAR+=($x) does. Also when $x is an array, VAR+=$x does joining ... } you can already use += on associative arrays Caught me on another detail I'd forgotten. So I guess I have no real preference for []+= or ++= as a syntax. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: array prepend 2013-01-17 14:52 ` Greg Klanderman 2013-01-17 15:49 ` Bart Schaefer @ 2013-01-19 7:53 ` Han Pingtian 2013-01-19 16:41 ` Bart Schaefer 1 sibling, 1 reply; 10+ messages in thread From: Han Pingtian @ 2013-01-19 7:53 UTC (permalink / raw) To: zsh-workers On Thu, Jan 17, 2013 at 09:52:01AM -0500, Greg Klanderman wrote: > Ahh OK, I see when SHWORDSPLIT is on, VAR+=$x does not perform > splitting on $x but VAR+=($x) does. > Looks like when SHWORDSPLIT is on, both VAR+=$x and VAR+=($x) will perform splitting on $x: localhost% setopt shwordsplit localhost% setopt interactive monitor norcs shinstdin shwordsplit zle localhost% array=(foo bar);v="xxx yyy";array+=$v;print -l $array foo bar xxx yyy localhost% array=(foo bar);v="xxx yyy";array+=($v);print -l $array foo bar xxx yyy localhost% ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: array prepend 2013-01-19 7:53 ` Han Pingtian @ 2013-01-19 16:41 ` Bart Schaefer 2013-01-20 11:08 ` Han Pingtian 0 siblings, 1 reply; 10+ messages in thread From: Bart Schaefer @ 2013-01-19 16:41 UTC (permalink / raw) To: zsh-workers On Jan 19, 3:53pm, Han Pingtian wrote: } } Looks like when SHWORDSPLIT is on, both VAR+=$x and VAR+=($x) will } perform splitting on $x: You're forgetting that when SHWORDSPLIT is on, $array will perform splitting on $array. torch% setopt shwordsplit torch% array=(foo bar);v="xxx yyy";array+=$v;print -l "${array[@]}" foo bar xxx yyy ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: array prepend 2013-01-19 16:41 ` Bart Schaefer @ 2013-01-20 11:08 ` Han Pingtian 0 siblings, 0 replies; 10+ messages in thread From: Han Pingtian @ 2013-01-20 11:08 UTC (permalink / raw) To: zsh-workers On Sat, Jan 19, 2013 at 08:41:37AM -0800, Bart Schaefer wrote: > On Jan 19, 3:53pm, Han Pingtian wrote: > } > } Looks like when SHWORDSPLIT is on, both VAR+=$x and VAR+=($x) will > } perform splitting on $x: > > You're forgetting that when SHWORDSPLIT is on, $array will perform > splitting on $array. > > torch% setopt shwordsplit > torch% array=(foo bar);v="xxx yyy";array+=$v;print -l "${array[@]}" > foo > bar > xxx yyy Thank you, Bart. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-01-20 11:19 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <50EFB80D.30002@sergio.spb.ru> [not found] ` <22417.1357954693@thecus.kiddle.eu> [not found] ` <20130113185141.4394d532@pws-pc.ntlworld.com> 2013-01-14 1:50 ` array prepend Bart Schaefer 2013-01-14 15:48 ` Oliver Kiddle 2013-01-17 5:02 ` Bart Schaefer 2013-01-14 18:36 ` Greg Klanderman 2013-01-17 5:00 ` Bart Schaefer 2013-01-17 14:52 ` Greg Klanderman 2013-01-17 15:49 ` Bart Schaefer 2013-01-19 7:53 ` Han Pingtian 2013-01-19 16:41 ` Bart Schaefer 2013-01-20 11:08 ` Han Pingtian
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).