Skip Menu |

Subject: List slice *sometimes* ignores undefined items
Date: Sun, 19 Aug 2012 08:26:48 -0700 (PDT)
To: "perlbug [...] perl.org" <perlbug [...] perl.org>
From: John Wiersba <jrw32982 [...] yahoo.com>
Download (untitled) / with headers
text/plain 392b
@x = ( (2)[0,1,2] ); @y = ( (2)[  1,2] ); use Data::Dumper; print Dumper \@x, \@y; produces: $VAR1 = [           2,           undef,           undef         ]; $VAR2 = []; This seems inconsistent.  The first result (for @x) was expected. The second (for @y) wasn't. I have tested this on linux ActivePerl from 5.8 through 5.16 with identical results.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 997b
On Sun Aug 19 08:27:12 2012, jrw32982@yahoo.com wrote: Show quoted text
> @x = ( (2)[0,1,2] ); > @y = ( (2)[� 1,2] ); > use Data::Dumper; > print Dumper \@x, \@y; > > produces: > > $VAR1 = [ > ��������� 2, > ��������� undef, > ��������� undef > ������� ]; > $VAR2 = []; > > This seems inconsistent.� The first result (for @x) was expected. The > second (for @y) wasn't. >
I don't think it's particularly inconsistent. In the first case the slicing operation finds a defined element in the 0-index position of the RH and assigns it to the array on the LH, and then (I suppose) proceeds to auto-vivify. In the second case, the slicing operation finds no element in the 0-index position, has nothing to assign, and stops there. If anything, I think the second case is more intuitively plausible than the first. I couldn't find anything in Camel book 3rd or 4th edition that clarifies this definitively. Thank you very much. Jim Keenan
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 586b
On Sun Aug 19 08:27:12 2012, jrw32982@yahoo.com wrote: Show quoted text
> @x = ( (2)[0,1,2] ); > @y = ( (2)[� 1,2] ); > use Data::Dumper; > print Dumper \@x, \@y; > > produces: > > $VAR1 = [ > ��������� 2, > ��������� undef, > ��������� undef > ������� ]; > $VAR2 = []; > > This seems inconsistent.� The first result (for @x) was expected. The > second (for @y) wasn't.
I have often relied on the fact that list slices return nothing for nonexistent elements. But I have usually used a single index. -- Father Chrysostomos
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Fri, 31 Aug 2012 00:49:40 +0200
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 327b
* James E Keenan via RT <perlbug-followup@perl.org> [2012-08-21 03:55]: Show quoted text
> I don't think it's particularly inconsistent.
It is completely inconsistent with the way slices work in every other case I can think of, and very surprising. This is a bug that should be fixed. It has the distinct smell of an implementation accident.
CC: perl5-porters [...] perl.org
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Thu, 30 Aug 2012 19:02:31 -0400
To: perlbug-followup [...] perl.org
From: Eric Brine <ikegami [...] adaelis.com>
Download (untitled) / with headers
text/plain 272b
On Tue, Aug 21, 2012 at 3:26 AM, Father Chrysostomos via RT <perlbug-followup@perl.org> wrote:
Show quoted text
I have often relied on the fact that list slices return nothing for
nonexistent elements.

Except they don't. Sometimes they return nothing, sometimes they return undef.

Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Fri, 31 Aug 2012 00:06:20 -0400
To: perl5-porters [...] perl.org
From: Rick Delaney <rick [...] bort.ca>
Download (untitled) / with headers
text/plain 1024b
On Aug 31 2012, Aristotle Pagaltzis wrote: Show quoted text
> * James E Keenan via RT <perlbug-followup@perl.org> [2012-08-21 03:55]:
> > I don't think it's particularly inconsistent.
> > It is completely inconsistent with the way slices work in every other > case I can think of, and very surprising. This is a bug that should be > fixed. It has the distinct smell of an implementation accident.
It is no accident. From perldata: A slice of an empty list is still an empty list. Thus: @a = ()[1,0]; # @a has no elements @b = (@a)[0,1]; # @b has no elements @c = (0,1)[2,3]; # @c has no elements But: @a = (1)[1,0]; # @a has two elements @b = (1,undef)[1,0,2]; # @b has three elements This makes it easy to write loops that terminate when a null list is returned: while ( ($home, $user) = (getpwent)[7,0]) { printf "%-8s %s\n", $user, $home; } -- Rick Delaney rick@bort.ca
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Fri, 31 Aug 2012 06:51:33 +0200
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 1.2k
* Rick Delaney <rick@bort.ca> [2012-08-31 06:10]: Show quoted text
> On Aug 31 2012, Aristotle Pagaltzis wrote:
> > * James E Keenan via RT <perlbug-followup@perl.org> [2012-08-21 03:55]:
> > > I don't think it's particularly inconsistent.
> > > > It is completely inconsistent with the way slices work in every other > > case I can think of, and very surprising. This is a bug that should be > > fixed. It has the distinct smell of an implementation accident.
> > It is no accident. From perldata:
I do not think your quotation says about this what you think it says. Show quoted text
> A slice of an empty list is still an empty list. Thus: > > @a = ()[1,0]; # @a has no elements > @b = (@a)[0,1]; # @b has no elements > @c = (0,1)[2,3]; # @c has no elements > > But: > > @a = (1)[1,0]; # @a has two elements > @b = (1,undef)[1,0,2]; # @b has three elements
The bug report was about the surprising difference between these: @x = ( (2)[0,1,2] ); @y = ( (2)[ 1,2] ); In both cases the slice is of a one-element list, not of an empty list, so the “But” clause from the quoted documentation applies and neither array should be empty. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Fri, 31 Aug 2012 01:11:32 -0400
To: perl5-porters [...] perl.org
From: Eric Brine <ikegami [...] adaelis.com>
Download (untitled) / with headers
text/plain 1.4k


On Fri, Aug 31, 2012 at 12:51 AM, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:
Show quoted text
* Rick Delaney <rick@bort.ca> [2012-08-31 06:10]:
> On Aug 31 2012, Aristotle Pagaltzis wrote:
> > * James E Keenan via RT <perlbug-followup@perl.org> [2012-08-21 03:55]:
> > > I don't think it's particularly inconsistent.
> >
> > It is completely inconsistent with the way slices work in every other
> > case I can think of, and very surprising. This is a bug that should be
> > fixed. It has the distinct smell of an implementation accident.
>
> It is no accident. From perldata:

I do not think your quotation says about this what you think it says.

>        A slice of an empty list is still an empty list.  Thus:
>
>            @a = ()[1,0];           # @a has no elements
>            @b = (@a)[0,1];         # @b has no elements
>            @c = (0,1)[2,3];        # @c has no elements
>
>        But:
>
>            @a = (1)[1,0];          # @a has two elements
>            @b = (1,undef)[1,0,2];  # @b has three elements

The bug report was about the surprising difference between these:

    @x = ( (2)[0,1,2] );
    @y = ( (2)[  1,2] );

In both cases the slice is of a one-element list, not of an empty list,
so the “But” clause from the quoted documentation applies and neither
array should be empty.

Actually, it is covered:

@c = (0,1)[2,3];        # @c has no elements

Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Fri, 31 Aug 2012 01:20:12 -0400
To: perl5-porters [...] perl.org
From: Uri Guttman <uri [...] stemsystems.com>
Download (untitled) / with headers
text/plain 1.8k
On 08/31/2012 12:51 AM, Aristotle Pagaltzis wrote: Show quoted text
> * Rick Delaney <rick@bort.ca> [2012-08-31 06:10]:
>> On Aug 31 2012, Aristotle Pagaltzis wrote:
>>> * James E Keenan via RT <perlbug-followup@perl.org> [2012-08-21 03:55]:
>>>> I don't think it's particularly inconsistent.
>>> >>> It is completely inconsistent with the way slices work in every other >>> case I can think of, and very surprising. This is a bug that should be >>> fixed. It has the distinct smell of an implementation accident.
>> >> It is no accident. From perldata:
> > I do not think your quotation says about this what you think it says. >
>> A slice of an empty list is still an empty list. Thus: >> >> @a = ()[1,0]; # @a has no elements >> @b = (@a)[0,1]; # @b has no elements >> @c = (0,1)[2,3]; # @c has no elements >> >> But: >> >> @a = (1)[1,0]; # @a has two elements >> @b = (1,undef)[1,0,2]; # @b has three elements
> > The bug report was about the surprising difference between these: > > @x = ( (2)[0,1,2] ); > @y = ( (2)[ 1,2] ); > > In both cases the slice is of a one-element list, not of an empty list, > so the “But” clause from the quoted documentation applies and neither > array should be empty.
look at the @c example which is the same as your @y line. slicing only above the last element is an empty list. if any value from the slice is from an existing element, the whole slice has elements. been that way forever from what i know to support that an empty list (even assigned to a list of scalars) is false. i was thinking about this feature to add to this thread but couldn't find the doc quote for it. my view is the docs could use a little more clarity saying that a slice of only indexes beyond the last one is always an empty list. uri
CC: perl5-porters [...] perl.org
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Fri, 31 Aug 2012 07:57:06 +0200
To: Uri Guttman <uri [...] stemsystems.com>
From: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>
Download (untitled) / with headers
text/plain 410b
On Fri, Aug 31, 2012 at 7:20 AM, Uri Guttman <uri@stemsystems.com> wrote:
Show quoted text
my view is the docs could use a little more clarity saying that a slice of only indexes beyond the last one is always an empty list.

  ... or just explain why C<< (0,1)[2,3] >> is an example of "a slice of an empty list".  To me it looks like a slice of C<< (0, 1) >>, which in turn does not look particularly empty ...


Eirik
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Fri, 31 Aug 2012 15:08:45 +0200
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 719b
* Eric Brine <ikegami@adaelis.com> [2012-08-31 07:15]: Show quoted text
> On Fri, Aug 31, 2012 at 12:51 AM, Aristotle Pagaltzis <pagaltzis@gmx.de>wrote:
> > In both cases the slice is of a one-element list, not of an empty > > list, so the “But” clause from the quoted documentation applies and > > neither array should be empty.
> > Actually, it is covered: > > @c = (0,1)[2,3]; # @c has no elements
D’oh. That is not a particularly empty list, the introductory verbiage is misleading. So that means: @a = 1..2; @b = @a [4,5,6]; # @b has 3 elements (all undef) @c = (@a)[4,5,6]; # @c has 0 elements It is an understatement to say I’m not wild about this design, but if it is intended… Patch attached.

Message body is not shown because sender requested not to inline it.

Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Fri, 31 Aug 2012 06:39:37 -0700 (PDT)
To: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>, Uri Guttman <uri [...] stemsystems.com>, "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
From: John Wiersba <jrw32982 [...] yahoo.com>
Download (untitled) / with headers
text/plain 2.4k
Please see the example below.

First, as the example below shows, there are inconsistencies depending on whether or not the list is held in a variable (@a1 or @a4) or a constant ((8) or ()) or a function return value.  I don't see how these can be anything other than one or more bugs.

Second, if there is intention (as Uri says and perldata says) to return an empty list when the list being sliced is an empty list, then there is a bug (as shown below) when the empty list is held in a variable @a4 vs. an empty list constant or an empty list returned from a function f4.

Third, perhaps the documentation could be enhanced to make this intentional inconsistency (in the handling of list slices when the subscripts are off the end of the list and the list goes from non-empty to empty) more obvious in documentation, since it is surprising due to the inconsistency.

-- John

#!/usr/bin/perl
use warnings;
use Data::Dumper;

sub f1 { return (9) }
@a1 = (7);
@x1 = (@a1[0,1,2]);  # [ 7, undef, undef ];
@y1 = (@a1[  1,2]);  # [    undef, undef ];
@x2 = ((8)[0,1,2]);  # [ 8, undef, undef ];
@y2 = ((8)[  1,2]);  # [];
@x3 = ((f1)[0,1,2]); # [ 9, undef, undef ];
@y3 = ((f1)[  1,2]); # [];

sub f4 { return () }
@a4 = ();
@x4 = (@a4[0,1,2]);  # [ undef, undef, undef ];
@y4 = (@a4[  1,2]);  # [        undef, undef ];
@x5 = (()[0,1,2]);   # [];
@y5 = (()[  1,2]);   # [];
@x6 = ((f4)[0,1,2]); # [];
@y6 = ((f4)[  1,2]); # [];

print Data::Dumper->Dump([\@x1, \@y1], [qw[x1 y1]]);
print Data::Dumper->Dump([\@x2, \@y2], [qw[x2 y2]]);
print Data::Dumper->Dump([\@x3, \@y3], [qw[x3 y3]]);
print "\n";
print Data::Dumper->Dump([\@x4, \@y4], [qw[x4 y4]]);
print Data::Dumper->Dump([\@x5, \@y5], [qw[x5 y5]]);
print Data::Dumper->Dump([\@x6, \@y6], [qw[x6 y6]]);





