List slice *sometimes* ignores undefined items

[p5pRT]

Migrated from rt.perl.org#114498 (status was 'resolved')

Searchable as RT114498$

[p5pRT]

From jrw32982@yahoo.com

@​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.

[p5pRT]

From @jkeenan

On Sun Aug 19 08​:27​:12 2012\, jrw32982@​yahoo.com wrote​:

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

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @cpansprout

On Sun Aug 19 08​:27​:12 2012\, jrw32982@​yahoo.com wrote​:

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

[p5pRT]

From @ap

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

[p5pRT]

From @ikegami

On Tue\, Aug 21\, 2012 at 3​:26 AM\, Father Chrysostomos via RT \< perlbug-followup@​perl.org> wrote​:

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.

[p5pRT]

From rick@bort.ca

On Aug 31 2012\, Aristotle Pagaltzis wrote​:

* James E Keenan via RT \perlbug\-followup@&#8203;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

[p5pRT]

@cpansprout - Status changed from 'open' to 'rejected'

[p5pRT]

From @ap

* Rick Delaney \rick@&#8203;bort\.ca [2012-08-31 06​:10]​:

On Aug 31 2012\, Aristotle Pagaltzis wrote​:

* James E Keenan via RT \perlbug\-followup@&#8203;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.

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

[p5pRT]

From @ikegami

On Fri\, Aug 31\, 2012 at 12​:51 AM\, Aristotle Pagaltzis \pagaltzis@&#8203;gmx\.dewrote​:

* Rick Delaney \rick@&#8203;bort\.ca [2012-08-31 06​:10]​:

On Aug 31 2012\, Aristotle Pagaltzis wrote​:

* James E Keenan via RT \perlbug\-followup@&#8203;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

[p5pRT]

From @perhunter

On 08/31/2012 12​:51 AM\, Aristotle Pagaltzis wrote​:

* Rick Delaney \rick@&#8203;bort\.ca [2012-08-31 06​:10]​:

On Aug 31 2012\, Aristotle Pagaltzis wrote​:

* James E Keenan via RT \perlbug\-followup@&#8203;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

[p5pRT]

From Eirik-Berg.Hanssen@allverden.no

On Fri\, Aug 31\, 2012 at 7​:20 AM\, Uri Guttman \uri@&#8203;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

[p5pRT]

From @ap

* Eric Brine \ikegami@&#8203;adaelis\.com [2012-08-31 07​:15]​:

On Fri\, Aug 31\, 2012 at 12​:51 AM\, Aristotle Pagaltzis \pagaltzis@&#8203;gmx\.dewrote​:

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.

[p5pRT]

From @ap

fix-perldata-empty-list-slice.diff

```diff diff --git i/pod/perldata.pod w/pod/perldata.pod index 3a4776c..9bff98f 100644 --- i/pod/perldata.pod +++ w/pod/perldata.pod @@ -777,13 +777,18 @@ 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 +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 + This makes it easy to write loops that terminate when a null list is returned: ```

[p5pRT]

From jrw32982@yahoo.com

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]]);

________________________________ From​: Eirik Berg Hanssen \Eirik\-Berg\.Hanssen@&#8203;allverden\.no To​: Uri Guttman \uri@&#8203;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@&#8203;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

[p5pRT]

From jrw32982@yahoo.com

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.

________________________________ From​: Aristotle Pagaltzis \pagaltzis@&#8203;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@&#8203;adaelis\.com [2012-08-31 07​:15]​:

On Fri\, Aug 31\, 2012 at 12​:51 AM\, Aristotle Pagaltzis \pagaltzis@&#8203;gmx\.dewrote​:

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.

[p5pRT]

From @cpansprout

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

#!/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

[p5pRT]

From @cpansprout

On Fri Aug 31 06​:09​:29 2012\, aristotle wrote​:

* Eric Brine \ikegami@&#8203;adaelis\.com [2012-08-31 07​:15]​:

On Fri\, Aug 31\, 2012 at 12​:51 AM\, Aristotle Pagaltzis \pagaltzis@&#8203;gmx\.dewrote​:

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

[p5pRT]

From jrw32982@yahoo.com

_______________________________

From​: Father Chrysostomos via RT \perlbug\-followup@&#8203;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]]);

[p5pRT]

From @jkeenan

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?

Thank you very much. Jim Keenan

[p5pRT]

From @cpansprout

On Fri Aug 31 09​:14​:20 2012\, jrw32982@​yahoo.com wrote​:

_______________________________

From​: Father Chrysostomos via RT \perlbug\-followup@&#8203;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

[p5pRT]

From @cpansprout

On Sat Sep 01 16​:02​:23 2012\, jkeenan wrote​:

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

[p5pRT]

From jrw32982@gmail.com

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@&#8203;yahoo\.com wrote​:

________________________________ From​: Father Chrysostomos via RT \perlbug\-followup@&#8203;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@&#8203;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

[p5pRT]

From @ap

* John Wiersba \jrw32982@&#8203;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.

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.

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

[p5pRT]

From @cpansprout

