Re^7: Confused as to why the "casting context" is mis-behaving (clinging)

[tye]

It is a nice fantasy you have built. It is nice that it works for you. It actually diverts from reality and it uses terminology (and concepts) quite at odds with how Perl is documented. So I don't consider it a good model for others to use.

But I'm tired of trying to point out facts. You aren't interested in how things actually work and I'm not interested in trying to understand your made-up concepts of "OBJECTS" and "COLLECTIONS".

"Remember the rule. Returned on the stack values are always copied before they can be used!"? Or learn the truth: 'returned on the stack from a function' values are already copies. But it is also just a simpler model, not having to invent an extra "it came from a function, so after returning, the values must be copied (for some mysterious reason)". How is this "it came from a function" information communicated to the for() loop so that it knows it has to take a copy? What have you invented to explain that?

Did you know that for($x,$y,$z) actually pushes three scalar values (that are aliases) onto the stack as well? But for() doesn't make copies of those values when it pulls them from the stack. Perl uses a stack-based op-code-dispatch machine. It is a common concept in computing.

I'm not advocating that there is only one correct mental model. That would be stupid. I'm just discouraging people from just making stuff up and then clinging to it. In particular, when you find an exception that your current mental model doesn't handle, don't just make up yet another thing to add to your mental model. That just leads to your mental model getting further and further from reality as you "learn" more and more about Perl.

You want to cling to the idea that the array gets returned and then it gets turned into a scalar after the function returns. In reality, return @array; is implemented as something much closer to:

    return wantarray ? @array[0..$#array] : 1+$#array;

Is there some way you think the caller can tell the above from return @array;?

This is only because the values from the stack are copied into the list and only after that "for" has a chance to alias them.

So the sub "returns the array" (whatever that means) then values from the stack are copied into a list and then for() aliases them? That's a lot of extra steps you have invented. In reality (if anybody cares), the sub pushes onto the stack (copies of the scalar values from the array) and the for() iterates over what is on the stack (just using them in-place).

[andal]

So the sub "returns the array" (whatever that means) then values from the stack are copied into a list and then for() aliases them? That's a lot of extra steps you have invented. In reality (if anybody cares), the sub pushes onto the stack (copies of the scalar values from the array) and the for() iterates over what is on the stack (just using them in-place).

Maybe you'll then try to explain why "return (@a)" behaves differently than "return (@a, 'b')" and differently than "return ('b', @a)" when assigned to scalar? According to your explanation, everything is flattened to the list, and then the assignment to scalar should always pick up the last element from the list. But it does not.

[tye]

Because the scalar context is applied before the sub returns. In a scalar context, 'return' only pushes one scalar onto the stack. (The section you quoted is describing what happens for for(fun()), which isn't a scalar context.)

[andal]

Because the scalar context is applied before the sub returns. In a scalar context, 'return' only pushes one scalar onto the stack. (The section you quoted is describing what happens for for(fun()), which isn't a scalar context.)

I have to admit. One can imagine that opcode for "return" looks up the context and returns on the stack only what context desires. It could be done this way. But if you check "perldoc perlxs" section "Returning SVs, AVs and HVs through RETVAL", then you'll see, that the extension functions don't need to check the context. They can simply place the AV (array) or HV (hash) on the stack, and the caller will do the context adjustment for them.

Well, one can still imagine, that the pure perl functions and the extension functions use different stack discipline, but somehow I find it unlikely.

At the end of the day. For the perl programmer it does not make any difference how the internal perl stack is managed. The main point is, returning an array from function produces different results than returning a list. This is the message I was trying to convey.

By the way. Have you ever tried

use strict;
my @a;
sub canmod : lvalue 
{
    @a;
}

(canmod()) = qw(c d e);

print join(',', @a), "\n";
print join(',', canmod()), "\n";

Here, the array IS returned from the function :)