Show quoted text

From: Eirik Berg Hanssen <Eirik-Berg.Hanssen@allverden.no>
To: Uri Guttman <uri@stemsystems.com>
Cc: perl5-porters@perl.org
Sent: Friday, August 31, 2012 1:57 AM
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items

On Fri, Aug 31, 2012 at 7:20 AM, Uri Guttman <uri@stemsystems.com> wrote:
my view is the docs could use a little more clarity saying that a slice of only indexes beyond the last one is always an empty list.

  ... or just explain why C<< (0,1)[2,3] >> is an example of "a slice of an empty list".  To me it looks like a slice of C<< (0, 1) >>, which in turn does not look particularly empty ...


Eirik


Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Fri, 31 Aug 2012 06:41:17 -0700 (PDT)
To: Aristotle Pagaltzis <pagaltzis [...] gmx.de>, "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
From: John Wiersba <jrw32982 [...] yahoo.com>
Download (untitled) / with headers
text/plain 1.1k
I'm not wild about it either, since it is inconsistent, but it is documented.  It certainly threw me for a loop when I encountered it in live code.

Show quoted text

From: Aristotle Pagaltzis <pagaltzis@gmx.de>
To: perl5-porters@perl.org
Sent: Friday, August 31, 2012 9:08 AM
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items

* Eric Brine <ikegami@adaelis.com> [2012-08-31 07:15]:
> On Fri, Aug 31, 2012 at 12:51 AM, Aristotle Pagaltzis <pagaltzis@gmx.de>wrote:
> > In both cases the slice is of a one-element list, not of an empty
> > list, so the “But” clause from the quoted documentation applies and
> > neither array should be empty.
>
> Actually, it is covered:
>
> @c = (0,1)[2,3];        # @c has no elements

D’oh. That is not a particularly empty list, the introductory verbiage
is misleading. So that means:

    @a = 1..2;
    @b =  @a [4,5,6]; # @b has 3 elements (all undef)
    @c = (@a)[4,5,6]; # @c has 0 elements

It is an understatement to say I’m not wild about this design, but if
it is intended…

Patch attached.


RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.4k
On Fri Aug 31 06:40:15 2012, jrw32982@yahoo.com wrote: Show quoted text
> Please see the example below. > > First, as the example below shows, there are inconsistencies depending > on whether or not the list is held in a variable (@a1 or @a4) or a > constant ((8) or ()) or a function return value.� I don't see how > these can be anything other than one or more bugs.
@a[1] and (@a)[1] are different creatures. The former is an array slice. The main difference is that you can assign to @a[1], but not to (@a)[1]. Show quoted text
> #!/usr/bin/perl > use warnings; > use Data::Dumper; > > sub f1 { return (9) } > @a1 = (7); > @x1 = (@a1[0,1,2]);� # [ 7, undef, undef ]; > @y1 = (@a1[� 1,2]);� # [��� undef, undef ]; > @x2 = ((8)[0,1,2]);� # [ 8, undef, undef ]; > @y2 = ((8)[� 1,2]);� # []; > @x3 = ((f1)[0,1,2]); # [ 9, undef, undef ]; > @y3 = ((f1)[� 1,2]); # []; > > sub f4 { return () } > @a4 = (); > @x4 = (@a4[0,1,2]);� # [ undef, undef, undef ]; > @y4 = (@a4[� 1,2]);� # [������� undef, undef ]; > @x5 = (()[0,1,2]);�� # []; > @y5 = (()[� 1,2]);�� # []; > @x6 = ((f4)[0,1,2]); # []; > @y6 = ((f4)[� 1,2]); # []; > > print Data::Dumper->Dump([\@x1, \@y1], [qw[x1 y1]]); > print Data::Dumper->Dump([\@x2, \@y2], [qw[x2 y2]]); > print Data::Dumper->Dump([\@x3, \@y3], [qw[x3 y3]]); > print "\n"; > print Data::Dumper->Dump([\@x4, \@y4], [qw[x4 y4]]); > print Data::Dumper->Dump([\@x5, \@y5], [qw[x5 y5]]); > print Data::Dumper->Dump([\@x6, \@y6], [qw[x6 y6]]);
-- Father Chrysostomos
RT-Send-CC: perl5-porters [...] perl.org, pagaltzis [...] gmx.de
Download (untitled) / with headers
text/plain 849b
On Fri Aug 31 06:09:29 2012, aristotle wrote: Show quoted text
> * Eric Brine <ikegami@adaelis.com> [2012-08-31 07:15]:
> > On Fri, Aug 31, 2012 at 12:51 AM, Aristotle Pagaltzis
> <pagaltzis@gmx.de>wrote:
> > > In both cases the slice is of a one-element list, not of an empty > > > list, so the “But” clause from the quoted documentation applies
> and
> > > neither array should be empty.
> > > > Actually, it is covered: > > > > @c = (0,1)[2,3]; # @c has no elements
> > D’oh. That is not a particularly empty list, the introductory verbiage > is misleading. So that means: > > @a = 1..2; > @b = @a [4,5,6]; # @b has 3 elements (all undef) > @c = (@a)[4,5,6]; # @c has 0 elements > > It is an understatement to say I’m not wild about this design, but if > it is intended…
Thank you. Applied as f51152e. -- Father Chrysostomos
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Fri, 31 Aug 2012 09:13:33 -0700 (PDT)
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
From: John Wiersba <jrw32982 [...] yahoo.com>
Download (untitled) / with headers
text/plain 1.9k
Show quoted text
_______________________________
> From: Father Chrysostomos via RT <perlbug-followup@perl.org> >To: jrw32982@yahoo.com >Sent: Friday, August 31, 2012 11:47 AM >Subject: [perl #114498] List slice *sometimes* ignores undefined items > >On Fri Aug 31 06:40:15 2012, jrw32982@yahoo.com wrote:
>> Please see the example below. >> >> First, as the example below shows, there are inconsistencies depending >>    on whether or not the list is held in a variable (@a1 or @a4) or a >>    constant ((8) or ()) or a function return value.  I don't see how >>    these can be anything other than one or more bugs.
> >@a[1] and (@a)[1] are different creatures.  The former is an array >slice.  The main difference is that you can assign to @a[1], but not to >(@a)[1].
OK.  But I don't see what that has to do with this bug report.  I don't believe I ever used code like that in my submission.  I used (@a[1]).  But regardless, if I leave off the surrounding parens, I get the same result. Have we agreed that we have a unambiguous bug? Here is the revised test program that still shows the bug. #!/usr/bin/perl use warnings; use Data::Dumper; sub f1 { return (9) } @a1 = (7); @x1 = @a1[0,1,2];  # [ 7, undef, undef ]; @y1 = @a1[  1,2];  # [    undef, undef ]; @x2 = (8)[0,1,2];  # [ 8, undef, undef ]; @y2 = (8)[  1,2];  # []; @x3 = (f1)[0,1,2]; # [ 9, undef, undef ]; @y3 = (f1)[  1,2]; # []; sub f4 { return () } @a4 = (); @x4 = @a4[0,1,2];  # [ undef, undef, undef ]; @y4 = @a4[  1,2];  # [        undef, undef ]; @x5 = ()[0,1,2];   # []; @y5 = ()[  1,2];   # []; @x6 = (f4)[0,1,2]; # []; @y6 = (f4)[  1,2]; # []; print Data::Dumper->Dump([\@x1, \@y1], [qw[x1 y1]]); print Data::Dumper->Dump([\@x2, \@y2], [qw[x2 y2]]); print Data::Dumper->Dump([\@x3, \@y3], [qw[x3 y3]]); print "\n"; print Data::Dumper->Dump([\@x4, \@y4], [qw[x4 y4]]); print Data::Dumper->Dump([\@x5, \@y5], [qw[x5 y5]]); print Data::Dumper->Dump([\@x6, \@y6], [qw[x6 y6]]);
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 228b
On Fri Aug 31 08:49:00 2012, sprout wrote: Show quoted text
> > Thank you. Applied as f51152e. >
Father C: I see this ticket in the Rejected queue. Should it actually be in Resolved? Or is it still Open? Thank you very much. Jim Keenan
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.4k
On Fri Aug 31 09:14:20 2012, jrw32982@yahoo.com wrote: Show quoted text
> _______________________________
> > From: Father Chrysostomos via RT <perlbug-followup@perl.org> > >To: jrw32982@yahoo.com > >Sent: Friday, August 31, 2012 11:47 AM > >Subject: [perl #114498] List slice *sometimes* ignores undefined
> items
> > > >On Fri Aug 31 06:40:15 2012, jrw32982@yahoo.com wrote:
> >> Please see the example below. > >> > >> First, as the example below shows, there are inconsistencies
> depending
> >>� � on whether or not the list is held in a variable (@a1 or @a4) or
> a
> >>� � constant ((8) or ()) or a function return value.� I don't see
> how
> >>� � these can be anything other than one or more bugs.
> > > >@a[1] and (@a)[1] are different creatures.� The former is an array > >slice.� The main difference is that you can assign to @a[1], but not
> to
> >(@a)[1].
> > OK.� But I don't see what that has to do with this bug report.� I > don't believe I ever used code like that in my submission.� I used > (@a[1]).
Which is an array slice, not a list silce. Show quoted text
> But regardless, if I leave off the surrounding parens, I > get the same result.
If you add parentheses, and use (@a)[1], you will get consistent results. Show quoted text
> > > Have we agreed that we have a unambiguous bug?
No. The example below uses both array slice and list slice. If you use only list slice, you will get consistent results. The special case applies only to list slices. Show quoted text
> > Here is the revised test program that still shows the bug. > > > #!/usr/bin/perl > use warnings; > use Data::Dumper; > > sub f1 { return (9) } > @a1 = (7); > @x1 = @a1[0,1,2];� # [ 7, undef, undef ]; > @y1 = @a1[� 1,2];� # [��� undef, undef ]; > @x2 = (8)[0,1,2];� # [ 8, undef, undef ]; > @y2 = (8)[� 1,2];� # []; > @x3 = (f1)[0,1,2]; # [ 9, undef, undef ]; > @y3 = (f1)[� 1,2]; # []; > > sub f4 { return () } > @a4 = (); > @x4 = @a4[0,1,2];� # [ undef, undef, undef ]; > @y4 = @a4[� 1,2];� # [������� undef, undef ]; > @x5 = ()[0,1,2];�� # []; > @y5 = ()[� 1,2];�� # []; > @x6 = (f4)[0,1,2]; # []; > @y6 = (f4)[� 1,2]; # []; > > print Data::Dumper->Dump([\@x1, \@y1], [qw[x1 y1]]); > print Data::Dumper->Dump([\@x2, \@y2], [qw[x2 y2]]); > print Data::Dumper->Dump([\@x3, \@y3], [qw[x3 y3]]); > print "\n"; > print Data::Dumper->Dump([\@x4, \@y4], [qw[x4 y4]]); > print Data::Dumper->Dump([\@x5, \@y5], [qw[x5 y5]]); > print Data::Dumper->Dump([\@x6, \@y6], [qw[x6 y6]]); >
-- Father Chrysostomos
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 502b
On Sat Sep 01 16:02:23 2012, jkeenan wrote: Show quoted text
> On Fri Aug 31 08:49:00 2012, sprout wrote:
> > > > Thank you. Applied as f51152e. > >
> > Father C: I see this ticket in the Rejected queue. Should it actually > be in Resolved? Or is it still Open?
Well, the original bug report was not a bug. But some of the documentation cited to support such designation was unclear, and got clarified as a result. So I don’t really know whether it should be rejected or resolved. -- Father Chrysostomos
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Sat, 1 Sep 2012 23:20:46 -0400
To: Father Chrysostomos via RT <perlbug-followup [...] perl.org>, John Wiersba <jrw32982 [...] yahoo.com>
From: John Wiersba <jrw32982 [...] gmail.com>
Download (untitled) / with headers
text/plain 6.6k
Somehow, I'm not explaining this properly. This is not just a doc bug. This is an implementation bug. The bug is the inconsistency of the behavior of list and array slices in the presence of out-of-bounds indexes. How is anyone supposed to understand and predict the results achieved when an array or list slice contains indexes off the end of the array or list? If you slice a list, you get completely different results depending on if the slice includes at least one in-bounds index or not. If you use an array, you get the same results as one of the list cases, but the results do *not* vary depending on if the slice includes at least one in-bounds index or not. What a mess! The only excuse for keeping the status quo would be backwards compatibility. If that is the reason for not fixing this bug, then please state so, and I'll go quietly. Otherwise, I submit that the results I get from my test program below are a disaster from the point of view of someone trying to comprehend or predict them. IMO, this is worse than an interpreter crash, which at least indicates that something went very wrong. It has taken me many tries before I came up with the simplest characterization of the results (in my bug description above). As you can see, it is none too simple. How is someone who has not spent hours writing and refining a test program (below) and analyzing the results supposed to find any consistency in the results of list or array slices when dealing with out-of-bounds indexes? I have added to my test cases below to show this issue with all the variations I can think of, including the difference between arrays and lists, the difference between empty and non-empty arrays/lists, and the difference between slices which include in-bounds indexes and those which don't. This reminds me of the smartmatch discussion, where nobody can predict what will happen in the general case, without referring to a complicated table of results. P.S. I don't think it's helping that either my reader or your reader is screwing up the formatting of my test program which, when displayed in a monospaced font, makes the test results clearer. I'm switching to a gmail account rather than a yahoo account in the hopes that we can resolve the formatting issue. I've configured my client to send plain text, but still the emails I'm getting back from you contain some indecipherable characters even though all I'm sending is (I believe) ASCII. Is there something that I'm missing here? Should I not be sending plain text emails, but instead be sending rich text emails with the program formatted in courier? use strict; use warnings; use Data::Dumper; sub f1 { return (9) } my @a1 = (7); my @x1 = @a1[2,0,1]; # [ undef, 7, undef ] my @y1 = @a1[2, 1]; # [ undef, undef ] my @x2 = (@a1)[2,0,1]; # [ undef, 7, undef ] my @y2 = (@a1)[2, 1]; # [] my @x3 = (8)[2,0,1]; # [ undef, 8, undef ] my @y3 = (8)[2, 1]; # [] my @x4 = (f1)[2,0,1]; # [ undef, 9, undef ] my @y4 = (f1)[2, 1]; # [] sub f5 { return () } my @a5 = (); my @x5 = @a5[2,0,1]; # [ undef, undef, undef ] my @y5 = @a5[2, 1]; # [ undef, undef ] my @x6 = (@a5)[2,0,1]; # [] my @y6 = (@a5)[2, 1]; # [] my @x7 = ()[2,0,1]; # [] my @y7 = ()[2, 1]; # [] my @x8 = (f5)[2,0,1]; # [] my @y8 = (f5)[2, 1]; # [] print Data::Dumper->Dump([\@x1, \@y1], [qw[x1 y1]]); print Data::Dumper->Dump([\@x2, \@y2], [qw[x2 y2]]); print Data::Dumper->Dump([\@x3, \@y3], [qw[x3 y3]]); print Data::Dumper->Dump([\@x4, \@y4], [qw[x4 y4]]); print "\n"; print Data::Dumper->Dump([\@x5, \@y5], [qw[x5 y5]]); print Data::Dumper->Dump([\@x6, \@y6], [qw[x6 y6]]); print Data::Dumper->Dump([\@x7, \@y7], [qw[x7 y7]]); print Data::Dumper->Dump([\@x8, \@y8], [qw[x8 y8]]); On Sat, Sep 1, 2012 at 9:14 PM, John Wiersba <jrw32982@yahoo.com> wrote: Show quoted text
> > > ________________________________ > From: Father Chrysostomos via RT <perlbug-followup@perl.org> > To: jrw32982@yahoo.com > Sent: Saturday, September 1, 2012 8:18 PM > Subject: [perl #114498] List slice *sometimes* ignores undefined items > > On Fri Aug 31 09:14:20 2012, jrw32982@yahoo.com wrote:
> > _______________________________
> > > From: Father Chrysostomos via RT <perlbug-followup@perl.org> > > >To: jrw32982@yahoo.com > > >Sent: Friday, August 31, 2012 11:47 AM > > >Subject: [perl #114498] List slice *sometimes* ignores undefined
> > items
> > > > > >On Fri Aug 31 06:40:15 2012, jrw32982@yahoo.com wrote:
> > >> Please see the example below. > > >> > > >> First, as the example below shows, there are inconsistencies
> > depending
> > >>� � on whether or not the list is held in a variable (@a1 or @a4) or
> > a
> > >>� � constant ((8) or ()) or a function return value.� I don't see
> > how
> > >>� � these can be anything other than one or more bugs.
> > > > > >@a[1] and (@a)[1] are different creatures.� The former is an array > > >slice.� The main difference is that you can assign to @a[1], but not
> > to
> > >(@a)[1].
> > > > OK.� But I don't see what that has to do with this bug report.� I > > don't believe I ever used code like that in my submission.� I used > > (@a[1]).
> > Which is an array slice, not a list silce. >
> > But regardless, if I leave off the surrounding parens, I > > get the same result.
> > If you add parentheses, and use (@a)[1], you will get consistent results. >
> > > > > > Have we agreed that we have a unambiguous bug?
> > No. The example below uses both array slice and list slice. If you use > only list slice, you will get consistent results. The special case > applies only to list slices. >
> > > > Here is the revised test program that still shows the bug. > > > > > > #!/usr/bin/perl > > use warnings; > > use Data::Dumper; > > > > sub f1 { return (9) } > > @a1 = (7); > > @x1 = @a1[0,1,2];� # [ 7, undef, undef ]; > > @y1 = @a1[� 1,2];� # [��� undef, undef ]; > > @x2 = (8)[0,1,2];� # [ 8, undef, undef ]; > > @y2 = (8)[� 1,2];� # []; > > @x3 = (f1)[0,1,2]; # [ 9, undef, undef ]; > > @y3 = (f1)[� 1,2]; # []; > > > > sub f4 { return () } > > @a4 = (); > > @x4 = @a4[0,1,2];� # [ undef, undef, undef ]; > > @y4 = @a4[� 1,2];� # [������� undef, undef ]; > > @x5 = ()[0,1,2];�� # []; > > @y5 = ()[� 1,2];�� # []; > > @x6 = (f4)[0,1,2]; # []; > > @y6 = (f4)[� 1,2]; # []; > > > > print Data::Dumper->Dump([\@x1, \@y1], [qw[x1 y1]]); > > print Data::Dumper->Dump([\@x2, \@y2], [qw[x2 y2]]); > > print Data::Dumper->Dump([\@x3, \@y3], [qw[x3 y3]]); > > print "\n"; > > print Data::Dumper->Dump([\@x4, \@y4], [qw[x4 y4]]); > > print Data::Dumper->Dump([\@x5, \@y5], [qw[x5 y5]]); > > print Data::Dumper->Dump([\@x6, \@y6], [qw[x6 y6]]); > >
> > > -- > > Father Chrysostomos > > >
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Sun, 2 Sep 2012 14:50:41 +0200
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 1.6k
* John Wiersba <jrw32982@gmail.com> [2012-09-02 07:45]: Show quoted text
> Somehow, I'm not explaining this properly.
Don’t worry, you made yourself understood. Show quoted text
> This is not just a doc bug. This is an implementation bug.
No. It is a dubious design, maybe a design bug. It *is* surprising and messy. But the *implementation* is not buggy – it implements the messy design correctly. Show quoted text
> This reminds me of the smartmatch discussion, where nobody can predict > what will happen in the general case, without referring to > a complicated table of results.
But actually, this is very different: *once you know*, it is very easy to say which of your test cases will produce which result under what circumstances. It is extremely surprising however, if you do not know. The lack of parallelism between arrays and lists makes me very unhappy. But if it was designed this way and documented as it is for such a long time, then I rather doubt it can change. I don’t know how much code relies on it (I have probably never written any – if anything, changing this is liable to fix code that I have written), but this cannot even be searched for on grep.cpan.me or such to see how disruptive it might be to change it. So if it were to be changed there would have to be an extremely long lead time with a (runtime :-( ) deprecation warning. Show quoted text
> P.S. […]
I don’t think anyone is missing any point because of formatting. Your mails exceed ASCII by including non-breaking spaces (U+00A0), but that is in Latin-1 – no Unicode needed. And your mails have all the requisite headers for that to work correctly. It is FC’s mail client that isn’t up to snuff. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 254b
On Sun Sep 02 05:51:27 2012, aristotle wrote: Show quoted text
> It is FC’s mail client that isn’t up > to snuff.
I am using the RT web interface. I think I know what is going on now. It treats Latin-1 as UTF-8, instead of converting it. -- Father Chrysostomos
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Sun, 2 Sep 2012 13:34:01 -0700 (PDT)
To: Aristotle Pagaltzis <pagaltzis [...] gmx.de>, "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
From: John Wiersba <jrw32982 [...] yahoo.com>
Download (untitled) / with headers
text/plain 4.2k


Show quoted text

From: Aristotle Pagaltzis <pagaltzis@gmx.de>
To: perl5-porters@perl.org
Sent: Sunday, September 2, 2012 8:50 AM
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items

* John Wiersba <jrw32982@gmail.com> [2012-09-02 07:45]:
> Somehow, I'm not explaining this properly.

Don’t worry, you made yourself understood.

> This is not just a doc bug. This is an implementation bug.

No. It is a dubious design, maybe a design bug. It *is* surprising and
messy. But the *implementation* is not buggy – it implements the messy
design correctly.

OK, I see that's one way of looking at it.  However my way of looking at it is that there's an implementation bug which has been documented (but maybe not documented well enough?).  There is a limit at which we should consider something an implementation bug rather than just some quirk to be documented.  For example, if "print 7" prints "q" and it's documented as such, it's still a bug that should be fixed.  But I do agree with your point below that if there's a lot (where "lot" needs to be defined) of code which depends on the bug, then maybe it shouldn't be fixed.

Show quoted text
> This reminds me of the smartmatch discussion, where nobody can predict
> what will happen in the general case, without referring to
> a complicated table of results.

But actually, this is very different: *once you know*, it is very easy
to say which of your test cases will produce which result under what
circumstances.

It is extremely surprising however, if you do not know.

The lack of parallelism between arrays and lists makes me very unhappy.

The rule took me a long time to figure out (or even to figure out that there was a rule).  From my initial investigation, which I originally coded, I thought the rule was:  a slice returns undef for each specified index which is off the end of the array or list.  Big mistake!  That only works if 1) it's an array slice rather than a list slice, or 2) if the list slice has at least one index not out-of-bounds.

The actual complete rule seems to be:
  1. An array slice always returns one item for each index specified, returning undef for each out-of-bounds index.
  2. Like an array slice, a list slice which contains at least one index which is not out-of-bounds returns one item for each index specified, returning undef for each out-of-bounds index.
  3. However, unlike an array slice, a list slice where every specified index is out-of bounds returns an empty list.
I don't think the current docs make it clear that array slices are different than list slices.  That could be fixed with the above verbiage.

But the real problem is that this situation doesn't come up often enough in real life to remember.  I don't mind remembering little edge cases if they come up often and they provide value.  But when they come up infrequently they are effectively bugs because programmers will not remember them and will assume that there is no inconsistent edge case.  That's what I encountered in my production code (and I have been writing perl for 15 years, so I am not a newbie).  BTW, this is part of what people don't like about perl:  that it has *too many* inconsistent edge cases and magic idioms.

Show quoted text
But if it was designed this way and documented as it is for such a long
time, then I rather doubt it can change. I don’t know how much code
relies on it (I have probably never written any – if anything, changing
this is liable to fix code that I have written), but this cannot even be
searched for on grep.cpan.me or such to see how disruptive it might be
to change it. So if it were to be changed there would have to be an
extremely long lead time with a (runtime :-( ) deprecation warning.

Well, better late than never.  :-)

Show quoted text
> P.S. […]

I don’t think anyone is missing any point because of formatting. Your
mails exceed ASCII by including non-breaking spaces (U+00A0), but that
is in Latin-1 – no Unicode needed. And your mails have all the requisite
headers for that to work correctly. It is FC’s mail client that isn’t up
to snuff.

It must be that U+00A0 is added when there are 2+ consecutive spaces.  I added extra spaces to make the code line up if viewed in a monospace font.

-- John
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 5.7k
On Sun Sep 02 13:34:41 2012, jrw32982@yahoo.com wrote: Show quoted text
> > > > >
> >________________________________ > > From: Aristotle Pagaltzis <pagaltzis@gmx.de> > >To: perl5-porters@perl.org > >Sent: Sunday, September 2, 2012 8:50 AM > >Subject: Re: [perl #114498] List slice *sometimes* ignores undefined
> items
> > > >* John Wiersba <jrw32982@gmail.com> [2012-09-02 07:45]:
> >> Somehow, I'm not explaining this properly.
> > > >Don’t worry, you made yourself understood. > >
> >> This is not just a doc bug. This is an implementation bug.
> > > >No. It is a dubious design, maybe a design bug. It *is* surprising
> and
> >messy. But the *implementation* is not buggy – it implements the
> messy
> >design correctly. > >
> > OK, I see that's one way of looking at it.  However my way of looking > at it is that there's an implementation bug which has been > documented (but maybe not documented well enough?).  There is a > limit at which we should consider something an implementation bug > rather than just some quirk to be documented.  For example, if > "print 7" prints "q" and it's documented as such, it's still a bug > that should be fixed.  But I do agree with your point below that if > there's a lot (where "lot" needs to be defined) of code which > depends on the bug, then maybe it shouldn't be fixed. > >
> > This reminds me of the smartmatch discussion, where nobody can
> predict
> >> what will happen in the general case, without referring to > >> a complicated table of results.
> > > >But actually, this is very different: *once you know*, it is very
> easy
> >to say which of your test cases will produce which result under what > >circumstances. > > > >It is extremely surprising however, if you do not know. > > > >The lack of parallelism between arrays and lists makes me very
> unhappy.
> >
> > The rule took me a long time to figure out (or even to figure out that > there was a rule).  From my initial investigation, which I > originally coded, I thought the rule was:  a slice returns undef > for each specified index which is off the end of the array or list. > Big mistake!  That only works if 1) it's an array slice rather than > a list slice, or 2) if the list slice has at least one index not > out-of-bounds. > > The actual complete rule seems to be: > > 1. An array slice always returns one item for each index specified, > returning undef for each out-of-bounds index. > 2. Like an array slice, a list slice which contains at least one > index which is not out-of-bounds returns one item for each index > specified, returning undef for each out-of-bounds index. > 3. However, unlike an array slice, a list slice where every specified > index is out-of bounds returns an empty list. > I don't think the current docs make it clear that array slices are > different than list slices.  That could be fixed with the above > verbiage. > > But the real problem is that this situation doesn't come up often > enough in real life to remember.  I don't mind remembering little > edge cases if they come up often and they provide value.  But when > they come up infrequently they are effectively bugs because > programmers will not remember them and will assume that there is no > inconsistent edge case.  That's what I encountered in my production > code (and I have been writing perl for 15 years, so I am not a > newbie).  BTW, this is part of what people don't like about perl: > that it has *too many* inconsistent edge cases and magic idioms. > > > But if it was designed this way and documented as it is for such a > long
> >time, then I rather doubt it can change. I don’t know how much code > >relies on it (I have probably never written any – if anything,
> changing
> >this is
> liable to fix code that I have written), but this cannot even be
> >searched for on grep.cpan.me or such to see how disruptive it might
> be
> >to change it. So if it were to be changed there would have to be an > >extremely long lead time with a (runtime :-( ) deprecation warning. > >
> > Well, better late than never.  :-)
The change to the current behaviour was made in commit c73bf8e3ece26. The note in perl56delta.pod was added in commit 08cd89523, along with the documentation in perldata.pod. What strikes me is that perl56delta says this: +=item Treatment of list slices of undef has changed + +When taking a slice of a literal list (as opposed to a slice of +an array or hash), Perl used to return an empty list if the +result happened to be composed of all undef values. + +The new behavior is to produce an empty list if (and only if) +the original list was empty. So it seems the new behaviour was not actually implemented as intended. The documentation in perldata added by the same commit said this originally: -As a special rule, if a list slice would produce a list consisting -entirely of undefined values, the null list is produced instead. +A slice of an empty list is still an empty list. Thus: + + @a = ()[1,0]; # @a has no elements + @b = (@a)[0,1]; # @b has no elements + @b = (1,undef)[1,0,1]; # @b has three elements Four months later, in commit 56d7751aa, the documentation was corrected to match the implementation: A slice of an empty list is still an empty list. Thus: @a = ()[1,0]; # @a has no elements @b = (@a)[0,1]; # @b has no elements - @b = (1,undef)[1,0,1]; # @b has three elements + @c = (0,1)[2,3]; # @c has no elements + +But: + + @a = (1)[1,0]; # @a has two elements + @b = (1,undef)[1,0,2]; # @b has three elements So maybe this should change to what is documented in perl56delta.pod. In any case, this is not resolved, so I’m reopening it. -- Father Chrysostomos
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Mon, 3 Sep 2012 12:44:32 -0700 (PDT)
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
From: John Wiersba <jrw32982 [...] yahoo.com>
Download (untitled) / with headers
text/plain 3.3k


Show quoted text

From: Father Chrysostomos via RT <perlbug-followup@perl.org>
To:
Cc: perl5-porters@perl.org
Sent: Sunday, September 2, 2012 7:18 PM
Subject: [perl #114498] List slice *sometimes* ignores undefined items

On Sun Sep 02 13:34:41 2012, jrw32982@yahoo.com wrote:
> ...
> The actual complete rule seems to be:
>
>     1. An array slice always returns one item for each index specified,
>    returning undef for each out-of-bounds index.
>     2. Like an array slice, a list slice which contains at least one
>    index which is not out-of-bounds returns one item for each index
>    specified, returning undef for each out-of-bounds index.
>     3. However, unlike an array slice, a list slice where every specified
>    index is out-of bounds returns an empty list.
> I don't think the current docs make it clear that array slices are
>    different than list slices.  That could be fixed with the above
>    verbiage.
> ...

The change to the current behaviour was made in commit c73bf8e3ece26.
The note in perl56delta.pod was added in commit 08cd89523, along with
the documentation in perldata.pod.  What strikes me is that perl56delta
says this:

+=item Treatment of list slices of undef has changed
+
+When taking a slice of a literal list (as opposed to a slice of
+an array or hash), Perl used to return an empty list if the
+result happened to be composed of all undef values.
+
+The new behavior is to produce an empty list if (and only if)
+the original list was empty.

So it seems the new behaviour was not actually implemented as intended.
The documentation in perldata added by the same commit said this
originally:

-As a special rule, if a list slice would produce a list consisting
-entirely of undefined values, the null list is produced instead.
+A slice of an empty list is still an empty list.  Thus:
+
+    @a = ()[1,0];          # @a has no elements
+    @b = (@a)[0,1];        # @b has no elements
+    @b = (1,undef)[1,0,1];  # @b has three elements

Four months later, in commit 56d7751aa, the documentation was corrected
to match the implementation:

A slice of an empty list is still an empty list.  Thus:

    @a = ()[1,0];          # @a has no elements
    @b = (@a)[0,1];        # @b has no elements
-    @b = (1,undef)[1,0,1];  # @b has three elements
+    @c = (0,1)[2,3];        # @c has no elements
+
+But:
+
+    @a = (1)[1,0];          # @a has two elements
+    @b = (1,undef)[1,0,2];  # @b has three elements

So maybe this should change to what is documented in perl56delta.pod.
In any case, this is not resolved, so I’m reopening it.

--

Father Chrysostomos


---
via perlbug:  queue: perl5 status: rejected
https://rt.perl.org:443/rt3/Ticket/Display.html?id=114498

FC: thanks for checking into this.  I was a little scared that I'd missed a case after I read the comments that you unearthed (above).  But after running a new test script against perl 5.8.9 and 5.14.2,  the results still seem to agree with my list of rules (above).  The results apparently do *not* depend on the *value* of the specified elements (whether or not they're undefined), but only on whether or not the specified indexes are in-bounds or out-of-bounds.

-- John
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Fri, 7 Sep 2012 01:47:25 +0200
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 1.5k
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-09-03 01:20]: Show quoted text
> So it seems the new behaviour was not actually implemented as > intended.
Phew. I’m very glad to hear the current behaviour was not by design, much less by Larry’s design… but is in fact an implementation bug. In which case – yes please, let’s get rid of the Surprise! “feature”. Show quoted text
> The documentation in perldata added by the same commit said this > originally: > > -As a special rule, if a list slice would produce a list consisting > -entirely of undefined values, the null list is produced instead. > +A slice of an empty list is still an empty list. Thus: > + > + @a = ()[1,0]; # @a has no elements > + @b = (@a)[0,1]; # @b has no elements > + @b = (1,undef)[1,0,1]; # @b has three elements
That actually makes sense. There’s still an asymmetry with arrays, in that @a = (); @b = @a [0,1]; # @b would have 2 elements @c = (@a)[0,1]; # @c would have 0 elements but this is far less bewildering because @a = ('a'..'c'); @b = @a [5,6]; # @b would have 2 elements @c = (@a)[5,6]; # @c would have 2 elements and the empty-list-only exemption is in fact useful in just the way outlined in the docs. And this special case is much easier to explain: “slices of empty literal lists always yield the empty list“. Simple to understand, and thus much easier to learn and to remember. Let’s have it that way. -- *AUTOLOAD=*_;sub _{s/::([^:]*)$/print$1,(",$\/"," ")[defined wantarray]/e;chop;$_} &Just->another->Perl->hack; #Aristotle Pagaltzis // <http://plasmasturm.org/>
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Thu, 6 Sep 2012 20:58:31 -0700 (PDT)
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
From: John Wiersba <jrw32982 [...] yahoo.com>
Download (untitled) / with headers
text/plain 2.9k
Aristotle, let me see if I understand what you're proposing.

The basic rule for array/list slices is:
a) A slice returns one element for each index specified.  If the index is out-of-bounds, then undef is returned for that element.

I believe that you're proposing amending that rule to allow a single exception:
b) A slice of an empty list always returns no elements.  A list is specified when literal parentheses are used.
c) There are no other exceptions.  In particular, a slice of an empty array returns one element for each index specified.
d) A slice of a hash, or of a reference to an array or hash, always returns one element for each index or key specified, regardless of number of elements in the hash or array.

