Re^5: RFC: Accelerated stepping

in reply to Re^4: RFC: Accelerated stepping
in thread RFC: Accelerated stepping

I just found out, that if you modify the example Perl code from
if (0 < scalar grep { $_ == 9 } (1..10)) {
[download]
to
if (0 < scalar grep(sub { $_ == 9 }, (1..10))) {
[download]
then 'n' does step over the whole grep command at once!

Update: thanks to tye for noticing an error in the above code. Obviously the code

if (0 < scalar grep(1, (1..10))) {
[download]

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

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

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.

In Section Meditations