Re: array prepend

Re: array prepend

[Bart Schaefer]

[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[]+=')

Re: array prepend

[Oliver Kiddle]

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

Re: array prepend

[Greg Klanderman]

>>>>> 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

Re: array prepend

[Bart Schaefer]

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.

Re: array prepend

[Bart Schaefer]

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.

Re: array prepend

[Greg Klanderman]

>>>>> 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

Re: array prepend

[Bart Schaefer]

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.

Re: array prepend

[Han Pingtian]

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%

Re: array prepend

[Bart Schaefer]

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

Re: array prepend

[Han Pingtian]

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.