in reply to (Ovid) Re: Re (tilly) 2: Paradigm Shift - Don't use strict
in thread Paradigm Shift - Don't use strict

To understand how to use goto, you need to understand why not to use it. And the best place to start with that is by reading Go To Statement Considered Harmful. If you read the classic paper that started the debate, you will find that the fundamental objection to goto is that it leads to control structures that are hard for people to model.

Therefore it follows that the only kind of goto which you should want to use is a goto which helps the program fit into control structures that people can understand. If, of course, there are alternate commands which can redirect flow you should want to use them instead. They document intent more clearly. But it is occasionally true that the best way to do things is a goto.

Knuth offered a number of examples in a paper I have not found online. However based on a variety of comments I have seen about it, it seems that the majority of his cases are addressed with having multiple exits from functions, and with Perl's loop control statements. In languages with single function exits and without loop control statements, you can reasonably reach for them with a goto. In Perl, as noted in perlsyn, you would be far better off reaching for loop control statements instead. Be warned, even so you will find that there is a debate on the advisability of internal loop exits. My position on this is shaped by Loop Exits and Structured Programming: Reopening the Debate.

Another example mentioned in the original paper is exception programming. I have seen goto used this way in both VB and Perl. Trust me. Doing your exception programming with die/eval or some other specific exception handler is far preferable to using goto for this purpose. But that is a use you will occasionally run into.

Given those extra control structures, it is rare to want a goto in Perl. You have stated one, subverting the stack. Eg to fool Exporter's caller. Or trying to get tail-recursion to work. A second would be if you were trying to create your own control structure. For instance that was the problem that TheDamian faced in Switch. His control of flow problem didn't fit with any loop control statements, it almost did but not quite. So he used an amazing goto to get what he wanted. Another example might be that you could use gotos to make state transitions for a finite state machine. (Hopefully the ugliness would be hidden behind some code autogeneration.) The goto is not problematic because it enables you to work within a good structure for the rest of the program.

I have not personally ever felt the desire to (other than in deliberate experimentation) use a goto in Perl for anything other than subverting the stack. However I remain aware that I could, and I would do it without hesitation if I thought the situation warranted it. I also doubt I will ever encounter such a situation, but I think I could likely spot it if I did...

Knuth's reponse is at Structured Programming with go to Statements. (PDF scan of a print article. Acceptable quality.) Thanks to hsmyers for pointing it out at Re: Would you use 'goto' here?.

  • Comment on Re (tilly) 4: Paradigm Shift - when to use goto

Replies are listed 'Best First'.
Re: Re (tilly) 4: Paradigm Shift - when to use goto
by TheDamian (Priest) on Nov 18, 2001 at 03:21 UTC
    I concur with everything tilly said above. To summarize, a goto is not considered harmful when you're:
    • replacing the current subroutine via a goto &othersub (rare),
    • autogenerating code that will never be seen or maintained directly (rarer),
    • implementing a flow-of-control that Perl doesn't support natively (rarest).

    For me, the key point in tilly's reply is that virtually all other "legitimate" uses of a goto in other languages are made redundant in Perl by the availability of named loops.

    Whereas in C/C++ you might reasonably have to write:

    for (i=1; i<10; i++) { for (j=1; j<10; j++) { for (k=1; k<10; k++) { /* Process data[i][j][k] here */ if (data[i][j][k] < threshold) goto EOLOOPS; } } } EOLOOPS:
    Perl has a much cleaner way to escape from a deep nesting:
    LOOPS: for $i (1..10) { for $j (1..10) { for $k (1..10) { # Process $data[$i][$j][$k] here last LOOPS if $data[$i][$j][$k] < $threshold; } } }
    Long ago, before I discovered the Way of the Camel, I used to rely on a couple of moderately evil preprocessor commands to give myself named loops in C/C++ too:
    #define named(name) goto name; name##_break: if (0) name: #define break(name) goto name##_break; /* Which then allows you to write... */ named (LOOPS) for (i=1; i<10; i++) { for (j=1; j<10; j++) { for (j=1; j<10; j++) { /* Process data[i][j][k] here */ if (data[i][j][k] < threshold) break(LOOPS); } } }
    Exploring how those #defines work -- and why they don't interfere with the semantics of normal (unnamed) break statements -- is left as an exercise for those of you who still follow the Dark Path. ;-)

      To shed my vast light on the discussion, 8 years later: Is this

      replacing the current subroutine via a goto &othersub (rare),
      really true? I thought that goto was the only way to get proper tail-call recursion, which means that those of us with functional backgrounds who aren't so fond of iteration would be using it a lot.

      Incidentally, nothingmuch has recently offered Sub::Call::Tail for those who recoil from the syntactic ugliness of the goto-based set-up. Given your contributions in the past, I imagine you have your own way of twisting tail-calling gotos into shape when the occasion warrants. :-)