if (0 < scalar grep(1, (1..10))) {
does not involve a code block, and consequently is stepped over with a single 'n'.
For map and sort the behavior looks a bit different, since the operator prototypes are not orthogonal :-(.
sort wants something like ::mycmp (no sigil, so what is the name of that type?).
These examples
print '1. ', (join q{,}, sort qw(a z b y)), "\n";
print '2. ', (join q{,}, sort { $a cmp $b } qw(a z b y)), "\n";
print '3. ', (join q{,}, sort(::mycmp qw(a z b y))), "\n";
sub mycmp
{
return $a cmp $b;
}
work, and will give these results:
example '1.' will be stepped over by 'n', while examples 2./3. are non stepped over with 'n'.
So, only if you supply your own comparison, 'n' steps into it.
The same goes for map, except that map only works with a code block.
This
# panics
print 'map2', (join q{,}, map(::myuc qw(a z b y))), "\n";
sub myuc
{
return uc($_[0]);
}
causes a panic from the Perl interpreter during compile time!
Finally the operators from List::Util and List::MoreUtils (c implementation) are stepped over with 'n'.
So I think the inconsistency in behavior is caused by the Perl interpreter, namely the treatment of code references/blocks as parameters of operators. So the behavior should better be changed there. I will contact p5p.
|