Is that right?  If so, could it be explicitly spelled out in the docs, more or less as I've stated it above rather than using only examples.  I don't mind the examples (they can help clarify the difference between a list and an array in this context), but I would prefer that there also be some verbiage specifying the rules as clearly as possible.

-- John

Show quoted text

From: A. Pagaltzis via RT <perlbug-followup@perl.org>
To: jrw32982@yahoo.com
Sent: Thursday, September 6, 2012 7:48 PM
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items

* Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-09-03 01:20]:
> So it seems the new behaviour was not actually implemented as
> intended.

Phew. I’m very glad to hear the current behaviour was not by design,
much less by Larry’s design… but is in fact an implementation bug. In
which case – yes please, let’s get rid of the Surprise! “feature”.

> The documentation in perldata added by the same commit said this
> originally:
>
> -As a special rule, if a list slice would produce a list consisting
> -entirely of undefined values, the null list is produced instead.
> +A slice of an empty list is still an empty list.  Thus:
> +
> +    @a = ()[1,0];          # @a has no elements
> +    @b = (@a)[0,1];        # @b has no elements
> +    @b = (1,undef)[1,0,1];  # @b has three elements

That actually makes sense. There’s still an asymmetry with arrays,
in that

    @a =  ();
    @b =  @a [0,1]; # @b would have 2 elements
    @c = (@a)[0,1]; # @c would have 0 elements

but this is far less bewildering because

    @a = ('a'..'c');
    @b =  @a [5,6]; # @b would have 2 elements
    @c = (@a)[5,6]; # @c would have 2 elements

and the empty-list-only exemption is in fact useful in just the way
outlined in the docs.

And this special case is much easier to explain: “slices of empty
literal lists always yield the empty list“. Simple to understand,
and thus much easier to learn and to remember.

Let’s have it that way.

