The assignment operator itself happens to be both in scalar and in list context. It produces both a list for the list, and a scalar for the function scalar().

You'll have to explain that. If it returns two values, what are they? How does it collapse into one value? How can you select which value you want? You're clearly speaking conceptually because that's not how perl is coded at all. So what advantages does your concept have?

What bearing should the implementation have upon the concept so long as the concept is not describing a different end result? Isn't the whole point of different levels of abstraction to enable, in as many instances as workable anyway, people to disregard how things work at the lower level? The microcode in the processor knows nothing of sv_this and av_that, after all.

Let's go with the idea that it's the list assignment operator that is the only thing returning anything there. It returns to the scalar() built-in the count of elements in the list. What returns results to the list on the left, which receives as many results as there are elements present to take them? Isn't that also the list assignment operator? If it's returning something to scalar() and it's returning something to ( $x, $y ) as well, then you have a single operator returning two results in two different contexts within the same expression.

I agree that abstraction is a very useful tool. But adding layers of abstraction for no reason is not better either. That's why I'm asking what value there is in your abstraction.

Let's go with the idea that it's the list assignment operator that is the only thing returning anything there.

I didn't realize that idea what proposed before, but ok. (I would say that say, scalar, both list operators, the assignment operator, $a, $b and $c all return something.)

What returns results to the list on the left, which receives as many results as there are elements present to take them? Isn't that also the list assignment operator?

If you're asking me what happens in your abstraction, I can't say, because I'm trying to understand your abstraction. So I'm going to assume you're asking what really happens.

Does the "+" in "$p + $q" return something to "$p"? No.
Does the "=" in "($a,$b) = ($c,$d)" return something to "($a,$b)"? No.

You have the flow backwards. The assignment operator assigns to a list returned to it.

            ____
           /  | \
          2|  | |1
           |  v |
say(scalar(() = ($a, $b, $c)))
    ^         |
    |         |3
     \_______/
[download]

Or viewed as named operators:

             _______________________
            /     \                 \
           |       |1                |2
           v       |                 |
say(scalar(aassign(list($a, $b, $c), list()))
    ^      |
    |      |3
     \____/
[download]

If it's returning something to scalar() and it's returning something to ( $x, $y ) as well, then you have a single operator returning two results in two different contexts within the same expression.

Ok, I understand your concept: You've renamed "assigns to" to "returns to". If that helps you understand how assignment operators work, great. On the other hand, introducing another definition for "return" is problematic.

The assignment operator itself happens to be both in scalar and in list context. It produces both a list for the list, and a scalar for the function scalar().

You are confused what I'm talking about. I'm not talking about how it happens in the interpreter. I'm talking about what appears to happen, so that people understand what the folks who talk about lists in scalar context are seeing from their POV. Look at the notation and pretend you know nothing about how perl works, and are only beginning with Perl.

No, I'm not confused. Operators do something and return something. This is both what happens and what appears to happen. The assignment operator gets the list on the right, it doesn't in any way produce or return it.
--
Online Fortune Cookie Search
Office Space merchandise