Aliasing an array slice
Dan Brook
e.g
## correct syntax?
my @array = << a list of values >>;
my @array_slice := @array[ 1 .. @array.end ];
Or would this merely bind @array_slice to the list returned by the slice,
or would it DTRT (in my eyes at least) and bind it to that particular
slice of @array?
Dan Brook
Luke Palmer
> e.g
>
> ## correct syntax?
> my @array = << a list of values >>;
>
> my @array_slice := @array[ 1 .. @array.end ];
Yeah, that'll work. It has to, lest:
my *@fibs := (1, 1, map { $^a + $^b } zip(@fibs, @fibs[1...])) #[1]
Wouldn't work.
> Or would this merely bind @array_slice to the list returned by the slice,
> or would it DTRT (in my eyes at least) and bind it to that particular
> slice of @array?
>
> Dan Brook
[1] Oh don't look so scared :-)
Luke
Damian Conway
> Will it be possible (or sane even) to bind a variable to an array slice
It *should* be, since it's possible (if ungainly) to do it in Perl 5:
use Data::Dumper 'Dumper';
@bar = (1,2,3);
*foo = (sub {\@_})->(@bar[1,0,3]);
print Dumper \@foo;
$foo[0] = 9;
$foo[1] = 11;
$foo[2] = 13;
print Dumper \@bar;
Damian
dbr...@noc.easyspace.net
> > Will it be possible (or sane even) to bind a variable to an array slice
> It *should* be, since it's possible (if ungainly) to do it in Perl 5:
Ouch, blatant abuse of perl5's aliasing with @_ and globs ;) Can I also
assume that you can also pass around a 'reference' to an array slice e.g
sub array_slice(Array @ar, int $begin, int $end) {
## does the binding syntax := exist in unary form?
## or would this be better suited to bound at the lvalue end?
return \@ar[0][ $begin .. $end ];
}
my @array = << un deux trois quatre cinq six >>;
my @slice = array_slice( @array, 2, 4 );
@slice = << san shi go >>;
print @array;
__output__
un deux san shi go six
As opposed to an explicit binding assignment, or is this perhaps a step
too far (in which direction is left to the discretion of the reader)?
Dan Brook
Luke Palmer
>
> > > Will it be possible (or sane even) to bind a variable to an array slice
> > It *should* be, since it's possible (if ungainly) to do it in Perl 5:
>
> Ouch, blatant abuse of perl5's aliasing with @_ and globs ;) Can I also
> assume that you can also pass around a 'reference' to an array slice e.g
>
> sub array_slice(Array @ar, int $begin, int $end) {
> ## does the binding syntax := exist in unary form?
> ## or would this be better suited to bound at the lvalue end?
> return \@ar[0][ $begin .. $end ];
I fear that this might take a reference to each element in the slice,
rather than a reference to the slice....
Actually, you can't reference a slice! Where the heck does the
reference point? I would probably do:
my @ret := @ar[0][ $begin .. $end ];
return \@ret;
Which would likely use an extra level of indirection in its
implementation, but that's okay.
In any case, this is highly hypothetical, and these semantics should
be nailed down in the upcoming[1] Apocalypse.
Luke
[1] Term used lightly. :-)
Nicholas Clark
> Actually, you can't reference a slice! Where the heck does the
> reference point? I would probably do:
Of course not. I presume it points to something non-existent just like
a substring reference would in perl5 :-)
$ perl -le '$a = "pie contest"; $b = \substr $a, 1, 9; $$b = "arro"; print $a'
parrot
Nicholas Clark
Luke Palmer
I don't think you're supposed to do that:
% perl -le '$a = "foobar'; $b = \substr $a,2,3; $a .= "jibby"; $$b = "OBA"; print $a'
foobarjibby
Because it copies the buffer to resize, and $b points back into the old buffer...
But a slice can be used as an lvalue, so I guess it would be valid to
reference it (just like substr *should* be).
The tricky stuff comes in in cases like:
my @a = (1,2,3,4,5);
my $sref = \@a[1..3];
shift @a;
@$sref = (4,3,2);
@a # ? (4,3,2,5) or (2,4,3,2) ?
Those are just semantics to be nailed down, but it's tricky
nonetheless... oh and let's not forget multidimensional slices.
This really comes down to an issue that I've been biting my
fingernails about for some time: iterators. There are two mutually
exclusive kinds of iterator semantics: list and array. In the above
example, (4,3,2,5) would be list semantics; (2,4,3,2) would be array.
And both of them are correct (or wrong) in certain applications.
For implementation reasons, I'm not sure it's possible to have both
kinds of iterator pointing into the same kind of array. Perhaps we
need a List class for an array which doesn't support indexing... but
then it doesn't really deserve the @ medal does it?
Hmm...
Luke
> Nicholas Clark
Luke Palmer
> >
> > > Actually, you can't reference a slice! Where the heck does the
> > > reference point? I would probably do:
> >
> > Of course not. I presume it points to something non-existent just like
> > a substring reference would in perl5 :-)
> >
> > $ perl -le '$a = "pie contest"; $b = \substr $a, 1, 9; $$b = "arro"; print $a'
> > parrot
>
> I don't think you're supposed to do that:
>
> % perl -le '$a = "foobar'; $b = \substr $a,2,3; $a .= "jibby"; $$b = "OBA"; print $a'
> foobarjibby
>
> Because it copies the buffer to resize, and $b points back into the old buffer...
Forget I said that. I put $b = "OBA" in my command line instead of
$$b. It works.
Luke
Dan Brook
> > return \@ar[0][ $begin .. $end ];
>
> I fear that this might take a reference to each element in the slice,
> rather than a reference to the slice....
Yes, that would indeed return a list of refs in perl5. Can it also be
assumed that the magic hyper-operation of \() in perl5 will translated to
perl6, or (hopefully) will this behaviour become more explicit with
something like ^\() (is the carat still the hyper-operator character
btw?) ?
> Actually, you can't reference a slice! Where the heck does the
> reference point?
Maybe this is a poor simile since references aren't pointers, but I would
imagine if references to slices were to exist they'd be something *like*
a pointer to a specific index in an array in C e.g
#include <stdio.h>
int main(void) {
char *str = "a list of characters";
char *p = &str[2];
puts(p);
return 0;
}
__output__
list of characters
Of course this isn't directly orthogonal to a reference of an array slice
but hopefully it illustrates my point. Or perhaps this could all just be
simply implemented with a tie() or some other such magic. Just thinking
out loud here :)
Dan Brook
David Storrs
Thinking about it, I'd rather see lvalue slices become a nicer version
of C<splice()>.
my @start = (0..5);
my @a = @start;
@a[1..3] = qw/ a b c d e /;
print @a; # 0 a b c d e 4 5
# Similarly:
@a = @start;
my $r_slice = \@a[1..3];
@$r_slice = qw/ a b c d e /;
print @a; # 0 a b c d e 4 5
# Note that it does NOT modify in rvalue context
print reverse @$r_slice; # e d c b a
print @a; # 0 a b c d e 4 5
# To modify, do this:
@$r_slice = reverse @$r_slice;
print @a; # 0 e d c b a 4 5
As far as what happens when you modify the array to which the slice
points--treat it like any other reference. If you undef an array to
which you are holding a reference, the reference is suddenly reffing a
null array. If you undef an array slice to which you are holding a
reference, your slice ref is now reffing undef.
@a = @start;
$r_slice = \@a[0..3];
print @a; # 0 1 2 3 4 5
print @$r_slice; # 0 1 2 3
shift @a; # (*)
print @a; # 1 2 3 4 5
print @$r_slice; # 1 2 3
(*) There should probably be a suppressable warning emitted here,
something like:
"Warning: slice reference being modified" or
"Warning: slice reference such-and-such included this element; ref modified"
If slices DO get this functionality, it would be nice to add a method
whereby we could retrieve the min/max keys (for an array) or the set
of keys (for a hash) which they are currently reffing.
--Dks
Jonadab The Unsightly One
> my $r_slice = \@a[1..3];
> @$r_slice = qw/ a b c d e /;
> print @a; # 0 a b c d e 4 5
This seems right to me. It would take approximately no time to get
used to this semantic, IMO.
> # Note that it does NOT modify in rvalue context
[/me recoils at the very idea]
> @a = @start;
> $r_slice = \@a[0..3];
> print @a; # 0 1 2 3 4 5
> print @$r_slice; # 0 1 2 3
> shift @a; # (*)
> print @a; # 1 2 3 4 5
> print @$r_slice; # 1 2 3
Just to clarify: @$r_slice would point to specific elements of @a,
_not_ the the xth through the yth element, is that what you're saying
above? That is, although in the example above it initially pointed to
the first four elements, it after the pop points to the first three,
because one of the four is no longer in the array; it does _not_ now
point to the now-current first four elements.
Does this imply, though, that it's pointing to specific elements, and
if so doesn't that imply that elements can be inserted into the
original array in-between them...
print @a; # 0 1 2 3 4 5
print @$r_slice; # 0 1 2 3
splice @a, 2, 0, 6; # 0 1 6 2 3 4 5
After that, does @$r_slice contain (0,1,2,3) (the same elements of @a
as before), or does it contain (0,1,6,2,3) (the elements from the
first one it contained before to the last one it contained before)?
I can reason either way, but it needs to be nailed down, and there
might be good reasons (which I'm not thinking of just now) to do it
one way or the other.
> (*) There should probably be a suppressable warning emitted here,
I can go along with that.
Jonadab The Unsightly One
> Does this imply, though, that it's pointing to specific elements,
Wow, I wasn't paying attention to what I was thinking there.
Obviously it points to specific elements, because the subscripts used
to create a slice don't have to be sequential or even in order. I
(theoretically) knew that...
> print @a; # 0 1 2 3 4 5
> print @$r_slice; # 0 1 2 3
> splice @a, 2, 0, 6; # 0 1 6 2 3 4 5
print @$r_slice; # 0 1 2 3
splice @a, 1, 1, 7; # 0 7 6 2 3 4 5
print @$r_slice; # 0 7 2 3
Am I now thinking clearly?
Austin Hastings
If you've created two separate arrays that happen to start with related
values, then the changes to the first won't affect the second.
If splice overwrites the values instead of dropping and then replacing
them, it's going to produce some strange behavior.
I think that for example:
my @a is Array of int;
my $r_slice is Array of int;
# ... as before ...
should behave as expected, and "expected" in this case means
copy-on-assign. OTOH, if you said C<$r_slice := @a ...> then you'd be
binding, not copying, and the one-change-affects-both behavior is in
effect.
=Austin
David Storrs
>
> --- Jonadab the Unsightly One <jon...@bright.net> wrote:
> > Am I now thinking clearly?
> >
> I don't think so.
>
> If you've created two separate arrays that happen to start with related
> values, then the changes to the first won't affect the second.
>
> If splice overwrites the values instead of dropping and then replacing
> them, it's going to produce some strange behavior.
What kind of strange behavior? Can you give an example?
> I think that for example:
>
> my @a is Array of int;
> my $r_slice is Array of int;
>
> # ... as before ...
>
> should behave as expected, and "expected" in this case means
> copy-on-assign.
Could you elaborate on this?
>OTOH, if you said C<$r_slice := @a ...> then you'd be
> binding, not copying, and the one-change-affects-both behavior is in
> effect.
>
> =Austin
You also wouldn't be using a slice, you'd be using a reference to the
array. Or was the ellipsis supposed to indicate the slice indices?
--Dks
Austin Hastings
--- David Storrs <dst...@dstorrs.com> wrote:
> On Tue, Jul 08, 2003 at 05:52:04PM -0700, Austin Hastings wrote:
> >
> > --- Jonadab the Unsightly One <jon...@bright.net> wrote:
> > > Am I now thinking clearly?
> > >
> > I don't think so.
> >
> > If you've created two separate arrays that happen to start with
> related
> > values, then the changes to the first won't affect the second.
> >
> > If splice overwrites the values instead of dropping and then
> replacing
> > them, it's going to produce some strange behavior.
>
> What kind of strange behavior? Can you give an example?
Sure:
<perlfunc>
splice ...
Removes the elements designated by OFFSET and LENGTH from an array, and
replaces them with the elements of LIST, if any.
</perlfunc>
You have an array of Things. @a[0..2]
You use splice to replace 2 and add 2 more: @a.splice 1, 1, $x, $y, $z;
Now, what happened to @a[1] (the original one)?
According to "what I think I know about perl", it was removed from the
list.
Which means it may (or may not) be GCed at some point, but it's
potentially still a viable object.
OTOH, if splice is going to try to overwrite the values, then the
C<typeof $x> and C<$typeof @a[1]> should match, because there's going
to be a body-swap. And that means (for advanced types) that splice may
have to call the assignment operator, close filehandles, etc.
I don't think we want the second one.
>
> > I think that for example:
> >
> > my @a is Array of int;
> > my $r_slice is Array of int;
> >
> > # ... as before ...
> >
> > should behave as expected, and "expected" in this case means
> > copy-on-assign.
>
> Could you elaborate on this?
@r = @a[1,3,5];
I don't think there should be some kind of wierd magic tie. I think
that the assignment is done, and any subsequent change to @a should be
invisible to @r.
$r_slice = @a[1,3,5];
Ditto.
$r_slice = @a[potentially_infinite_iterator()];
Now what? Especially since @a could potentially be a (potentially
infinite) tied thing? To me, the right behavior is to copy the values
of @a on assignment. To be more specific:
my @a is Array of Num value { $^a * 2 };
my $r_slice = @a[1 .. { 2 * $^a + 1 }];
So $r_slice should return the odd members of @a, which itself contains
Num.Inf even numbers.
So what then happens if I say @a.shift?
Should $r_slice be late-bound, and suddenly one of it's members doesn't
appear? I think this is "trouble waiting to happen", since when we get
to mixed literal/generator slices (e.g., ... =
@a[1,3,11,22,generator()]) the implementation will be forced to copy
the literal part.
Instead, I think that $r_slice should get a new "composed" generator
function (a "copy" of @a's values, filtered through the "slice id") so
that subsequent shift/unshift/splice operations on @a don't affect it.
> >OTOH, if you said C<$r_slice := @a ...> then you'd be
> > binding, not copying, and the one-change-affects-both behavior is
> in
> > effect.
> >
> > =Austin
>
> You also wouldn't be using a slice, you'd be using a reference to the
> array. Or was the ellipsis supposed to indicate the slice indices?
Yeah, it was supposed to mean "all that stuff he typed above".
Essentially, what I'm getting at is that = vs. := is still meaningful
in slice context (where possible).
=Austin
Benjamin Goldberg
David Storrs wrote:
>
> Thinking about it, I'd rather see lvalue slices become a nicer version
> of C<splice()>.
>
> my @start = (0..5);
> my @a = @start;
>
> @a[1..3] = qw/ a b c d e /;
> print @a; # 0 a b c d e 4 5
What would happen if I used 1,2,3 instead of 1..3? Would it do the same
thing? I wanna know what happens if I do:
@a[0,2,4] = qw/ a b c d e /;
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Luke Palmer
> >
> > Thinking about it, I'd rather see lvalue slices become a nicer version
> > of C<splice()>.
> >
> > my @start = (0..5);
> > my @a = @start;
> >
> > @a[1..3] = qw/ a b c d e /;
> > print @a; # 0 a b c d e 4 5
>
> What would happen if I used 1,2,3 instead of 1..3? Would it do the same
> thing?
Of course.
> I wanna know what happens if I do:
>
> @a[0,2,4] = qw/ a b c d e /;
It would probably do the same as in Perl 5; the same thing as:
@a[0,2,4] = << a b c >>;
(those << >> brackets are new shorthand for qw, not that qw is going
anywhere)
Luke
Benjamin Goldberg
Luke Palmer wrote:
>
> > David Storrs wrote:
> > >
> > > Thinking about it, I'd rather see lvalue slices become a nicer version
> > > of C<splice()>.
> > >
> > > my @start = (0..5);
> > > my @a = @start;
> > >
> > > @a[1..3] = qw/ a b c d e /;
> > > print @a; # 0 a b c d e 4 5
> >
> > What would happen if I used 1,2,3 instead of 1..3? Would it do the
> > same thing?
>
> Of course.
>
> > I wanna know what happens if I do:
> >
> > @a[0,2,4] = qw/ a b c d e /;
>
> It would probably do the same as in Perl 5; the same thing as:
>
> @a[0,2,4] = << a b c >>;
>
> (those << >> brackets are new shorthand for qw, not that qw is going
> anywhere)
Hmm... so, if I were to do:
@x = map int(rand(6)), 1..3;
@a[@x] = "a" .. "e";
print @a.length;
Then, if the three integers in @x are consecutive, @a grows, but
otherwise it doesn't?
Dave Whipp
> Benjamin Goldberg wrote:
> > David Storrs wrote:
> > > @a[1..3] = qw/ a b c d e /;
> > > print @a; # 0 a b c d e 4 5
> >
> > What would happen if I used 1,2,3 instead of 1..3? Would it do the same
> > thing?
>
> Of course.
I tend to agree, I think. But see below
> > I wanna know what happens if I do:
> >
> > @a[0,2,4] = qw/ a b c d e /;
>
> It would probably do the same as in Perl 5; the same thing as:
>
> @a[0,2,4] = << a b c >>;
But that would be awful:
@a[$x,$y] = <<a b c d e>>
would insert all 5 elements if ($y == $x+1); but only the first two
otherwise. Belch.
If we wanted the array-splice thing to resize arrays for us, then either we
trigger the behavior only when rx/ \[ <scalar> \.\. <scalar> \]/, or we need
to define the spilling algorithm in a way that makes sense (e.g. all
remaining items go into the element of the righmost index).
But perhaps there's a better way to beet the desire. Perhaps ellipses could
be emplyed to indicate that the splice is allowed to resize the array:
@a[1...3] = qw(a b c d e);
Dave.
Benjamin Goldberg
> "Luke Palmer" wrote:
> > Benjamin Goldberg wrote:
> > > David Storrs wrote:
> > > > @a[1..3] = qw/ a b c d e /;
> > > > print @a; # 0 a b c d e 4 5
> > >
> > > What would happen if I used 1,2,3 instead of 1..3?
> > > Would it do the same thing?
> >
> > Of course.
>
> I tend to agree, I think. But see below
>
> > > I wanna know what happens if I do:
> > >
> > > @a[0,2,4] = qw/ a b c d e /;
> >
> > It would probably do the same as in Perl 5; the same thing as:
> >
> > @a[0,2,4] = << a b c >>;
>
> But that would be awful:
>
> @a[$x,$y] = <<a b c d e>>
>
> would insert all 5 elements if ($y == $x+1); but only the first two
> otherwise. Belch.
>
> If we wanted the array-splice thing to resize arrays for us, then either
> we trigger the behavior only when rx/ \[ <scalar> \.\. <scalar> \]/, or
AFAIK, in perl6, $a..$b doesn't create an expanded list... it creates a
lazy list, which gets expanded as-needed. Most likely, this list
object, and the list object representing the values being stored there,
would be handed directly to the @a array object, just as if we'd done
code like:
@a[ new LazyIntRange(1,3) ] = new LazyStrRange("a","e");
So, @a can say, "hey, this is a Range, not merely a list of 1,2,3... I
should instead splice() the values in"
> we need to define the spilling algorithm in a way that makes sense (e.g.
> all remaining items go into the element of the righmost index).
>
> But perhaps there's a better way to beet the desire. Perhaps ellipses
> could be emplyed to indicate that the splice is allowed to resize the
> array:
>
> @a[1...3] = qw(a b c d e);
That might work, too.
My way is more invisible, but then again, if someone *wants* to have
@a[1,2,3,4,5,6,7,8,9] = @x, and writes it as @a[1..9] = @x, and is
surprised by perl doing a splice, it would be bad; with "..." it would
only splice when the user asks for a splice.
Luke Palmer
> Luke Palmer wrote:
> >
> > > David Storrs wrote:
> > > >
> > > > Thinking about it, I'd rather see lvalue slices become a nicer version
> > > > of C<splice()>.
> > > >
> > > > my @start = (0..5);
> > > > my @a = @start;
> > > >
> > > > @a[1..3] = qw/ a b c d e /;
> > > > print @a; # 0 a b c d e 4 5
> > >
> > > What would happen if I used 1,2,3 instead of 1..3? Would it do the
> > > same thing?
> >
> > Of course.
> >
> > > I wanna know what happens if I do:
> > >
> > > @a[0,2,4] = qw/ a b c d e /;
> >
> > It would probably do the same as in Perl 5; the same thing as:
> >
> > @a[0,2,4] = << a b c >>;
> >
> > (those << >> brackets are new shorthand for qw, not that qw is going
> > anywhere)
>
> Hmm... so, if I were to do:
>
> @x = map int(rand(6)), 1..3;
> @a[@x] = "a" .. "e";
> print @a.length;
>
> Then, if the three integers in @x are consecutive, @a grows, but
> otherwise it doesn't?
You know what would be nice? If I actually read what we were talking
about (which can be seen at the top of this message %-).
In general, (partially) because of this, I don't think slice splicing
is a good idea; that's what the C<splice> function is for. The idea
of lexical expansion is good, and slice splicing kills that. For
example:
@a[1..3] = << a b c d e >>
Can be expanded in people's heads to:
(@a[1], @a[2], @a[3]) = << a b c d e >>
And I don't think that's something we want to get rid of.
Luke
David Storrs
> What would happen if I used 1,2,3 instead of 1..3? Would it do the same
> thing?
I would think so.
> I wanna know what happens if I do:
>
> @a[0,2,4] = qw/ a b c d e /;
Yup, you're right, I didn't consider non-contiguous ranges in my
original proposal. Stupid of me.
After considering it more thoroughly, I guess this isn't a good idea.
Here are some of the cases that it would need to cover (obviously,
punting on some of these is an option).
Single finite contiguous list (1,2,3)
Single finite noncontiguous list with pattern (2,4,6)
Single finite noncontiguous list without pattern (2,4,6,13)
Single finite contiguous range (1..3)
Single finite noncontiguous range(1..10 :by 2)
Multiple finite contiguous lists
- that resolve to a contiguous list ((1,2,3),(4,5,6))
- that do not resolve to a contiguous list ((1,2,3),(7,8,9))
Multiple finite noncontiguous lists with pattern ((2,4,6),(9,12,15))
- that resolve to a contiguous list if reordered
((2,4,6),(1,2,3))
# reordering is almost certainly a bad idea
Multiple finite noncontiguous lists without pattern ((2,4,6,13), (77,100,203))
Multiple finite contiguous ranges ((1..3),(7..9))
Multiple finite noncontiguous ranges ((1..10 :by 2), (20..50 :by 7))
Infinite ranges (1..Inf) or (7..Inf :by 8)
Mixed cases
- ((2,4,6),(99..200))
- ((2,4,6),(20..50 :by7))
Overlapping cases
- ( (1,2,3,4), (3,4,5,6) )
It's a shame, because I think it would make a really nice convenience
feature. I will say that I like the solution proposed earlier (sorry,
I forget by whom) that the C<...> in 5...10 would mean "this is a
splice slice".
Btw, I don't remember what the syntax for "range, step by N" was, so
my version probably isn't right.
--Dks