--
*AUTOLOAD=*_;sub _{s/::([^:]*)$/print$1,(",$\/"," ")[defined wantarray]/e;chop;$_}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // <http://plasmasturm.org/>




Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Fri, 7 Sep 2012 17:48:10 +0200
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 1.8k
* John Wiersba <jrw32982@yahoo.com> [2012-09-07 06:00]: Show quoted text
> Aristotle, let me see if I understand what you're proposing.
OK. Show quoted text
> The basic rule for array/list slices is: > a) A slice returns one element for each index specified. If the index > is out-of-bounds, then undef is returned for that element.
Yes… but you are aware that this is currently not the whole story, right? That there already is a strange exception for literal lists? (Which is what this ticket is about.) Show quoted text
> I believe that you're proposing amending that rule to allow a single > exception: > b) A slice of an empty list always returns no elements.  A list is > specified when literal parentheses are used. > c) There are no other exceptions.  In particular, a slice of an empty > array returns one element for each index specified. > d) A slice of a hash, or of a reference to an array or hash, always > returns one element for each index or key specified, regardless of > number of elements in the hash or array. > > Is that right?
Yes. Well, it isn’t my own proposition so much as it is the originally intended behaviour for list slices that was never implemented correctly, and I suggest that this be fixed. Show quoted text
> If so, could it be explicitly spelled out in the docs, more or less as > I've stated it above rather than using only examples.  I don't mind > the examples (they can help clarify the difference between a list and > an array in this context), but I would prefer that there also be some > verbiage specifying the rules as clearly as possible.
Isn’t the explanation I suggested (basically what the old version of the POD said, except slightly more explicit) for the exception sufficient? “As a special case, a slice of an empty literal list always yields the empty list.” To me that seems clear enough, combined with the examples. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
RT-Send-CC: perl5-porters [...] perl.org
On Fri Sep 07 08:48:54 2012, aristotle wrote: Show quoted text
> * John Wiersba <jrw32982@yahoo.com> [2012-09-07 06:00]:
> > Aristotle, let me see if I understand what you're proposing.
> > OK. >
> > The basic rule for array/list slices is: > > a) A slice returns one element for each index specified. If the index > > is out-of-bounds, then undef is returned for that element.
> > Yes… but you are aware that this is currently not the whole story, > right? That there already is a strange exception for literal lists? > (Which is what this ticket is about.) >
> > I believe that you're proposing amending that rule to allow a single > > exception: > > b) A slice of an empty list always returns no elements.  A list is > > specified when literal parentheses are used. > > c) There are no other exceptions.  In particular, a slice of an empty > > array returns one element for each index specified. > > d) A slice of a hash, or of a reference to an array or hash, always > > returns one element for each index or key specified, regardless of > > number of elements in the hash or array. > > > > Is that right?
> > Yes. Well, it isn’t my own proposition so much as it is the originally > intended behaviour for list slices that was never implemented correctly, > and I suggest that this be fixed. >
> > If so, could it be explicitly spelled out in the docs, more or less as > > I've stated it above rather than using only examples.  I don't mind > > the examples (they can help clarify the difference between a list and > > an array in this context), but I would prefer that there also be some > > verbiage specifying the rules as clearly as possible.
> > Isn’t the explanation I suggested (basically what the old version of the > POD said, except slightly more explicit) for the exception sufficient? > “As a special case, a slice of an empty literal list always yields the > empty list.” To me that seems clear enough, combined with the examples.
‘Empty literal list’ could easily be confused with ‘literal empty list’, meaning (), and not encompassing (each(...)). -- Father Chrysostomos
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Fri, 7 Sep 2012 10:17:54 -0700 (PDT)
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
From: John Wiersba <jrw32982 [...] yahoo.com>
Download (untitled) / with headers
text/plain 3.7k

Show quoted text

From: A. Pagaltzis via RT <perlbug-followup@perl.org>
To: jrw32982@yahoo.com
Sent: Friday, September 7, 2012 11:48 AM
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items

* John Wiersba <jrw32982@yahoo.com> [2012-09-07 06:00]:
> Aristotle, let me see if I understand what you're proposing.

OK.
Thanks!  :-)

Show quoted text
> The basic rule for array/list slices is:
> a) A slice returns one element for each index specified. If the index
>    is out-of-bounds, then undef is returned for that element.

Yes… but you are aware that this is currently not the whole story,
right? That there already is a strange exception for literal lists?
(Which is what this ticket is about.)
Yes, I know that's not the whole story.  But I believe that what I stated above is the basic rule, which is the foundation for the exceptions.

I'm aware that there is an existing behavior for lists (all types of lists) which is both unexpected and inconsistent.  The current behavior doesn't have anything to do specifically with empty lists, but instead with the slice indexes themselves and whether or not they're out of bounds.  The proposed behavior has to do with empty lists. 

Maybe I'm not understanding your use of the phrase "literal list".  Are there other kinds of lists besides literal ones?  I think you are using "literal list" to include constructs like (@a) and (fn(1, 2)), which don't appear to be literal to me.

Show quoted text
> I believe that you're proposing amending that rule to allow a single
> exception:
> b) A slice of an empty list always returns no elements.  A list is
>    specified when literal parentheses are used.
> c) There are no other exceptions.  In particular, a slice of an empty
>    array returns one element for each index specified.
> d) A slice of a hash, or of a reference to an array or hash, always
>    returns one element for each index or key specified, regardless of
>    number of elements in the hash or array.
>
> Is that right?

Yes. Well, it isn’t my own proposition so much as it is the originally
intended behaviour for list slices that was never implemented correctly,
and I suggest that this be fixed.
It would be great if it could be fixed to be more consistent and at least comprehensible to someone who doesn't write slices with out-of-bounds indexes very often.

Show quoted text
> If so, could it be explicitly spelled out in the docs, more or less as
> I've stated it above rather than using only examples.  I don't mind
> the examples (they can help clarify the difference between a list and
> an array in this context), but I would prefer that there also be some
> verbiage specifying the rules as clearly as possible.

Isn’t the explanation I suggested (basically what the old version of the
POD said, except slightly more explicit) for the exception sufficient?
“As a special case, a slice of an empty literal list always yields the
empty list.” To me that seems clear enough, combined with the examples.
There are a couple issues. 
1)
The word "literal" is confusing to me; are there other types of lists than "literal lists"?
2) This behavior is unexpected and inconsistent enough that I think it should be spelled out, rather than implied, that this behavior does not apply to arrays or hashes or references.  A
ll subscripted list forms, if they happen to compute the empty list, are treated differently than the subscripted array or hash or reference forms.

BTW, there seems to be an ambiguity as to whether or not @a = ( fn(1, 2) )[3] is a subscripted list or a list slice.  If fn returns the empty list, would @a be assigned an empty list or a list with the single element undef?

Show quoted text
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/
>
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 392b
On Fri Sep 07 10:18:39 2012, jrw32982@yahoo.com wrote: Show quoted text
> BTW, there seems to be an ambiguity as to whether or not @a = ( fn(1, > 2) )[3] is a subscripted list or a list slice.  If fn returns the > empty list, would @a be assigned an empty list or a list with the > single element undef?
There is no difference between a subscripted list and a list slice. -- Father Chrysostomos
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Fri, 7 Sep 2012 19:27:19 -0700 (PDT)
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
From: John Wiersba <jrw32982 [...] yahoo.com>


Show quoted text

From: Father Chrysostomos via RT <perlbug-followup@perl.org>
To: jrw32982@yahoo.com
Sent: Friday, September 7, 2012 7:10 PM
Subject: [perl #114498] List slice *sometimes* ignores undefined items

On Fri Sep 07 10:18:39 2012, jrw32982@yahoo.com wrote:
> BTW, there seems to be an ambiguity as to whether or not @a = ( fn(1,
>    2) )[3] is a subscripted list or a list slice.  If fn returns the
>    empty list, would @a be assigned an empty list or a list with the
>    single element undef?

There is no difference between a subscripted list and a list slice.
OK.  So, does @a = (@b)[3] behave the slice rules (i.e. if @b is empty, then @a is empty) or the normal subscript rules (i.e. @a is (undef))?  This should be clarified in the description of the slice rules and in the examples:

b) A slice of an empty list always returns no elements.  A list is specified when literal parentheses are used.  A subscripted list is the same as a list slice.

Examples:
@a = ();
@b = (2);
@c = (@a)[3];  # @c is empty
@d = (@b)[3];  # @d is (undef)

RT-Send-CC: perl5-porters [...] perl.org, pagaltzis [...] gmx.de
Download (untitled) / with headers
text/plain 636b
On Thu Sep 06 16:48:06 2012, aristotle wrote: Show quoted text
> * Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-09-03
01:20]: Show quoted text
> > So it seems the new behaviour was not actually implemented as > > intended.
> > Phew. I’m very glad to hear the current behaviour was not by design, > much less by Larry’s design… but is in fact an implementation bug. In > which case – yes please, let’s get rid of the Surprise! “feature”.
Attached is a patch, but I had to change some tests added by the patch from ticket #39882. I do think this should change, though. Would you be willing to write a doc patch? -- Father Chrysostomos
Download open_JGsho88U.txt
text/plain 2.5k
diff --git a/pp.c b/pp.c index f99c460..50dc46d 100644 --- a/pp.c +++ b/pp.c @@ -4772,7 +4772,6 @@ PP(pp_lslice) SV ** const lastlelem = PL_stack_base + POPMARK; SV ** const firstlelem = PL_stack_base + POPMARK + 1; SV ** const firstrelem = lastlelem + 1; - I32 is_something_there = FALSE; const I32 max = lastrelem - lastlelem; SV **lelem; @@ -4801,15 +4800,11 @@ PP(pp_lslice) if (ix < 0 || ix >= max) *lelem = &PL_sv_undef; else { - is_something_there = TRUE; if (!(*lelem = firstrelem[ix])) *lelem = &PL_sv_undef; } } - if (is_something_there) - SP = lastlelem; - else - SP = firstlelem - 1; + SP = lastlelem; RETURN; } diff --git a/t/op/list.t b/t/op/list.t index 87045fc..10637de 100644 --- a/t/op/list.t +++ b/t/op/list.t @@ -3,10 +3,10 @@ BEGIN { chdir 't' if -d 't'; @INC = qw(. ../lib); + require "test.pl"; } -require "test.pl"; -plan( tests => 64 ); +plan( tests => 66 ); @foo = (1, 2, 3, 4); cmp_ok($foo[0], '==', 1, 'first elem'); @@ -146,21 +146,28 @@ cmp_ok(join('',(1,2),3,(4,5)),'eq','12345','list (..).(..)'); my $size = scalar(()[1..1]); cmp_ok($size,'==','0','size nil'); + + $size = scalar(()=((1,2,3,4,5)[()])[2,3,4]); + is $size, 0, 'slice of empty list from complex expr is empty list'; + + @a = (1)[2,3,4]; + is "@{[ map $_//'undef', @a ]}", "undef undef undef", + 'slice beyond the end of non-empty list returns undefs'; } { # perl #39882 - sub test_zero_args { + sub test_two_args { my $test_name = shift; - is(scalar(@_), 0, $test_name); + is(scalar(@_), 2, $test_name); } - test_zero_args("simple list slice", (10,11)[2,3]); - test_zero_args("grepped list slice", grep(1, (10,11)[2,3])); - test_zero_args("sorted list slice", sort((10,11)[2,3])); - test_zero_args("assigned list slice", my @tmp = (10,11)[2,3]); - test_zero_args("do-returned list slice", do { (10,11)[2,3]; }); - test_zero_args("list literal slice", qw(a b)[2,3]); - test_zero_args("empty literal slice", qw()[2,3]); + test_two_args("simple list slice", (10,11)[2,3]); + test_two_args("grepped list slice", grep(1, (10,11)[2,3])); + test_two_args("sorted list slice", sort((10,11)[2,3])); + test_two_args("assigned list slice", my @tmp = (10,11)[2,3]); + test_two_args("do-returned list slice", do { (10,11)[2,3]; }); + test_two_args("list literal slice", qw(a b)[2,3]); + is (()=qw()[2,3], 0, "empty literal slice"); } {
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Thu, 20 Sep 2012 07:43:21 -0700 (PDT)
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
From: John Wiersba <jrw32982 [...] yahoo.com>
Download (untitled) / with headers
text/plain 3.9k
Yes, but never having done that before, it will take me a while to figure it out.  Let me test your patch first.  I have found perldoc.perl.org/perlrepository.html to help me work through the steps.  If I have questions getting things working, should I continue to use perlbug-followup@perl.org to get straightened out?

-- John

Show quoted text

From: Father Chrysostomos via RT <perlbug-followup@perl.org>
To: jrw32982@yahoo.com
Sent: Wednesday, September 19, 2012 12:58 PM
Subject: [perl #114498] List slice *sometimes* ignores undefined items

On Thu Sep 06 16:48:06 2012, aristotle wrote:
> * Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-09-03
01:20]:
> > So it seems the new behaviour was not actually implemented as
> > intended.
>
> Phew. I’m very glad to hear the current behaviour was not by design,
> much less by Larry’s design… but is in fact an implementation bug. In
> which case – yes please, let’s get rid of the Surprise! “feature”.

Attached is a patch, but I had to change some tests added by the patch
from ticket #39882.

I do think this should change, though.

Would you be willing to write a doc patch?

--

Father Chrysostomos


diff --git a/pp.c b/pp.c
index f99c460..50dc46d 100644
--- a/pp.c
+++ b/pp.c
@@ -4772,7 +4772,6 @@ PP(pp_lslice)
    SV ** const lastlelem = PL_stack_base + POPMARK;
    SV ** const firstlelem = PL_stack_base + POPMARK + 1;
    SV ** const firstrelem = lastlelem + 1;
-    I32 is_something_there = FALSE;

    const I32 max = lastrelem - lastlelem;
    SV **lelem;
@@ -4801,15 +4800,11 @@ PP(pp_lslice)
    if (ix < 0 || ix >= max)
        *lelem = &PL_sv_undef;
    else {
-        is_something_there = TRUE;
        if (!(*lelem = firstrelem[ix]))
        *lelem = &PL_sv_undef;
    }
    }
-    if (is_something_there)
-    SP = lastlelem;
-    else
-    SP = firstlelem - 1;
+    SP = lastlelem;
    RETURN;
}

diff --git a/t/op/list.t b/t/op/list.t
index 87045fc..10637de 100644
--- a/t/op/list.t
+++ b/t/op/list.t
@@ -3,10 +3,10 @@
BEGIN {
    chdir 't' if -d 't';
    @INC = qw(. ../lib);
+    require "test.pl";
}

