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";
[download]

I'm talking about what happens when return @array; gets run. return @array; is not implemented using XS macros.

And Perl has special handling for dealing with (just) XS code that behaves badly and returns more than one item when called in a scalar context (I even mentioned this specifically previously -- probably in a prior thread about this ever-returning topic but one I re-read recently).

but somehow I find it unlikely

Yeah, I just make all this stuff up. For Python's sake, just go look at the source code if you think I don't know what I'm talking about. Wow, cling much?

Here, the array IS returned from the function :)

Um, actually, a single reference is returned from the function and the fact that the function was predeclared :lvalue means that the caller adds code to dereference that reference. But nice last stab at trying to cling just a little more. q-:

- tye        

Well. You have it right. I do know only how the XS functions are interfaced with perl and I base my assumptions on this knowledge. I'm not going to check perl sources to see if perl has different stack discipline for pure perl functions. After all it is not important for me since I write either in perl or extensions for perl. And if you know how the things are really handled, fine with me. It does not affect my work, for perl programs it makes no difference how the internal stack is handled :)

The example of a way to return array from the function was not a way to "cling". This whole discussion has started after your statement, that there's no way to return an array in perl. So I just gave an example when the array is returned from the function. Whatever internal steps are done for this are not of a concern for me at this point. In our arguing about how things are done internally we have forgotten, why the arguing has started in the first place :)