Re: Is map's sub block really being evaluated in list context? wantarray() returns undef..

My first pass assessment would be that maps block doesn't qualify as a sub in the normal sense:

print map{ print wantarray(); (1,2,3) } 1;;
Use of uninitialized value in print at (eval 19) line 1, <STDIN> line 
+11.

1 2 3
[download]

It was obviously called in a list context, else the return would be different:

print scalar map{ print wantarray(); (1,2,3) } 1;;
Use of uninitialized value in print at (eval 20) line 1, <STDIN> line 
+12.

3
[download]

This implies that the block is not a true sub as far as wantarray is concerned. It is just a block as with:

print do{ print wantarray(); (1,2,3) };;
Use of uninitialized value in print at (eval 23) line 1, <STDIN> line 
+15.

1 2 3
[download]

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re: Is map's sub block really being evaluated in list context? wantarray() returns undef.. Select or Download Code

Replies are listed 'Best First'.
Re^2: Is map's sub block really being evaluated in list context? wantarray() returns undef.. by moritz (Cardinal) on Oct 20, 2011 at 10:35 UTC
Curiously, if you define your own sub which takes a block, wantarray treats it as a normal routine: `$ perl -wE 'sub f(&) { shift->() }; say f { wantarray }' 1` [download] I wonder if this inconsistency is worth a bug report. Perl 6 - second systems done right	[reply] [d/l]
Re^3: Is map's sub block really being evaluated in list context? wantarray() returns undef.. by BrowserUk (Patriarch) on Oct 20, 2011 at 15:07 UTC
I suspect that as a built-in, map avails itself of more optimisations than it would be safe to apply to a user-written function. I know from experience that if you implement a callback interface in XS using the full belts'n'braces approach described in perlcall, then the result is far less efficient than the carefully optimised callback interface used by List::Util`::reduce()`. The downside of trying to match that level of optimisation with your own XS code is that it is very easy to create the situation whereby the callback leaks memory if it contains closures. (The early versions of reduce() suffered from the same problems.) I think it would be very difficult, if not impossible to compile user-written, runtime-compiled subs taking callbacks, to be as efficient as map. And to 'fix the inconsistency' would essentially require pessimising the implementation of map So no, I don't think it is worth a bug report. At most, a documentation change noting the difference might be useful. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l]