-require "test.pl";
-plan( tests => 64 );
+plan( tests => 66 );

@foo = (1, 2, 3, 4);
cmp_ok($foo[0], '==', 1, 'first elem');
@@ -146,21 +146,28 @@ cmp_ok(join('',(1,2),3,(4,5)),'eq','12345','list (..).(..)');

    my $size = scalar(()[1..1]);
    cmp_ok($size,'==','0','size nil');
+
+    $size = scalar(()=((1,2,3,4,5)[()])[2,3,4]);
+    is $size, 0, 'slice of empty list from complex expr is empty list';
+
+    @a = (1)[2,3,4];
+    is "@{[ map $_//'undef', @a ]}", "undef undef undef",
+      'slice beyond the end of non-empty list returns undefs';
}

{
    # perl #39882
-    sub test_zero_args {
+    sub test_two_args {
        my $test_name = shift;
-        is(scalar(@_), 0, $test_name);
+        is(scalar(@_), 2, $test_name);
    }
-    test_zero_args("simple list slice",      (10,11)[2,3]);
-    test_zero_args("grepped list slice",    grep(1, (10,11)[2,3]));
-    test_zero_args("sorted list slice",      sort((10,11)[2,3]));
-    test_zero_args("assigned list slice",    my @tmp = (10,11)[2,3]);
-    test_zero_args("do-returned list slice", do { (10,11)[2,3]; });
-    test_zero_args("list literal slice",    qw(a b)[2,3]);
-    test_zero_args("empty literal slice",    qw()[2,3]);
+    test_two_args("simple list slice",      (10,11)[2,3]);
+    test_two_args("grepped list slice",    grep(1, (10,11)[2,3]));
+    test_two_args("sorted list slice",      sort((10,11)[2,3]));
+    test_two_args("assigned list slice",    my @tmp = (10,11)[2,3]);
+    test_two_args("do-returned list slice", do { (10,11)[2,3]; });
+    test_two_args("list literal slice",    qw(a b)[2,3]);
+    is (()=qw()[2,3], 0, "empty literal slice");
}

{


Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Thu, 20 Sep 2012 09:02:43 -0700 (PDT)
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
From: John Wiersba <jrw32982 [...] yahoo.com>
Download (untitled) / with headers
text/plain 4.7k
BTW, I notice that http://perldoc.perl.org/perlrepository.html shows up as being in the 5.12 documentation, but not in 5.16.  Do you know why that is?  This looks like very useful information, but it's not in the latest perl release.

Also, your patch is against blead, right?  Or should I test this against some other branch?

Thanks!
-- John

Show quoted text

From: John Wiersba <jrw32982@yahoo.com>
To: "perlbug-followup@perl.org" <perlbug-followup@perl.org>
Sent: Thursday, September 20, 2012 10:43 AM
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items

Yes, but never having done that before, it will take me a while to figure it out.  Let me test your patch first.  I have found perldoc.perl.org/perlrepository.html to help me work through the steps.  If I have questions getting things working, should I continue to use perlbug-followup@perl.org to get straightened out?

-- John


From: Father Chrysostomos via RT <perlbug-followup@perl.org>
To: jrw32982@yahoo.com
Sent: Wednesday, September 19, 2012 12:58 PM
Subject: [perl #114498] List slice *sometimes* ignores undefined items

On Thu Sep 06 16:48:06 2012, aristotle wrote:
> * Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-09-03
01:20]:
> > So it seems the new behaviour was not actually implemented as
> > intended.
>
> Phew. I’m very glad to hear the current behaviour was not by design,
> much less by Larry’s design… but is in fact an implementation bug. In
> which case – yes please, let’s get rid of the Surprise! “feature”.

Attached is a patch, but I had to change some tests added by the patch
from ticket #39882.

I do think this should change, though.

Would you be willing to write a doc patch?

--

Father Chrysostomos


diff --git a/pp.c b/pp.c
index f99c460..50dc46d 100644
--- a/pp.c
+++ b/pp.c
@@ -4772,7 +4772,6 @@ PP(pp_lslice)
    SV ** const lastlelem = PL_stack_base + POPMARK;
    SV ** const firstlelem = PL_stack_base + POPMARK + 1;
    SV ** const firstrelem = lastlelem + 1;
-    I32 is_something_there = FALSE;

    const I32 max = lastrelem - lastlelem;
    SV **lelem;
@@ -4801,15 +4800,11 @@ PP(pp_lslice)
    if (ix < 0 || ix >= max)
        *lelem = &PL_sv_undef;
    else {
-        is_something_there = TRUE;
        if (!(*lelem = firstrelem[ix]))
        *lelem = &PL_sv_undef;
    }
    }
-    if (is_something_there)
-    SP = lastlelem;
-    else
-    SP = firstlelem - 1;
+    SP = lastlelem;
    RETURN;
}

diff --git a/t/op/list.t b/t/op/list.t
index 87045fc..10637de 100644
--- a/t/op/list.t
+++ b/t/op/list.t
@@ -3,10 +3,10 @@
BEGIN {
    chdir 't' if -d 't';
    @INC = qw(. ../lib);
+    require "test.pl";
}

-require "test.pl";
-plan( tests => 64 );
+plan( tests => 66 );

@foo = (1, 2, 3, 4);
cmp_ok($foo[0], '==', 1, 'first elem');
@@ -146,21 +146,28 @@ cmp_ok(join('',(1,2),3,(4,5)),'eq','12345','list (..).(..)');

    my $size = scalar(()[1..1]);
    cmp_ok($size,'==','0','size nil');
+
+    $size = scalar(()=((1,2,3,4,5)[()])[2,3,4]);
+    is $size, 0, 'slice of empty list from complex expr is empty list';
+
+    @a = (1)[2,3,4];
+    is "@{[ map $_//'undef', @a ]}", "undef undef undef",
+      'slice beyond the end of non-empty list returns undefs';
}

{
    # perl #39882
-    sub test_zero_args {
+    sub test_two_args {
        my $test_name = shift;
-        is(scalar(@_), 0, $test_name);
+        is(scalar(@_), 2, $test_name);
    }
-    test_zero_args("simple list slice",      (10,11)[2,3]);
-    test_zero_args("grepped list slice",    grep(1, (10,11)[2,3]));
-    test_zero_args("sorted list slice",      sort((10,11)[2,3]));
-    test_zero_args("assigned list slice",    my @tmp = (10,11)[2,3]);
-    test_zero_args("do-returned list slice", do { (10,11)[2,3]; });
-    test_zero_args("list literal slice",    qw(a b)[2,3]);
-    test_zero_args("empty literal slice",    qw()[2,3]);
+    test_two_args("simple list slice",      (10,11)[2,3]);
+    test_two_args("grepped list slice",    grep(1, (10,11)[2,3]));
+    test_two_args("sorted list slice",      sort((10,11)[2,3]));
+    test_two_args("assigned list slice",    my @tmp = (10,11)[2,3]);
+    test_two_args("do-returned list slice", do { (10,11)[2,3]; });
+    test_two_args("list literal slice",    qw(a b)[2,3]);
+    is (()=qw()[2,3], 0, "empty literal slice");
}

{




CC: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Thu, 20 Sep 2012 11:05:13 -0500
To: John Wiersba <jrw32982 [...] yahoo.com>
From: Jesse Luehrs <doy [...] tozt.net>
Download (untitled) / with headers
text/plain 393b
On Thu, Sep 20, 2012 at 09:02:43AM -0700, John Wiersba wrote: Show quoted text
> BTW, I notice that http://perldoc.perl.org/perlrepository.html shows > up as being in the 5.12 documentation, but not in 5.16.  Do you know > why that is?  This looks like very useful information, but it's not in > the latest perl release.
All the information in perlrepository was moved to either perlhack or perlgit. -doy
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 448b
On Thu Sep 20 08:07:24 2012, jrw32982@yahoo.com wrote: Show quoted text
> Yes, but never having done that before, it will take me a while to > figure it out.  Let me test your patch first.  I have found > perldoc.perl.org/perlrepository.html to help me work through the > steps.  If I have questions getting things working, should I > continue to use perlbug-followup@perl.org to get straightened out?
Yes, that’s fine. -- Father Chrysostomos
CC: Jesse Luehrs <doy [...] tozt.net>
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Thu, 20 Sep 2012 09:58:37 -0700 (PDT)
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
From: John Wiersba <jrw32982 [...] yahoo.com>
Download (untitled) / with headers
text/plain 2.6k
Thanks, Jesse.

It see the perlhack page on perldoc.perl.org, but that site can't find any perlgit page.  I did find some links to perlgit within perlhack page, but unfortunately they're broken.  I was able to run "man perlgit" after building the blead source and find the perlgit man page that was built from blead.  But since I used git to get the repository to be built, it would have been useful to have been able to see perlgit on perldoc.perl.org before doing that.

Also, when I built perl from blead, for some reason, it didn't build perldoc.  I built perl like this:

mkdir ~/perl ~/perl/src
git clone http://perl5.git.perl.org/perl.git ~/perl/src
cd ~/perl/src
git branch list-slice
git checkout list-slice

Then, in order to get Configure to work with -des, I used:

./Configure -des -Dusedevel -Dprefix=~/perl
make
make test
make install

At this point, I have ~/perl/bin filled with:
a2p5.17.5             h2ph5.17.5        piconv5.17.5      psed5.17.5
c2ph5.17.5            h2xs5.17.5        pl2pm5.17.5       pstruct5.17.5
config_data5.17.5     instmodsh5.17.5   pod2html5.17.5    ptar5.17.5
corelist5.17.5        json_pp5.17.5     pod2latex5.17.5   ptardiff5.17.5
cpan2dist5.17.5       libnetcfg5.17.5   pod2man5.17.5     ptargrep5.17.5
cpan5.17.5            perl5.17.5        pod2text5.17.5    s2p5.17.5
cpanp-run-perl5.17.5  perlbug5.17.5     pod2usage5.17.5   shasum5.17.5
cpanp5.17.5           perldoc5.17.5     podchecker5.17.5  splain5.17.5
enc2xs5.17.5          perlivp5.17.5     podselect5.17.5   xsubpp5.17.5
find2perl5.17.5       perlthanks5.17.5  prove5.17.5       zipdetails5.17.5

but no perldoc in there.  Is that because I built the development release? 

One further question: in order to test Father's patch, should I have built the development (5.17) release, or should I have built 5.16?

Thanks!
-- John

Show quoted text

From: Jesse Luehrs <doy@tozt.net>
To: John Wiersba <jrw32982@yahoo.com>
Cc: "perlbug-followup@perl.org" <perlbug-followup@perl.org>
Sent: Thursday, September 20, 2012 12:05 PM
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items

On Thu, Sep 20, 2012 at 09:02:43AM -0700, John Wiersba wrote:
> BTW, I notice that http://perldoc.perl.org/perlrepository.html shows
> up as being in the 5.12 documentation, but not in 5.16.  Do you know
> why that is?  This looks like very useful information, but it's not in
> the latest perl release.

All the information in perlrepository was moved to either perlhack or
perlgit.

-doy


RT-Send-CC: perl5-porters [...] perl.org
Sorry you got no response. I missed this message. On Thu Sep 20 09:59:19 2012, jrw32982@yahoo.com wrote: Show quoted text
> Thanks, Jesse. > > It see the perlhack page on perldoc.perl.org, but > that site can't find any perlgit page. I did find some links to > perlgit > within perlhack page, but unfortunately they're broken. I was able > to run > "man perlgit" after building the blead source and find the perlgit man > page that was built from blead. But since I used git to > get the repository to be built, it would have been useful to have been > able to > see perlgit on perldoc.perl.org before doing that. > > Also, when I built perl from blead, for some reason, it didn't build > perldoc. I built perl like this: > > mkdir ~/perl ~/perl/src > git clone http://perl5.git.perl.org/perl.git ~/perl/src > cd ~/perl/src > git branch list-slice > git checkout list-slice > > Then, in order to get Configure to work with -des, I used: > > ./Configure -des -Dusedevel -Dprefix=~/perl > make > make test > make install > > At this point, I have ~/perl/bin filled with: > a2p5.17.5 h2ph5.17.5 piconv5.17.5 psed5.17.5 > c2ph5.17.5 h2xs5.17.5 pl2pm5.17.5 > pstruct5.17.5 > config_data5.17.5 instmodsh5.17.5 pod2html5.17.5 ptar5.17.5 > corelist5.17.5 json_pp5.17.5 pod2latex5.17.5 > ptardiff5.17.5 > cpan2dist5.17.5 libnetcfg5.17.5 pod2man5.17.5 > ptargrep5.17.5 > cpan5.17.5 perl5.17.5 pod2text5.17.5 s2p5.17.5 > cpanp-run-perl5.17.5 perlbug5.17.5 pod2usage5.17.5 shasum5.17.5 > cpanp5.17.5 perldoc5.17.5 podchecker5.17.5 splain5.17.5
------------------------^^^^^^^^^^^^^ Show quoted text
> enc2xs5.17.5 perlivp5.17.5 podselect5.17.5 xsubpp5.17.5 > find2perl5.17.5 perlthanks5.17.5 prove5.17.5 > zipdetails5.17.5 > > but no perldoc in there. Is that because I built the development > release?
See my crude ASCII arrow. :-) Show quoted text
> > One further question: in order to test Father's patch, > should I have built the development (5.17) release, or should I have > built 5.16?
The latest snapshot of the development (blead) branch is the best thing to use. See <http://perl5.git.perl.org/perl.git/shortlog/refs/heads/blead>. If you use rsync, this branch is called perl-current. Show quoted text
> > Thanks! > -- John > > > >
> >________________________________ > > From: Jesse Luehrs <doy@tozt.net> > >To: John Wiersba <jrw32982@yahoo.com> > >Cc: "perlbug-followup@perl.org" <perlbug-followup@perl.org> > >Sent: Thursday, September 20, 2012 12:05 PM > >Subject: Re: [perl #114498] List slice *sometimes* ignores undefined
> items
> > > >On Thu, Sep 20, 2012 at 09:02:43AM -0700, John Wiersba wrote:
> shows
> >> up as being in the 5.12 documentation, but not in 5.16. Do you
> know
> >> why that is? This looks like very useful information, but it's not
> in
> >> the latest perl release.
> > > >All the information in perlrepository was moved to either perlhack or > >perlgit. > > > >-doy > > > > > >
-- Father Chrysostomos
CC: perlbug-followup [...] perl.org
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Thu, 10 Oct 2013 07:36:02 +0200
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 690b
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-09-19 19:00]: Show quoted text
> Would you be willing to write a doc patch?
Sorry it took so long to get around to this. In the 2 weeks you needed to produce a patch, the details of the matter slipped my mind entirely, and going back over a long thread to refamiliarise myself with something half-remembered is dreadful work to me, so in the end I only got back to it once I lost all recollection of the matter and could read it afresh. How’s the attached look to you? John? -- *AUTOLOAD=*_;sub _{s/..([^:]*)$/()[print$1,(",$\/"," ")[defined wantarray]]/e;$_} &Just->another->Perl->hack; #Aristotle Pagaltzis // <http://plasmasturm.org/>

Message body is not shown because sender requested not to inline it.

Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Thu, 10 Oct 2013 10:10:56 -0700 (PDT)
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
From: John Wiersba <jrw32982 [...] yahoo.com>
Download (untitled) / with headers
text/plain 4.1k
Thanks for working on this, Aristotle!

I don't think what you wrote is quite right, in that it implies that the special exception is only empty lists.  But really, the exception is not the contents of the list (whether or not it's empty), but the "quality" of the indexes (whether or not they are all in-bounds, or some of them are out-of-bounds).

