Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re^4: Is this a bug, or expected behavior?

by fizbin (Chaplain)
on Mar 17, 2006 at 15:47 UTC ( #537480=note: print w/replies, xml ) Need Help??

in reply to Re^3: Is this a bug, or expected behavior?
in thread Is this a bug, or expected behavior?

Why? I mean, I can see that this:
$b = [ $a->[1..4]->[11..12] ];
Would require that 1..4 get evaluated in scalar context, but why would 11..12 also need to be evaluated in scalar context? Why doesn't the last thing in the -> chain inherit the context from the overall chain?
@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/; map{y/X_/\n /;print}map{pop@$_}@/for@/

Replies are listed 'Best First'.
Re^5: Is this a bug, or expected behavior?
by merlyn (Sage) on Mar 17, 2006 at 16:16 UTC
    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.

Re^5: Is this a bug, or expected behavior?
by Fletch (Bishop) on Mar 17, 2006 at 16:13 UTC

    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:

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

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

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://537480]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (4)
As of 2022-08-09 01:13 GMT
Find Nodes?
    Voting Booth?

    No recent polls found