I'm fairly new to Perl programming, but I'm no stranger to coding in
machine language.
I've noticed that in almost every Perl instruction book, web-based
tutorial and others' scripts I've looked at, there is very little, if any,
use of 'goto Label' which are similar to [conditional] jumps.
Is there some reason why 'goto' and 'labels' aren't common in Perl?
--
Ed Jay (remove M to respond by email)
Ed Jay wrote:
> I'm fairly new to Perl programming, but I'm no stranger to coding in
> machine language.
>
> I've noticed that in almost every Perl instruction book, web-based
> tutorial and others' scripts I've looked at, there is very little, if any,
> use of 'goto Label' which are similar to [conditional] jumps.
>
> Is there some reason why 'goto' and 'labels' aren't common in Perl?
Because using goto* is a sign of horrendous programming. If you feel
the need to use goto, you probably made a very horrific algorithmic
decision. This is not unique to Perl, but is true of pretty much any
language of higher level than Assembler.
Labels, on the other hand, are quite useful and very common. But they
are used in conjunction with loop control keywords next, last, and
redo, not with goto.
Paul Lalli
* I mean, of course, the goto LABEL form of the word. Perl has another
kind of goto, which is quite common and useful, in which you can
terminate the current subroutine and immediately jump into another
subroutine. This is used most commonly in auto-loading methods for
classes.
"Paul Lalli"
>Ed Jay wrote:
>> I'm fairly new to Perl programming, but I'm no stranger to coding in
>> machine language.
>>
>> I've noticed that in almost every Perl instruction book, web-based
>> tutorial and others' scripts I've looked at, there is very little, if any,
>> use of 'goto Label' which are similar to [conditional] jumps.
>>
>> Is there some reason why 'goto' and 'labels' aren't common in Perl?
>
>Because using goto* is a sign of horrendous programming. If you feel
>the need to use goto, you probably made a very horrific algorithmic
>decision. This is not unique to Perl, but is true of pretty much any
>language of higher level than Assembler.
>
>Labels, on the other hand, are quite useful and very common. But they
>are used in conjunction with loop control keywords next, last, and
>redo, not with goto.
>
>Paul Lalli
>
>* I mean, of course, the goto LABEL form of the word. Perl has another
>kind of goto, which is quite common and useful, in which you can
>terminate the current subroutine and immediately jump into another
>subroutine. This is used most commonly in auto-loading methods for
>classes.
I'm not sure I understand what you mean by 'horrendous programming' or
'horrific algorithm.'
What is so horrendous or horrific about, e.g.:
if ($x == 0) {goto NO_X}
versus
if ($x != 0) {do the next task}
else {yada}
You mentioned using goto to branch from one subroutine to another. Is
there an inherent conflict of some sort between this and using 'goto
LABEL?'
--
Ed Jay (remove M to respond by email)
Ed Jay wrote:
> "Paul Lalli"
>
> >Ed Jay wrote:
> >> I'm fairly new to Perl programming, but I'm no stranger to coding in
> >> machine language.
> >>
> >> I've noticed that in almost every Perl instruction book, web-based
> >> tutorial and others' scripts I've looked at, there is very little, if any,
> >> use of 'goto Label' which are similar to [conditional] jumps.
> >>
> >> Is there some reason why 'goto' and 'labels' aren't common in Perl?
> >
> >Because using goto* is a sign of horrendous programming. If you feel
> >the need to use goto, you probably made a very horrific algorithmic
> >decision. This is not unique to Perl, but is true of pretty much any
> >language of higher level than Assembler.
> >
>
> I'm not sure I understand what you mean by 'horrendous programming' or
> 'horrific algorithm.'
>
> What is so horrendous or horrific about, e.g.:
>
> if ($x == 0) {goto NO_X}
>
> versus
>
> if ($x != 0) {do the next task}
> else {yada}
Because NO_X could be defined *anywhere* in the file, or even not
defined at all. And then the program flow from wherever NO_X is
defined has no guaranteed means of returning from whence it came. It
makes maintaining and reading code absurdly more difficult than it has
to be.
> >* I mean, of course, the goto LABEL form of the word. Perl has another
> >kind of goto, which is quite common and useful, in which you can
> >terminate the current subroutine and immediately jump into another
> >subroutine. This is used most commonly in auto-loading methods for
> >classes.
> You mentioned using goto to branch from one subroutine to another. Is
> there an inherent conflict of some sort between this and using 'goto
> LABEL?'
No, I did not. I mentioned the goto &sub form being used to replace
one subroutine call with another. There is no "branching" involved.
It is analogous to exec()'s effect on processes. The currently
executing subroutine is immediately ended and replaced with a call to
the goto'd subroutine. Even the callstack is modified so that no one
is aware the original subroutine was ever called. Again, this is
almost exclusively used in Autoloading, not in "normal" programming
design.
The reasons not to use goto have been documented as far back as 1968
(no, that's not a typo). Do a google search for the classic paper "Go
To Statement Considered Harmful".
For more information on Perl's specific variant of goto, read:
perldoc -f goto
Paul Lalli
"Paul Lalli"
>Ed Jay wrote:
>> "Paul Lalli"
>>
>> >Ed Jay wrote:
>> >> I'm fairly new to Perl programming, but I'm no stranger to coding in
>> >> machine language.
>> >>
>> >> I've noticed that in almost every Perl instruction book, web-based
>> >> tutorial and others' scripts I've looked at, there is very little, if any,
>> >> use of 'goto Label' which are similar to [conditional] jumps.
>> >>
>> >> Is there some reason why 'goto' and 'labels' aren't common in Perl?
>> >
>> >Because using goto* is a sign of horrendous programming. If you feel
>> >the need to use goto, you probably made a very horrific algorithmic
>> >decision. This is not unique to Perl, but is true of pretty much any
>> >language of higher level than Assembler.
>> >
>>
>> I'm not sure I understand what you mean by 'horrendous programming' or
>> 'horrific algorithm.'
>>
>> What is so horrendous or horrific about, e.g.:
>>
>> if ($x == 0) {goto NO_X}
>>
>> versus
>>
>> if ($x != 0) {do the next task}
>> else {yada}
>
>Because NO_X could be defined *anywhere* in the file, or even not
>defined at all. And then the program flow from wherever NO_X is
>defined has no guaranteed means of returning from whence it came. It
>makes maintaining and reading code absurdly more difficult than it has
>to be.
>
>> >* I mean, of course, the goto LABEL form of the word. Perl has another
>> >kind of goto, which is quite common and useful, in which you can
>> >terminate the current subroutine and immediately jump into another
>> >subroutine. This is used most commonly in auto-loading methods for
>> >classes.
>> You mentioned using goto to branch from one subroutine to another. Is
>> there an inherent conflict of some sort between this and using 'goto
>> LABEL?'
>
>No, I did not. I mentioned the goto &sub form being used to replace
>one subroutine call with another. There is no "branching" involved.
>It is analogous to exec()'s effect on processes. The currently
>executing subroutine is immediately ended and replaced with a call to
>the goto'd subroutine. Even the callstack is modified so that no one
>is aware the original subroutine was ever called. Again, this is
>almost exclusively used in Autoloading, not in "normal" programming
>design.
Sorry for my misinterpretation. I stand corrected.
>
>The reasons not to use goto have been documented as far back as 1968
>(no, that's not a typo). Do a google search for the classic paper "Go
>To Statement Considered Harmful".
>
>For more information on Perl's specific variant of goto, read:
>perldoc -f goto
>
Thanks for the reference to Dijkstra's paper. I understand exactly why
it's dangerous to employ goto.
I'm also grateful that Mr. Dijkstra finishes by saying, "The exercise to
translate an arbitrary flow diagram more or less mechanically into a
jump-less one, however, is not to be recommended." :-)
I can see why, as Dijkstra puts it, 'unbridled use is asking for trouble;'
however, I'm using it sparingly and my labels are within three or four
lines of code. It's hard to get lost, but time to reconsider rewriting.
Thanks, Paul.
--
Ed Jay (remove M to respond by email)
In message <8nmoq11oucok0ksj5rlljdbjcbhhuev7pm@4ax.com>
Ed Jay
> I can see why, as Dijkstra puts it, 'unbridled use is asking for trouble;'
> however, I'm using it sparingly and my labels are within three or four
> lines of code. It's hard to get lost, but time to reconsider rewriting.
I don't know how perl handles goto, but I know that with BASIC the GOTO
command actually slows a program down.
When a program encounters something like REPEAT, the address is put on a
stack and when the UNTIL is reached the program "knows" to jump back to the
REPEAT. However when GOTO is encountered the program simply starts at the
beginning and searches through the program until the required line number is
reached. This means that the following program A will execute faster than
program B (assuming that the lines in between are all filled).
A: B:
10 REPEAT 10 REPEAT
1000 GOTO10 20 GOTO 1000
1010 UNTIL FALSE 1000 UNTIL FALSE
Ken Down
--
================ ARCHAEOLOGICAL DIGGINGS ===============
| Australia's premiere archaeological magazine |
| http://www.diggingsonline.com |
========================================================
Ed Jay wrote:
> I'm fairly new to Perl programming, but I'm no stranger to coding in
> machine language.
>
> I've noticed that in almost every Perl instruction book, web-based
> tutorial and others' scripts I've looked at, there is very little, if any,
> use of 'goto Label' which are similar to [conditional] jumps.
>
> Is there some reason why 'goto' and 'labels' aren't common in Perl?
Yes. The 'next', 'last' and 'redo' keywords inside
loop constructs make 'goto' unnecessary.
linux% cat no-goto.pl
#!/usr/bin/perl
print "\@ARGV = (@ARGV)\n";
for my $arg (@ARGV) {
print "Start '$arg'\n";
$arg .= 'REDO' and redo if $arg eq 'XYZ';
next if $arg eq 'NEXT';
last if $arg eq 'QUIT';
print "End '$arg'\n";
} continue {
print "continuing with $arg\n";
}
print "Hit either end of ARGV or 'QUIT'\n";
linux% ./no-goto.pl one two DUMMY four XYZ six QUIT eight nine
@ARGV = (one two DUMMY four XYZ six QUIT eight nine)
Start 'one'
End 'one'
continuing with one
Start 'two'
End 'two'
continuing with two
Start 'NEXT'
continuing with NEXT
Start 'four'
End 'four'
continuing with four
Start 'XYZ'
Start 'XYZREDO'
End 'XYZREDO'
continuing with XYZREDO
Start 'six'
End 'six'
continuing with six
Start 'QUIT'
Hit either end of ARGV or 'QUIT'
Ed Jay wrote:
> I'm fairly new to Perl programming, but I'm no stranger to coding in
> machine language.
Machine language = programming in octal and hex.
Assembler = translates assembly language into machine language.
Macro assembler = assembler with pseudo-ops to define and invoke
macros, which can be a lot more sophisticated than a pre-processor.
The great thing about MACRO-10, the macro assembly language on the
36-bit PDP-10, was the power of its macros. Even though the
language did not have if-then-else constructs, it was possible
to define macros that did. Using them, it was possible to
eliminate all the GOTO statements in the source code. (They
would still be in use when the macros were expanded, but they
would no longer appear in the source code.)
Once you leave the realm of machine language and assembly language
and get into macros and higher-level languages, GOTO is not necessary.
-Joe
Joe Smith
>Ed Jay wrote:
>> I'm fairly new to Perl programming, but I'm no stranger to coding in
>> machine language.
>
>Machine language = programming in octal and hex.
>Assembler = translates assembly language into machine language.
>Macro assembler = assembler with pseudo-ops to define and invoke
>macros, which can be a lot more sophisticated than a pre-processor.
>
>The great thing about MACRO-10, the macro assembly language on the
>36-bit PDP-10, was the power of its macros. Even though the
>language did not have if-then-else constructs, it was possible
>to define macros that did. Using them, it was possible to
>eliminate all the GOTO statements in the source code. (They
>would still be in use when the macros were expanded, but they
>would no longer appear in the source code.)
>
>Once you leave the realm of machine language and assembly language
>and get into macros and higher-level languages, GOTO is not necessary.
>
Perhaps not necessary, I agree, but convenient for simple jumps, although
I learned years ago to never use goto to exit a subroutine or loop. I
don't pretend to understand the nuances of high-level languages, but in
machine or assembler language, doing so requires maintenance of a registry
stack, which is just too easy to screw up and often very difficult to
debug.
--
Ed Jay (remove M to respond by email)
Kendall K. Down wrote:
> I don't know how perl handles goto, but I know that with BASIC the GOTO
> command actually slows a program down.
>However when GOTO is encountered the program simply starts at the
> beginning and searches through the program until the required line number is
> reached.
Perl is nothing like that. It has a compile phase and a run phase.
At the end of the compile phase it is completely done reading the
source file; it never does a sequential search through program
statements. GOTO and such jump directly to the appropriate location
in the byte code.
-Joe
Ed Jay wrote:
> I learned years ago to never use goto to exit a subroutine or loop. I
> don't pretend to understand the nuances of high-level languages, but in
> machine or assembler language, doing so requires maintenance of a registry
> stack, which is just too easy to screw up and often very difficult to
> debug.
Perl recovers from that with just a warning.
perl -wle 'foo($_) for (1..3); sub foo {next if $_[0] == 2;}'
Exiting subroutine via next at -e line 1.
In message
Joe Smith
> Perl is nothing like that. It has a compile phase and a run phase.
> At the end of the compile phase it is completely done reading the
> source file; it never does a sequential search through program
> statements. GOTO and such jump directly to the appropriate location
> in the byte code.
Thanks. I wondered if it was something like that. GOTO is still a bad idea,
mind.
Ken Down
--
================ ARCHAEOLOGICAL DIGGINGS ===============
| Australia's premiere archaeological magazine |
| http://www.diggingsonline.com |
========================================================