in reply to returning to the outer loop

Named blocks used to be the GOTO answer for this sort of problem, but goto is frowned on because it tends to obscure code flow. Often there are better ways to structure your code so that you don't need an explicit equivalent of goto. One way to do that is to place your nested loops in a sub that is called from the outer loop.

Consider:

#!/usr/bin/perl -w
use strict;

my @kPatterns =
    (
    ['aaaaa', 'bbbbb', 'ccccc', 'ddddd',],
    ['eeeee', 'fffff', 'ggggg', 'hhhhh',],
    ['iiiii', 'jjjjj', 'kkkkk', 'lllll',],
    );

for my $test ('yyjjjjjxx', 'ddddd') {
    my $match = scan($test);
    
    print "Matched $test using $match\n" if $match;
}


sub scan {
    my ($test) = @_;
    
    for my $patternList (@kPatterns) {
        for my $pattern (@$patternList) {
            return $pattern if $test =~ $pattern;
        }
    }
    
    return ;
}

[download]

Prints:

Matched yyjjjjjxx using jjjjj
Matched ddddd using ddddd

[download]
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

Replies are listed 'Best First'.
Re^2: returning to the outer loop
by Laurent_R (Canon) on Sep 20, 2018 at 22:45 UTC
    Hi GrandFather,

    I upvoted your very good post, but I have to disagree somewhat with this:

    Named blocks used to be the GOTO answer for this sort of problem, but goto is frowned on because it tends to obscure code flow.
    Many years ago, I had a CS professor who (mildly) criticized my code (but still gave me a good mark) because I was using constructs similar to next, last and return to exit early from a loop because, he claimed, this was akin to (an evil) GOTO. I disagreed moderately with him at the time, and, with three decades of experience in between, I still disagree, much more strongly, with this view today.

    In the debate that followed the famous Go to statement considered harmful article (https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf) by E. Dijkstra (with a title staged to polemicize chosen by N. Wirth), Donald Knuth (Structured Programming with go to Statements, http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf) argued for a more balanced view making (among other things) a distinction between goto forward and goto backward (I'm simplifying quite a bit). Goto backward, he admitted, are often bad because they pave the way for spaghetti code. But goto forward, he said, make sense in many situations. Most of us don't use goto nowadays (at least not in Perl, except possibly and quite rarely for the different goto &NAME form), but next and last statements were invented as a form of healthy structured programming goto forward to exit early from a loop. I agree with Knuth on that (I'm just saying that to state what I think, but, of course, I realize that no one cares about what I think about D. Knuth's arguments on the subject).

    In brief, I really don't think that named blocks tend to obscure code flow (contrary to goto statements). I think they usually are a very natural and clean way to exit early from a loop and that alternatives often tend to be more complicated.

[reply]
[d/l]
[select]

      I somewhat agree that early exits using named blocks has a place. However there is very often benefit in terms of understanding the intent of code from wrapping "complicated" stuff up in a sub. The immediate benefit is that you can understand the surrounding code providing a context for a chunk of named work. If the name is good understanding both the calling context and the called code should be easier and you don't have to understand everything at the same time.

      So, a small part of my reply is "don't use goto", but most of it is "refactor into simple digestible chunks".

      Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
[reply]
        I definitely agree with you that using a sub and a return statement often makes things clearer than named blocks with other flow control statements. I just don't want to dogmatically reject the next, last and continue control flow statements, as they can offer a good and simple way of finely-tuned control flow.
[reply]
      I agree, next and last to named blocks in order to exit multi-level loops is perfectly fine. Using the obscure next and last feature that it will jump through subroutine call boundaries, on the other hand, is evil. Yeah.
[reply]
Re^2: returning to the outer loop
by rizzo (Curate) on Sep 20, 2018 at 23:26 UTC
    ...but goto is frowned on...

    or in other words:
    "... not for the faint of heart (nor for the pure of heart) ..."
    Programming Perl 3rd Edition, page 160.
[reply]
Re^2: returning to the outer loop
by nysus (Parson) on Sep 20, 2018 at 21:56 UTC

    This is interesting to me. For someone like me, whose first language was Apple BASIC, I find the loop labels easier to follow and I don't understand why others feel it "obscures" the flow. I find the use of labels to be more clear, actually.

    $PM = "Perl Monk's";
    $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate Priest";
    $nysus = $PM . ' ' . $MCF;
    Click here if you love Perl Monks

[reply]

      The issue with goto based code is that it becomes almost impossible to tell how you get from one point in the code to another which obscures the relationship and intended ordering of the code. Spaghetti coding (using gotos) just doesn't scale well. For a couple of handfuls of code it's OK, but by the time you need to take your shoes and socks off the code starts to lose structure making it hard to understand code flow.

      Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
[reply]

      ...because you can fall out of the loop, and have no idea logically where you remain.

[reply]

In Section Seekers of Perl Wisdom