$b = [ $a->[1..4]->[11..12] ];
[download]

@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/
[download]

Does "by definition" and "it makes sense to Larry" help here?

The index of a scalar access to a data structure (array or hash) is always evaluated in scalar context, because one and only one item comes back from the calculation.

You don't expect $a->[3..5] to come back with 3 items, do you? If so, please reset your expectations to the way Larry implemented that design. If you want a slice, there's a slice notation. If you want a single element, you have a single element notation.

Note that for Perl6, Larry changed his mind ("see rule #1"), and it acts differently, which I think will mean that DWIMmery will eventually lead to unpredictable behavior at that level. In fact, I saw some evidence of that in a Perl6 design discussion two years ago.

However, for Perl5, it's very predictable, and doesn't depend on the context in which the item appears, which I think is quite nice.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

It does because it is a scalar context.

Your problem is that you're not accepting/catching/groking that the parts inside the [] have their own context due to their nature (dereferencing a single element from an array reference) that's independent from the context of the larger expression. It doesn't matter how many of them you stack up, each of them is trying to retrieve a single element. Slices use @{ $aref }[ LIST ], single elements use ${ $aref }[ EXPR ]. The later is not the former, the former is not the later. They're two different things which impose different contexts on the subscripts.

Update: let me rewrite your example using the more explicit brace-y syntax I used; that might help clear it up. Your:
$a->[1..4]->[11..12]

is the same as:
${ ${ $a }[ 1..4 ] }[ 11..12 ]

A similar slice (which due to the indices you used wouldn't make much sense :) would be:
@{ @{ $a }[ 1..4 ] }[ 11..12 ]

But again, you don't have a slice, you're fetching a single element so it's scalar context inside the []s.

Okay, that now makes sense.

What actually helped shed light on it was using your ctx function in this code:

sub ctx {
  my $w = wantarray;
  print "$_[0]:";
  print ( defined $w ? ($w?'array':'scalar') : 'void');
  print "\n";
  \&ctx;
}
sub ctxind {
  my $w = wantarray;
  print "$_[0]:";
  print ( defined $w ? ($w?'array':'scalar') : 'void');
  print "\n";
  1;
}

my $a = [ ctx("buildA1"),ctx("buildA2"),ctx("buildA3"),ctx("buildA4") 
+];
ctx("by itself");
@{$a}[ctxind("slice ndx")];
$a -> [ctxind("plain ndx")] -> 
    ("fn1",ctx("args1"),ctx("args2")) -> ("fn2",ctx("args3"));
[download]

This yields:

buildA1:array
buildA2:array
buildA3:array
buildA4:array
by itself:void
slice ndx:array
args3:array
args1:array
args2:array
plain ndx:scalar
fn1:scalar
fn2:void
[download]

Which now all makes sense, except for the "args3" being evaluated before "args1". That seems like a rather bizarre evaluation order.

The contexts inside () on the function references are all array context, and the context inside [] is array or scalar depending only on the immediately surrounding syntax. The context of the function called by the dereference itself depends on the surrounding code.

I guess if TIEARRAY worked better, I'd be able to tie the array that $a points to and see that the FETCH method was getting called with different contexts depending on the code surrounding the array ref, even though the context applied to the expression generating the index was determined only by wheter I'd used the slice syntax or not. Unfortunately, it appears that FETCH is always called in scalar context, no matter what.

--


@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/
[download]