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]

             _______________________
            /     \                 \
           |       |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.

Firstly, this isn't my abstraction. I never invented it and take no credit nor blame for it. I merely think that if it's helpful to someone, those of you who favor another abstraction shouldn't argue that it can't be helpful to them.

Secondly, I know that infix operators could very well be rewritten as prefix or even as postfix operators or as prefix functions. That's not what is being discussed here.

As I've said before, and I always tend to have to say when discussing this topic: I think there's merit in giving people pointers to an abstraction that is clearer to you, but that if they find an abstraction you find inferior clearer to them then why must you attack that abstraction?

I think both ways of looking at this can be helpful. I think some people learn better by digging deeper and figuring out what happens at the lower level sooner. I think others prefer to learn a few rules and to learn convoluted exceptions. I really do think some people learn better that way. In fact, in many fields of endeavor people are taught first approximations of ideas, then exceptions, and later taught completely different ways of thinking about the same things.

"'i' before 'i' except after 'c', except when it's an 'a' like in 'neighbor' and 'weigh'" ... except when it's not. Do you really expect kids just learning to spell to know which words are from French, German, Latin, and Greek roots? Irregular plural nouns are taught similarly. Gee, if only there was a programming language that was written by a linguist and could be learned piecemeal like a natural language...

if they find an abstraction you find inferior clearer to them then why must you attack that abstraction?

Where have I done this? Did you mean "Why must one attack"? I asked a couple of questions to try to understand the abstraction, and the only thing I've done since then is answering questions that were posed.

Secondly, I know that infix operators could very well be rewritten as prefix or even as postfix operators or as prefix functions. That's not what is being discussed here.

I didn't rewrite anything or discuss rewriting anything. I simply posted a representation of the opcode tree. list and aassign (list assignment) actually exist in the tree. And yes, the args of aassign are in the reverse order that they appear in the code.

I think both ways of looking at this can be helpful.

I agree. That's why I asked question to better understand.

Before the last discussion on the topic, I would have said there's no such thing as a list in scalar context. The discussion resulted in learning that using the word list is problematic since it means too many different related things.

I think some people learn better by digging deeper and figuring out what happens at the lower level sooner. I think others prefer to learn a few rules and to learn convoluted exceptions.

What about a few rules without any exceptions?

• An operator imposes a context on its operands.
• Every operator decides what it returns based on context.
• An operator cannot return a list in scalar context.

There are no exceptions to the first two rules. Any exceptions to the third rule will crash Perl.

You can use heuristics to determine what a particular operator returns in scalar context (the last element "except after 'c'"). This is where the learning method you mentioned applies. But trying to rewrite those three base rules has so far resulted in a 18 post deep thread of questions.