Why does the goatse operator work?

Question

The difference between arrays and lists and between list and scalar context have been discussed in the Perl community quite a bit this last year (and every year, really). I

Answer 1

You misunderstand. Lists evaluated in scalar context do not get their size. In fact, it is all but impossible to have a list in scalar context. Here, you have a scalar assignment with two operands, a scalar variable on the left, and a list assignment on the right (given scalar context by the scalar assignment). List assignments in scalar context evaluate to the number of items on the right of the assignment.

So, in:

1 $foo
2 =
3 ()
4 =
5 ('bar')

2, a scalar assignment, gives 1 and 4 scalar context. 4, a list assignment, gives 3 and 5 list context, but nevertheless is itself in scalar context and returns appropriately.

(When = is a list assignment or a scalar assignment is determined purely from the surrounding syntax; if the left operand is a hash, array, hash slice, array slice, or in parentheses, it is a list assignment, otherwise it is a scalar assignment.)

This treatment of list assignments in scalar context makes possible code like:

while ( my ($key, $value) = each %hash ) {

where list-context each is an iterator that returns (in list context) one key and value for each call, and an empty list when done, giving the while a 0 and terminating the loop.

Answer 2

It helps to remember that in Perl, assignment is an expression, and that you should be thinking about the value of the expression (the value of the assignment operator), not "the value of a list".

The value of the expression qw(a b) is ('a', 'b') in list context and 'b' in scalar context, but the value of the expression (() = qw(a b)) is () in list context and 2 in scalar context. The values of (@a = qw(a b)) follow the same pattern. This is because pp_aassign, the list assignment operator, chooses to return a count in scalar context:

else if (gimme == G_SCALAR) {
    dTARGET;
    SP = firstrelem;
    SETi(lastrelem - firstrelem + 1);
}

(pp_hot.c line 1257; line numbers are subject to change, but it's near the end of PP(pp_aassign).)

Then, apart from the value of the assignment operator is the side-effect of the assignment operator. The side-effect of list assignment is to copy values from its right side to its left side. If the right side runs out of values first, the remaining elements of the left side get undef; if the left side runs out of values first, the remaining elements of the right side aren't copied. When given a LHS of (), the list assignment doesn't copy anything anywhere at all. But the value of the assignment itself is still the number of elements in the RHS, as shown by the code snippet.

Answer 3

First, "list" is an ambiguous term. Even the question uses it to refer to two different things. I suspect you might be doing this without realizing it, and that this is a significant part of the cause of your confusion.

I shall use "a list value" to denote what an operator returns in list context. In contrast, "the list operator" refers the operator EXPR,EXPR,EXPR,... also known as "the comma operator"^[1].

Second, you should read Scalar vs List Assignment Operator.

---

I guess that assignment via = from list to list distributes assignments from items in one list to items in the other list, which is why in the second example $string2 gets 'stuff', and why we can unpack @_ via list assignment.

Correct.

I've read numerous times that lists don't actually exist in scalar context.

That wording is very ambiguous. You seem to be talking about list values (which are found in memory), but scalar context only exist in the code (where operators are found).

• A list/comma operator can be evaluated in scalar context.
• A list value can't be returned in scalar context.

Scalar context is a context in which an operator can be evaluated.

A operator evaluated in scalar context cannot return a list. It must return a scalar. Loosely speaking, you could say a list can't be returned in scalar context.

On the other hand, a list/comma operator can be evaluated in scalar context. e.g. scalar(4,5,6). Every operator can be evaluated in any context (though it's not necessarily useful to do so).

But the explanation of the goatse operator is that it is a list assignment in scalar context.

It includes one, yes.

List values and list assignment operators are two different things. One's a value. The other is a piece of of code.

A list assignment operator, like every other operator, can be evaluated in scalar context. A list assignment operator in scalar context returns the number of scalars returned by its RHS.

So if you evaluate () = qw(a b c) in scalar context, it will return three, since qw() placed three scalars on the stack.

However, I don't understand how assignment to (), an empty list, could possibly work.

Just like the assignment ($x,$y) = qw(stuff junk things) ignores the third element returned by the RHS, () = qw(stuff junk things) ignores all elements returned by the RHS.

With my current understanding, since lists are immutable, the size of the list would remain 0

Saying "the size of the list would remain zero" for ()=qw(a b c) is like saying "the value of the scalar will remain 4" for 4+5.

For starters, there's question of which list you're talking about. The LHS returned one, the RHS returned one, and the assignment operator might return one.

The list value returned by the LHS will be 0 in length.

The list value returned by the RHS will be 3 in length.

In scalar context, the list assignment operator returns the number of scalars returned by RHS (3).

In list context, the list assignment operator returns the scalars returned by LHS as lvalues (empty list).

lists are supposed to be immutable.

If you're thinking in terms of list mutability, you took a wrong turn somewhere.^[2]

---

Notes:

1. The docs call EXPR,EXPR,EXPR,... two instances of a binary operator, but it's easier to understand as a single N-ary operator, and it's actually implemented as a single N-ary operator. Even in scalar context.

2. It's not actually true, but let's not go any further down this wrong turn.