$ perl -le 'print "<$_>" for ("x")[1,2]'
$ perl -le 'print "<$_>" for ("x")[0,1,2]'
<x>
<>
<>


So, this unusual behavior happens not only for empty lists, but for any list where all the indexes are out of bounds.

Here are my notes trying to explain this behavior to myself:

   - An array (or hash) slice always returns one item for each index
     specified, returning undef for each out-of-bounds index.
   - Like an array slice, a list slice which contains at least one index
     which is not out-of-bounds returns one item for each index specified,
     returning undef for each out-of-bounds index.
   - However, unlike an array slice, a list slice where every specified
     index is out-of bounds returns an empty list.

This behavior is so weird (inconsistent, unexpected) that I don't think examples alone will do it justice.  It has to be written out in words, something similar to your explanation for empty lists, or my wording above.

Show quoted text

From: Aristotle Pagaltzis via RT <perlbug-followup@perl.org>
To: jrw32982@yahoo.com
Sent: Thursday, October 10, 2013 1:36 AM
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items

* Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-09-19 19:00]:
> Would you be willing to write a doc patch?

Sorry it took so long to get around to this. In the 2 weeks you needed
to produce a patch, the details of the matter slipped my mind entirely,
and going back over a long thread to refamiliarise myself with something
half-remembered is dreadful work to me, so in the end I only got back to
it once I lost all recollection of the matter and could read it afresh.

How’s the attached look to you? John?

--
*AUTOLOAD=*_;sub _{s/..([^:]*)$/()[print$1,(",$\/"," ")[defined wantarray]]/e;$_}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // <http://plasmasturm.org/>


From 385013a1eff5855e500f7f6a2657260f0673cf19 Mon Sep 17 00:00:00 2001
Message-Id: <385013a1eff5855e500f7f6a2657260f0673cf19.1381382810.git.pagaltzis@gmx.de>
From: Aristotle Pagaltzis <pagaltzis@gmx.de>
Date: Thu, 10 Oct 2013 07:24:10 +0200
Subject: [PATCH] perldata: document corrected list slicing behaviour

---
pod/perldata.pod | 25 ++++++++++---------------
1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/pod/perldata.pod b/pod/perldata.pod
index 254884d..7dc4cde 100644
--- a/pod/perldata.pod
+++ b/pod/perldata.pod
@@ -879,26 +879,21 @@ values of the array or hash.
        s/(\w+)/\u\L$1/g;  # "titlecase" words
    }

-A slice of an empty list is still an empty list.  Thus:
+As a special exception, when you slice a list (but not an array or a hash),
+if the list evaluates to empty, then taking a slice of that empty list will
+always yield the empty list in turn.  Thus:

-    @a = ()[1,0];          # @a has no elements
-    @b = (@a)[0,1];        # @b has no elements
-
-But:
-
-    @a = (1)[1,0];          # @a has two elements
-    @b = (1,undef)[1,0,2];  # @b has three elements
-
-More generally, a slice yields the empty list if it indexes only
-beyond the end of a list:
-
-    @a = (1)[  1,2];        # @a has no elements
-    @b = (1)[0,1,2];        # @b has three elements
+    @a = ()[0,1];          # @a has no elements
+    @b = (@a)[0,1];        # @b has no elements
+    @c = (sub{}->())[0,1]; # @c has no elements
+    @d = ('a','b')[0,1];  # @d has two elements
+    @e = (@d)[0,1,8,9];    # @e has four elements
+    @f = (@d)[8,9];        # @f has two elements

This makes it easy to write loops that terminate when a null list
is returned:

-    while ( ($home, $user) = (getpwent)[7,0]) {
+    while ( ($home, $user) = (getpwent)[7,0] ) {
        printf "%-8s %s\n", $user, $home;
    }

--
1.8.3.4



CC: perlbug-followup [...] perl.org
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Thu, 10 Oct 2013 20:18:29 +0200
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 835b
* John Wiersba <jrw32982@yahoo.com> [2013-10-10 19:15]: Show quoted text
> I don't think what you wrote is quite right, in that it implies that > the special exception is only empty lists.  But really, the exception > is not the contents of the list (whether or not it's empty), but the > "quality" of the indexes (whether or not they are all in-bounds, or > some of them are out-of-bounds). > > $ perl -le 'print "<$_>" for ("x")[1,2]' > $ perl -le 'print "<$_>" for ("x")[0,1,2]' > <x> > <> > <>
Yes, that is how it works now. I already patched the documentation to say that. But this doc patch is for the patch that FatherC submitted, which, as I understand it, implements the originally intended semantics – where slicing *only* an empty list yields an empty list. Does it not? Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Fri, 11 Oct 2013 12:00:43 -0700 (PDT)
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
From: John Wiersba <jrw32982 [...] yahoo.com>
Download (untitled) / with headers
text/plain 1.1k
I just tried my example below on 5.19.5 and it works the same way as I show below (the same as 5.10 - 5.18).


Show quoted text

From: Aristotle Pagaltzis via RT <perlbug-followup@perl.org>
To: jrw32982@yahoo.com
Sent: Thursday, October 10, 2013 2:19 PM
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items

* John Wiersba <jrw32982@yahoo.com> [2013-10-10 19:15]:
> I don't think what you wrote is quite right, in that it implies that
> the special exception is only empty lists.  But really, the exception
> is not the contents of the list (whether or not it's empty), but the
> "quality" of the indexes (whether or not they are all in-bounds, or
> some of them are out-of-bounds).
>
> $ perl -le 'print "<$_>" for ("x")[1,2]'
> $ perl -le 'print "<$_>" for ("x")[0,1,2]'
> <x>
> <>
> <>

Yes, that is how it works now. I already patched the documentation to
say that.

But this doc patch is for the patch that FatherC submitted, which, as
I understand it, implements the originally intended semantics – where
slicing *only* an empty list yields an empty list.

Does it not?

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>




CC: perlbug-followup [...] perl.org
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Sat, 12 Oct 2013 05:10:12 +0200
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 1.4k
* John Wiersba <jrw32982@yahoo.com> [2013-10-11 21:05]: Show quoted text
> * Aristotle Pagaltzis <pagaltzis@gmx.de> [2013-10-10 20:20]:
> > * John Wiersba <jrw32982@yahoo.com> [2013-10-10 19:15]:
> > > I don't think what you wrote is quite right, in that it implies > > > that the special exception is only empty lists.  But really, the > > > exception is not the contents of the list (whether or not it's > > > empty), but the "quality" of the indexes (whether or not they are > > > all in-bounds, or some of them are out-of-bounds). > > > > > > $ perl -le 'print "<$_>" for ("x")[1,2]' > > > $ perl -le 'print "<$_>" for ("x")[0,1,2]' > > > <x> > > > <> > > > <>
> > > > Yes, that is how it works now. I already patched the documentation > > to say that. > > > > But this doc patch is for the patch that FatherC submitted, which, > > as I understand it, implements the originally intended semantics > > – where slicing *only* an empty list yields an empty list. > > > > Does it not?
> > I just tried my example below on 5.19.5 and it works the same way as > I show below (the same as 5.10 - 5.18).
Yes, FC’s patch has not been applied, so any released version of perl necessarily still works in that buggy way. We went over this already. My question was whether you feel the phrasing I proposed conveys the non-buggy semantics under FC’s patch clearly. Tell me something about that please? -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Sat, 12 Oct 2013 06:20:20 -0700 (PDT)
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
From: John Wiersba <jrw32982 [...] yahoo.com>
Download (untitled) / with headers
text/plain 1.9k
Yes, I think your doc patch is clear, especially because it used the words "special exception".  It might also be helpful to include some example for contrast showing differing behavior with array and hash slices vs a list slice, since the distinction between "list" and "array" is not always clear.


Show quoted text

From: Aristotle Pagaltzis via RT <perlbug-followup@perl.org>
To: jrw32982@yahoo.com
Sent: Friday, October 11, 2013 11:11 PM
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items

* John Wiersba <jrw32982@yahoo.com> [2013-10-11 21:05]:
> * Aristotle Pagaltzis <pagaltzis@gmx.de> [2013-10-10 20:20]:
> > * John Wiersba <jrw32982@yahoo.com> [2013-10-10 19:15]:
> > > I don't think what you wrote is quite right, in that it implies
> > > that the special exception is only empty lists.  But really, the
> > > exception is not the contents of the list (whether or not it's
> > > empty), but the "quality" of the indexes (whether or not they are
> > > all in-bounds, or some of them are out-of-bounds).
> > >
> > > $ perl -le 'print "<$_>" for ("x")[1,2]'
> > > $ perl -le 'print "<$_>" for ("x")[0,1,2]'
> > > <x>
> > > <>
> > > <>
> >
> > Yes, that is how it works now. I already patched the documentation
> > to say that.
> >
> > But this doc patch is for the patch that FatherC submitted, which,
> > as I understand it, implements the originally intended semantics
> > – where slicing *only* an empty list yields an empty list.
> >
> > Does it not?
>
> I just tried my example below on 5.19.5 and it works the same way as
> I show below (the same as 5.10 - 5.18).

Yes, FC’s patch has not been applied, so any released version of perl
necessarily still works in that buggy way. We went over this already.

My question was whether you feel the phrasing I proposed conveys the
non-buggy semantics under FC’s patch clearly. Tell me something about
that please?

--
Aristotle Pagaltzis // <http://plasmasturm.org/>




