in reply to Re^4: odd =>behavior
in thread odd =>behavior

I don't think that disproves anything . . .

Parentheses don't make lists, though. Commas do. I agree that the higher precedence of the assignment operator is important, but it's very much not the case that all evaluation of lists in scalar context returns the final element of the list.

Replies are listed 'Best First'.
Re^6: odd =>behavior
by Fletch (Bishop) on Dec 04, 2007 at 19:52 UTC

    The statement $result = 3, 2, 1 is a LIST in void context with the list consisting of an assignment expression ($result = 3) and two constants:

    $ perl -MO=Concise -e '$result = 3, 2, 1;' 8 <@> leave[1 ref] vKP/REFC ->(end) 1 <0> enter ->2 2 <;> nextstate(main 1 -e:1) v ->3 7 <@> list vK ->8 3 <0> pushmark v ->4 6 <2> sassign vKS/2 ->7 4 <$> const(IV 3) s ->5 - <1> ex-rv2sv sKRM*/1 ->6 5 <$> gvsv(*result) s ->6 - <0> ex-const v ->- - <0> ex-const v ->7

    Were one to evaluate this entire list expression in scalar context (say $outer = ( $result = 3, 2, 1 );, again only using parentheses for precedence disambiguation) the value in $outer would still be the last element of the list (1). It just so happens in the original that the entire list is in void context so it doesn't matter and that value gets dropped on the floor.

    Having said that, I don't think displaying a value set as a side effect of one subexpression of building the entire list shows anything about the value of that entire list were the entire list in a scalar context.

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

Re^6: odd =>behavior
by ysth (Canon) on Dec 05, 2007 at 02:18 UTC
    Are you thinking of some counter-example? I have the feeling that would involve a definition of list different than mine.