http://qs321.pair.com?node_id=709190


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

Oh, I think it's a good idea to change the source. In terms of backward compatibility you've still got 's' (step into), while the 'n' (next statement) is always a pain when 'n'-ing over sort and map blocks. Of course you can 'c' (continue) to a new location (line), but then you have to stop, break your flow, and work out where you want to go specifically. It's nice to see someone prepared to delve into those murky depths to fix this behaviour to be more intuitive at last.

Richard Foley.

ps. sry, didn't mean to post anonymously earlier :-)

Replies are listed 'Best First'.
Re^5: RFC: Accelerated stepping
by hexcoder (Curate) on Sep 07, 2008 at 19:24 UTC
    I just found out, that if you modify the example Perl code from
    if (0 < scalar grep { $_ == 9 } (1..10)) {
    to
    if (0 < scalar grep(sub { $_ == 9 }, (1..10))) {
    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))) {
    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.

      grep sub { ... }, @list

      never runs the anonymous subroutine and always returns all of @list since a code ref evaluates to 'true' in a Boolean context.

      - tye        

        Oops,

        thanks for your comment, I missed that.