From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
To: perl5-porters [...] perl.org
Date: Tue, 11 Mar 2014 08:19:34 +0100
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Download (untitled) / with headers
text/plain 356b
* Aristotle Pagaltzis <pagaltzis@gmx.de> [2013-10-10 07:40]: Show quoted text
> * Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-09-19 19:00]:
> > Would you be willing to write a doc patch?
> > Sorry it took so long to get around to this.
Bump. It would be nice for this to make it into 5.20. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Date: Sun, 11 May 2014 12:10:08 +0200
To: perl5-porters [...] perl.org
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 194b
* Aristotle Pagaltzis <pagaltzis@gmx.de> [2014-03-11 08:20]: Show quoted text
> Bump. > > It would be nice for this to make it into 5.20.
Maybe if I try with the patch inlined it’ll get comments quicker. :-)
From 385013a1eff5855e500f7f6a2657260f0673cf19 Mon Sep 17 00:00:00 2001 Message-Id: <385013a1eff5855e500f7f6a2657260f0673cf19.1381382810.git.pagaltzis@gmx.de> From: Aristotle Pagaltzis <pagaltzis@gmx.de> Date: Thu, 10 Oct 2013 07:24:10 +0200 Subject: [PATCH] perldata: document corrected list slicing behaviour --- pod/perldata.pod | 25 ++++++++++--------------- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/pod/perldata.pod b/pod/perldata.pod index 254884d..7dc4cde 100644 --- a/pod/perldata.pod +++ b/pod/perldata.pod @@ -879,26 +879,21 @@ values of the array or hash. s/(\w+)/\u\L$1/g; # "titlecase" words } -A slice of an empty list is still an empty list. Thus: +As a special exception, when you slice a list (but not an array or a hash), +if the list evaluates to empty, then taking a slice of that empty list will +always yield the empty list in turn. Thus: - @a = ()[1,0]; # @a has no elements - @b = (@a)[0,1]; # @b has no elements - -But: - - @a = (1)[1,0]; # @a has two elements - @b = (1,undef)[1,0,2]; # @b has three elements - -More generally, a slice yields the empty list if it indexes only -beyond the end of a list: - - @a = (1)[ 1,2]; # @a has no elements - @b = (1)[0,1,2]; # @b has three elements + @a = ()[0,1]; # @a has no elements + @b = (@a)[0,1]; # @b has no elements + @c = (sub{}->())[0,1]; # @c has no elements + @d = ('a','b')[0,1]; # @d has two elements + @e = (@d)[0,1,8,9]; # @e has four elements + @f = (@d)[8,9]; # @f has two elements This makes it easy to write loops that terminate when a null list is returned: - while ( ($home, $user) = (getpwent)[7,0]) { + while ( ($home, $user) = (getpwent)[7,0] ) { printf "%-8s %s\n", $user, $home; } -- 1.8.3.4
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Date: Sun, 11 May 2014 12:27:53 +0200
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 327b
Hi perl5-porters, * Aristotle Pagaltzis <pagaltzis@gmx.de> [2014-05-11 12:15]: Show quoted text
> * Aristotle Pagaltzis <pagaltzis@gmx.de> [2014-03-11 08:20]:
> > Bump. > > > > It would be nice for this to make it into 5.20.
> > Maybe if I try with the patch inlined it’ll get comments quicker. :-)
Also now as a patience diff, much nicer.
From 385013a1eff5855e500f7f6a2657260f0673cf19 Mon Sep 17 00:00:00 2001 Message-Id: <385013a1eff5855e500f7f6a2657260f0673cf19.1381382810.git.pagaltzis@gmx.de> From: Aristotle Pagaltzis <pagaltzis@gmx.de> Date: Thu, 10 Oct 2013 07:24:10 +0200 Subject: [PATCH] perldata: document corrected list slicing behaviour --- pod/perldata.pod | 25 ++++++++++--------------- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/pod/perldata.pod b/pod/perldata.pod index 254884d..7dc4cde 100644 --- a/pod/perldata.pod +++ b/pod/perldata.pod @@ -879,26 +879,21 @@ values of the array or hash. s/(\w+)/\u\L$1/g; # "titlecase" words } - -A slice of an empty list is still an empty list. Thus: - - @a = ()[1,0]; # @a has no elements - @b = (@a)[0,1]; # @b has no elements - -But: - - @a = (1)[1,0]; # @a has two elements - @b = (1,undef)[1,0,2]; # @b has three elements - -More generally, a slice yields the empty list if it indexes only -beyond the end of a list: - - @a = (1)[ 1,2]; # @a has no elements - @b = (1)[0,1,2]; # @b has three elements + +As a special exception, when you slice a list (but not an array or a hash), +if the list evaluates to empty, then taking a slice of that empty list will +always yield the empty list in turn. Thus: + + @a = ()[0,1]; # @a has no elements + @b = (@a)[0,1]; # @b has no elements + @c = (sub{}->())[0,1]; # @c has no elements + @d = ('a','b')[0,1]; # @d has two elements + @e = (@d)[0,1,8,9]; # @e has four elements + @f = (@d)[8,9]; # @f has two elements This makes it easy to write loops that terminate when a null list is returned: - while ( ($home, $user) = (getpwent)[7,0]) { + while ( ($home, $user) = (getpwent)[7,0] ) { printf "%-8s %s\n", $user, $home; } -- 1.8.3.4
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
To: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Date: Mon, 12 May 2014 10:46:39 -0400
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 114b
Aristotle, if you have fact-checked the changes against bleadperl, please feel free to apply them ASAP. -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

Date: Tue, 13 May 2014 08:59:54 -0400
To: Father Chrysostomos via RT <perlbug-followup [...] perl.org>
Subject: Re: Fw: [perl #114498] List slice *sometimes* ignores undefined items
From: John Wiersba <jrw32982 [...] gmail.com>
Download (untitled) / with headers
text/plain 3.3k
See my reply below.  It bounced when sending it from yahoo.


On Tue, May 13, 2014 at 8:52 AM, John Wiersba <jrw32982@yahoo.com> wrote:
Show quoted text

----- Forwarded Message -----
From: John Wiersba <jrw32982@yahoo.com>
To: "perlbug-followup@perl.org" <perlbug-followup@perl.org>
Sent: Tuesday, May 13, 2014 8:42 AM
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items

Thanks for this, Aristotle.  I would consider adding one more contrasting example:

+    @b = (@a)[0,1];        # @b has no elements
+    @b = @a[0,1];        # @b has two elements   # <= this is new

Also, you might consider adding a note that this is a change in behavior from perls < 5.20, where a slice of an nonempty list would yield an empty list when all the indexes were out of bounds.

-- John


From: Aristotle Pagaltzis via RT <perlbug-followup@perl.org>
To: jrw32982@yahoo.com
Sent: Sunday, May 11, 2014 6:28 AM
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items

Hi perl5-porters,

* Aristotle Pagaltzis <pagaltzis@gmx.de> [2014-05-11 12:15]:
> * Aristotle Pagaltzis <pagaltzis@gmx.de> [2014-03-11 08:20]:
> > Bump.
> >
> > It would be nice for this to make it into 5.20.
>
> Maybe if I try with the patch inlined it’ll get comments quicker. :-)

Also now as a patience diff, much nicer.


From 385013a1eff5855e500f7f6a2657260f0673cf19 Mon Sep 17 00:00:00 2001
Message-Id: <385013a1eff5855e500f7f6a2657260f0673cf19.1381382810.git.pagaltzis@gmx.de>
From: Aristotle Pagaltzis <pagaltzis@gmx.de>
Date: Thu, 10 Oct 2013 07:24:10 +0200
Subject: [PATCH] perldata: document corrected list slicing behaviour

---
pod/perldata.pod | 25 ++++++++++---------------
1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/pod/perldata.pod b/pod/perldata.pod
index 254884d..7dc4cde 100644
--- a/pod/perldata.pod
+++ b/pod/perldata.pod
@@ -879,26 +879,21 @@ values of the array or hash.
        s/(\w+)/\u\L$1/g;  # "titlecase" words
    }
-
-A slice of an empty list is still an empty list.  Thus:
-
-    @a = ()[1,0];          # @a has no elements
-    @b = (@a)[0,1];        # @b has no elements
-
-But:
-
-    @a = (1)[1,0];          # @a has two elements
-    @b = (1,undef)[1,0,2];  # @b has three elements
-
-More generally, a slice yields the empty list if it indexes only
-beyond the end of a list:
-
-    @a = (1)[  1,2];        # @a has no elements
-    @b = (1)[0,1,2];        # @b has three elements
+
+As a special exception, when you slice a list (but not an array or a hash),
+if the list evaluates to empty, then taking a slice of that empty list will
+always yield the empty list in turn.  Thus:
+
+    @a = ()[0,1];          # @a has no elements
+    @b = (@a)[0,1];        # @b has no elements
+    @c = (sub{}->())[0,1]; # @c has no elements
+    @d = ('a','b')[0,1];  # @d has two elements
+    @e = (@d)[0,1,8,9];    # @e has four elements
+    @f = (@d)[8,9];        # @f has two elements

This makes it easy to write loops that terminate when a null list
is returned:

-    while ( ($home, $user) = (getpwent)[7,0]) {
+    while ( ($home, $user) = (getpwent)[7,0] ) {
        printf "%-8s %s\n", $user, $home;
    }

--
1.8.3.4






From: Karl Williamson <public [...] khwilliamson.com>
Date: Mon, 16 Jun 2014 14:41:53 -0600
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
To: Aristotle Pagaltzis <pagaltzis [...] gmx.de>, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 430b
On 05/11/2014 04:27 AM, Aristotle Pagaltzis wrote: Show quoted text
> Hi perl5-porters, > > * Aristotle Pagaltzis <pagaltzis@gmx.de> [2014-05-11 12:15]:
>> * Aristotle Pagaltzis <pagaltzis@gmx.de> [2014-03-11 08:20]:
>>> Bump. >>> >>> It would be nice for this to make it into 5.20.
>> >> Maybe if I try with the patch inlined it’ll get comments quicker. :-)
> > Also now as a patience diff, much nicer. >
What is the status on applying this?
To: perl5-porters [...] perl.org
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Date: Tue, 17 Jun 2014 00:26:06 +0200
Download (untitled) / with headers
text/plain 472b
* Karl Williamson <public@khwilliamson.com> [2014-06-16 22:45]: Show quoted text
> What is the status on applying this?
The underlying core patch has not been applied and so this doc patch cannot be either. I found that FC’s patch no longer applies cleanly and made an ad-hoc attempt to rebase it, but I ran out of time and put it on the back burner. And there it sits for now, on my todo list, along with my doc patch. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 590b
On Mon Jun 16 15:26:27 2014, aristotle wrote: Show quoted text
> * Karl Williamson <public@khwilliamson.com> [2014-06-16 22:45]:
> > What is the status on applying this?
> > The underlying core patch has not been applied and so this doc patch > cannot be either. > > I found that FC’s patch no longer applies cleanly and made an ad-hoc > attempt to rebase it, but I ran out of time and put it on the back > burner. > > And there it sits for now, on my todo list, along with my doc patch.
I have applied my core patch as cbce292e0 and your doc patch as e2ec1b05a. Thank you. -- Father Chrysostomos
Date: Thu, 4 Dec 2014 15:55:42 +0100
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
To: perl5-porters [...] perl.org
Subject: Re: [perl #114498] List slice *sometimes* ignores undefined items
Download (untitled) / with headers
text/plain 223b
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2014-12-04 03:20]: Show quoted text
> I have applied my core patch as cbce292e0 and your doc patch as > e2ec1b05a. Thank you.
Thank you! Another semantics bug fixed, hooray. :-)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 374b
On Thu Dec 04 06:56:03 2014, aristotle wrote: Show quoted text
> * Father Chrysostomos via RT <perlbug-followup@perl.org> [2014-12-04 03:20]:
> > I have applied my core patch as cbce292e0 and your doc patch as > > e2ec1b05a. Thank you.
> > Thank you! Another semantics bug fixed, hooray. :-)
Speaking of semantics bugs, would you be willing to look at #123367? -- Father Chrysostomos
Subject: Your ticket against Perl 5 has been resolved
Download (untitled) / with headers
text/plain 222b
Thanks for submitting this ticket The issue should be resolved with the release today of Perl v5.22. If you find that the problem persists, feel free to reopen this ticket -- Karl Williamson for the Perl 5 porters team
Subject: Re: Fw: [perl #114498] Your ticket against Perl 5 has been resolved
To: Karl Williamson via RT <perlbug-followup [...] perl.org>
From: John Wiersba <jrw32982 [...] gmail.com>
Date: Tue, 2 Jun 2015 01:52:37 -0400
Download (untitled) / with headers
text/plain 522b
Show quoted text
> From: Karl Williamson via RT <perlbug-followup@perl.org> > To: jrw32982@yahoo.com > Sent: Monday, June 1, 2015 11:40 PM > Subject: [perl #114498] Your ticket against Perl 5 has been resolved > > Thanks for submitting this ticket > > The issue should be resolved with the release today of Perl v5.22. If you > find that the problem persists, feel free to reopen this ticket > > -- > Karl Williamson for the Perl 5 porters team
Thanks, Karl (and all of p5p)! The world will be a better place because of your hard work!


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org