fgg1991 has asked for the wisdom of the Perl Monks concerning the following question:

my code is like:
my $r = ['111','222','aaa','bbb']; print $r; my $s = ('111','222','aaa','bbb'); print $s;
I understand that in this situation $r woulb be a ref and print $r would give me sth like ARRAY(0x35423542), but I don't understant the second example, why it would give me bbb, the last element ?

Replies are listed 'Best First'.
Re: The behavior when assigning an array to scalar?
by choroba (Cardinal) on Sep 26, 2017 at 09:52 UTC
    That's because the comma operator in scalar context returns the second argument. See perlop for details.

    Update:

    Also, one interesting case is missing in your question:

    my $t = '111', '222', 'aaa', 'bbb'; print $t;

    It prints 111, becuase of precedence of the two operators involved, the comma and equal sign. In fact, the parentheses in the $s case were used only to change the precedence.

    ($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord }map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
Re: The behavior when assigning an array to scalar? (updated)
by haukex (Archbishop) on Sep 26, 2017 at 09:56 UTC
    why it would give me bbb, the last element ?

    Because the Comma Operator in scalar context "evaluates its left argument, throws that value away, then evaluates its right argument and returns that value." See also arrays and lists, hmmm (one thread of many)

    (choroba beat me to it ;-) )

    Update: I just wanted to pick up on the node title:

    assigning an array to scalar

    ('111','222','aaa','bbb') isn't an array, in this form it's a literal list. While you obviously use lists to populate arrays, arrays and literal lists behave differently in different contexts. For example, an array in scalar context returns its size, whereas a list returns its last value (due to the way the comma operator works, as I said above).

Re: The behavior when assigning an array to scalar?
by perl-diddler (Chaplain) on Sep 27, 2017 at 05:55 UTC
    An alternate way of looking at the problem (besides focusing on the comma's behavior as an operator): is that in the 2nd example, you are putting parentheses around a list. You'll get the same value assigned to "$s" whether you use parentheses or not.

    In a way, it's similar to using semi-colons to separate statements that are grouped together:

    my $s = do {"111"; "222"; "aaa"; "bbb"}; print $s."\n";
    The above also prints "bbb" -- but if you have warnings on, it will also warn you that the first 3 items are ignored:
    > perl -e ' use warnings; my $s = do {"111"; "222"; "aaa"; "bbb"}; print $s."\n";' Useless use of a constant ("111") in void context at -e line 3. Useless use of a constant ("222") in void context at -e line 3. Useless use of a constant ("aaa") in void context at -e line 3. bbb
      You'll get the same value assigned to "$s" whether you use parentheses or not.

      Sorry, but that's not correct, as choroba showed in his update shortly after posting. The reason is that assignment has slightly higher precedence than the comma.

      $ perl -le 'my $s = ("111","bbb"); print $s' bbb $ perl -le 'my $s = "111","bbb" ; print $s' 111 $ perl -MO=Deparse,-p -e 'my $s = ("111","bbb")' (my $s = ('???', 'bbb')); $ perl -MO=Deparse,-p -e 'my $s = "111","bbb" ' ((my $s = '111'), '???');
      it will also warn you that the first 3 items are ignored

      You get those warnings with commas as well - but it's a good point, since it hints that the OP may not be using warnings. fgg1991: Always Use strict and warnings!

      $ perl -wMstrict -e 'my $s = ("111","222","aaa","bbb")' Useless use of a constant ("111") in void context at -e line 1. Useless use of a constant ("222") in void context at -e line 1. Useless use of a constant ("aaa") in void context at -e line 1. $ perl -wMstrict -e 'my $s = "111","222","aaa","bbb" ' Useless use of a constant ("222") in void context at -e line 1. Useless use of a constant ("aaa") in void context at -e line 1. Useless use of a constant ("bbb") in void context at -e line 1.
        Re: precedence... wow.. so perl is different than C in that case? Thought for sure C took the right most element and that perl was designed to follow C precedence rules. hmmm...I should probably go test a C case now...