On Sun Sep 02 05​:51​:27 2012\, aristotle wrote​:

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

[p5pRT]

From jrw32982@yahoo.com

________________________________ From​: Aristotle Pagaltzis \pagaltzis@&#8203;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@&#8203;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.  :-)

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

[p5pRT]

From @cpansprout

On Sun Sep 02 13​:34​:41 2012\, jrw32982@​yahoo.com wrote​:

________________________________ From​: Aristotle Pagaltzis \pagaltzis@&#8203;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@&#8203;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

[p5pRT]

@cpansprout - Status changed from 'rejected' to 'open'

[p5pRT]

From jrw32982@yahoo.com

________________________________ From​: Father Chrysostomos via RT \perlbug\-followup@&#8203;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-archive.perl.org/perl5/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

[p5pRT]

From @ap

* Father Chrysostomos via RT \perlbug\-followup@&#8203;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/>

[p5pRT]

From jrw32982@yahoo.com

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

________________________________ From​: A. Pagaltzis via RT \perlbug\-followup@&#8203;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@&#8203;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/>

[p5pRT]

From @ap

* John Wiersba \jrw32982@&#8203;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.

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

[p5pRT]

From @cpansprout

On Fri Sep 07 08​:48​:54 2012\, aristotle wrote​:

* John Wiersba \jrw32982@&#8203;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

[p5pRT]

From jrw32982@yahoo.com

________________________________ From​: A. Pagaltzis via RT \perlbug\-followup@&#8203;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@&#8203;yahoo\.com [2012-09-07 06​:00]​:

Aristotle\, let me see if I understand what you're proposing.

OK. Thanks!  :-)

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.

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.

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.  All 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?

Regards\,

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

[p5pRT]

From @cpansprout

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.

--

Father Chrysostomos

[p5pRT]

From jrw32982@yahoo.com

________________________________ From​: Father Chrysostomos via RT \perlbug\-followup@&#8203;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)

[p5pRT]

From @cpansprout

On Thu Sep 06 16​:48​:06 2012\, aristotle wrote​:

* Father Chrysostomos via RT \perlbug\-followup@&#8203;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

[p5pRT]

From @cpansprout

Inline Patch

```diff 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"); } { ```

[p5pRT]

From jrw32982@yahoo.com

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@&#8203;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@&#8203;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"); }

{

[p5pRT]

From jrw32982@yahoo.com

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

________________________________ From​: John Wiersba \jrw32982@&#8203;yahoo\.com To​: "perlbug-followup@​perl.org" \perlbug\-followup@&#8203;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@&#8203;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@&#8203;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"); }

{

[p5pRT]

From @doy

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

[p5pRT]

From @cpansprout

On Thu Sep 20 08​:07​:24 2012\, jrw32982@​yahoo.com wrote​:

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

[p5pRT]

From jrw32982@yahoo.com

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

________________________________ From​: Jesse Luehrs \doy@&#8203;tozt\.net To​: John Wiersba \jrw32982@&#8203;yahoo\.com Cc​: "perlbug-followup@​perl.org" \perlbug\-followup@&#8203;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

[p5pRT]

From @cpansprout

Sorry you got no response. I missed this message.

On Thu Sep 20 09​:59​:19 2012\, jrw32982@​yahoo.com wrote​:

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?

See my crude ASCII arrow. :-)

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.

Thanks! -- John

________________________________ From​: Jesse Luehrs \doy@&#8203;tozt\.net To​: John Wiersba \jrw32982@&#8203;yahoo\.com Cc​: "perlbug-followup@​perl.org" \perlbug\-followup@&#8203;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

--

Father Chrysostomos

[p5pRT]

From @ap

* Father Chrysostomos via RT \perlbug\-followup@&#8203;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/>

[p5pRT]

From @ap

0001-perldata-document-corrected-list-slicing-behaviour.patch

```diff From 385013a1eff5855e500f7f6a2657260f0673cf19 Mon Sep 17 00:00:00 2001 Message-Id: <385013a1eff5855e500f7f6a2657260f0673cf19.1381382810.git.pagaltzis@gmx.de> From: Aristotle Pagaltzis 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 ```

[p5pRT]

From jrw32982@yahoo.com

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]' \ \<> \<>

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.

________________________________ From​: Aristotle Pagaltzis via RT \perlbug\-followup@&#8203;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@&#8203;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@&#8203;gmx\.de From​: Aristotle Pagaltzis \pagaltzis@&#8203;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

[p5pRT]

From @ap

* John Wiersba \jrw32982@&#8203;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]' \ \<> \<>

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

[p5pRT]

From jrw32982@yahoo.com

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

________________________________ From​: Aristotle Pagaltzis via RT \perlbug\-followup@&#8203;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@&#8203;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]' \ \<> \<>

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

[p5pRT]

From @ap

* John Wiersba \jrw32982@&#8203;yahoo\.com [2013-10-11 21​:05]​:

* Aristotle Pagaltzis \pagaltzis@&#8203;gmx\.de [2013-10-10 20​:20]​:

* John Wiersba \jrw32982@&#8203;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]' \ \<> \<>

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