# Is there such a thing as a list in scalar context?

•  06-03-2021
•  |
•

Question

my \$mind = ( 'a', 'little', 'confused' );

And it's because perldoc perlfaq4 explains the line above as follows (emphasis added):

Since you're assigning to a scalar, the righthand side is in scalar context. The comma operator (yes, it's an operator!) in scalar context evaluates its lefthand side, throws away the result, and evaluates it's righthand side and returns the result. In effect, that list-lookalike assigns to \$scalar it's rightmost value. Many people mess this up because they choose a list-lookalike whose last element is also the count they expect:

my \$scalar = ( 1, 2, 3 );  # \$scalar gets 3, accidentally

What I understand this to mean is that there is no such thing as a list in scalar context.

However, ikegami maintains that it "result[s] in a list operator, so it is a list literal."

So, is it a list or not?

Solution

A list literal is something that is actually a list written out in code, so (1, 2, 3) is a list literal, whereas caller for example is a function that could return a list or a scalar depending on context.

In a line like:

my \$x = ...;

the ... sees scalar context, so if ... was a list literal, then you would have a list literal in scalar context:

my \$x = (1, 2, 3);

but the list literal does not result in a list, because the comma operator it contains sees scalar context, which then results in it returning the last item of the list literal, and throwing the remaining values away after evaluating them.

In terms of a function, the function itself sees whatever context it is called from, which then is propagated to any line in that function that returns. So you can have a function in scalar, list, or void context, and if the last line of that sub happens to be a list literal, that list literal will see any of those contexts and will behave appropriately.

So basically this is a terminology distinction, with list literal referring to a comma separated list of values in the actual source code*, and list referring to a sequence of values placed onto perl's stack.

You can write subroutines with return values that either behave like arrays or like list literals with regard to context.

sub returns_like_array  {my @x = 1..5; return @x}

sub returns_like_list   {my @x = 1..5; return @x[0 .. \$#x]}

*or something that results in a list of comma separated values, like a qw() or a fat comma => or a hash or array slice.

You can also look at my answer here: How do I get the first item from a function that returns an array in Perl? which goes into a bit more detail about lists.

OTHER TIPS

I agree with you and with perlfaq4. To quote perldata, which is probably the definitive documentation on this point:

In a context not requiring a list value, the value of what appears to be a list literal is simply the value of the final element, as with the C comma operator.

(emphasis mine).

That said, ikegami is entitled to use whatever terminology (s)he wants. Different people think of different language constructs in different terms, and as long as the end results are the same, I don't think it matters if their terminology differs from that in the documentation. (It's not a great idea to insist on idiosyncratic terminology in a public forum, though!)

>perl -MO=Concise,-exec -e"my \$s = (\$x, \$y, \$z);"
1  <0> enter
2  <;> nextstate(main 1 -e:1) v:{
3  <0> pushmark v
4  <#> gvsv[*x] s
5  <#> gvsv[*y] s
6  <#> gvsv[*z] s
7  <@> list sKP                      <--- list in (s)calar context.
9  <2> sassign vKS/2
a  <@> leave[1 ref] vKP/REFC

So yes, one can have a list in scalar context.

One cannot return a list in scalar context. (Well, it is possible from XS, but the program will crash, probably with a "Bizarre copy" error.)

It can't be any other way. If there was a distinct list op and comma op, it would be impossible to compile the following:

sub f { "a", "b", "c" }

Would that result in a list op or a comma op? In reality, there is no such distinction, so yes, it results in that op.

It's not a list. Since you're assigning to a scalar, it's the comma operator - evaluates the left side, evaluates the right side, returns the right side, and resolves left-to-right. \$scalar will be 'confused' :)

It's a matter of terminology and perspective. Terminology is tricky here because you can write a list in source code, return a list of values, or evaluate something in list context.. and the word "list" means something subtly different in each case!

Technically, a list cannot exist in scalar context because perl (the interpreter) does not create a list of values for things like this:

my \$x = ('a', 'b', 'c');

When being pedantic precise this is explained as the behavior of the comma operator in scalar context. Similarly, qw is defined as returning the last element in scalar context so there's no list here, either:

my \$x = qw(a b c);

In both of these cases (and for any other operator examples that we could muster up) what we're saying is that the interpreter doesn't create a list of values. That's an implementation detail. There's no reason that perl couldn't create a list of values and throw away all but the last one; it just chooses not to.

Perl the language is abstract. At a source code level ('a', 'b', 'c') is a list. You can use that list in an expression that imposes scalar context on it, so from that perspective a list can exist in scalar context.

In the end, it's a choice between mental models of how [Pp]erl operates. The "A list in scalar context returns its last value" model is slightly inaccurate but easier to grok. As far as I know there aren't any corner cases where it is functionally incorrect. The "There's no such thing as a list in scalar context" model is more accurate but harder to work with as you need to consider the behavior of every operator in scalar context.