in reply to Return Value of List-Producing Elements in Scalar Context

The important thing to understand (and something that I clearly misunderstood ten years ago -- I still remember the feeling of egg on face) is that there simply is no such thing as a list in scalar context. A "list producing expression used in scalar context" does not produce a list. It just produces a single value, which is the last element in the comma-delimited expression. (That's as near as I can come to describing the right-hand-side.)

So the truth is that this construct:

my $a = ( 10, 20, 30, 40, 50 );

[download]

...is not generating a list in scalar context and then assigning the last element to $a. It's assigning the scalar value 50 to $a, that's it. There's no list, and the entity has a size of one.

B::Deparse's output is interesting when list-producing syntax is used in scalar context. There's no list. :)

perl -MO=Deparse -E '$x = (10,20,30); say $x'

[download]

There you'll see the comma operator at work doing what it's supposed to do in scalar context: throwing away the item on the lefthand, returning the one on the right.


Dave

Replies are listed 'Best First'.
Re^2: Return Value of List-Producing Elements in Scalar Context
by LanX (Saint) on Jul 28, 2013 at 14:26 UTC
    > A "list producing expression used in scalar context" does not produce a list. It just produces a single value, which is the last element in the comma-delimited expression.

    Maybe better phrased "a list-producing expression used in scalar context" will not produce an intermediate LIST which is then evaluated in scalar context, but a scalar is produced depending on the value. 

      DB<102> scalar (a..d)
 => "1E0"

  DB<103> sub tst {a..d}

  DB<104> tst()
 => ("a", "b", "c", "d")

  DB<105> scalar tst()
 => "1E0"

  DB<106> scalar ("a", "b", "c", "d")
 => "d"

  DB<107> sub tst { @{[a..d]} }

  DB<108> scalar tst()
 => 4

    [download]

    I wonder if a listify operator could help avoiding bugs when changing the return expression of a sub.

    Cheers Rolf

    ( addicted to the Perl Programming Language)

[reply]
[d/l]
[select]
      I wonder if a listify operator could help avoiding bugs when changing the return expression of a sub.

      It might help (and indeed, I think Perl6 has the list operator — but don't quote me), but the context in which the  .. and  ... range/flip-flop operators act is usually pretty clear. scalar alone serves pretty well in this case and in general since it's very easy to induce list context, so easy that one almost gets the impression it's the default!

[reply]
[d/l]
[select]
        I was already bitten by a case where I wanted to return a list like 1,2,3 from a sub and replaced it with  1..3 which acted differently in scalar context.

        True I should have used wantarray, but one intuitively expect a constant behavior...

        (I had different code-branches which returned and I didn't want to duplicate wantarray checks for each branch.)

        FWIW, here a possible implementation of listify: Re^3: wantarray alternative

        Maybe something like l_return (always return list) and a_return (always return array) could help...

        Cheers Rolf

        ( addicted to the Perl Programming Language)

[reply]
[d/l]
[select]
Re^2: Return Value of List-Producing Elements in Scalar Context
by Anonymous Monk on Jul 28, 2013 at 03:57 UTC
[reply]
[reply]

In Section Seekers of Perl Wisdom