--0016363b7c1218eb3a04a0d85a64
Content-Type: text/plain; charset=ISO-8859-1

I'm writing a script for work that navigates users through a complex
decision-making tree, where decisions are made based on some fairly in-depth
processing of data entered by the user. The script runs really well, does
exactly what we need it to do. I'm having some trouble with the humans
using it making data entry errors. A lot of these are caught by code I've
included to prompt the user to re-enter data when what they've entered
doesn't make sense (e.g., patient weight exceeding 250 kg., diastolic blood
pressure values that include non-numeric characters). Some errors aren't
caught by the script because they're not obvious, and it's not being noticed
by a human until several steps later.

What I want to do is be able to allow the user to return to a prior step,
but I'm having trouble figuring out how to make that work using last or
next, or a control loop. I could pry make clever use of control loops in a
smaller script, but we're talking nearly 100 decisions in the tree. I never
bothered to learn how to use goto because it's deprecated (or on it's way?),
but it seems like this would be a good place to use it. At the same time, I
understand that use of goto is akin to sleeping with your sister among most
programmers in the Perl programming community.

I'd like to be able to share some code here, but the people who sign my
checks have asked me not to.

Can anyone point me in the right direction? Thanks for any help.

OC.

--0016363b7c1218eb3a04a0d85a64--

>>>>> "OC" == Owen Chavez <owen.chavez314159 [at] gmail.com> writes:

OC> I'm writing a script for work that navigates users through a
OC> complex decision-making tree, where decisions are made based on
OC> some fairly in-depth processing of data entered by the user. The
OC> script runs really well, does exactly what we need it to do. I'm
OC> having some trouble with the humans using it making data entry
OC> errors. A lot of these are caught by code I've included to prompt
OC> the user to re-enter data when what they've entered doesn't make
OC> sense (e.g., patient weight exceeding 250 kg., diastolic blood
OC> pressure values that include non-numeric characters). Some errors
OC> aren't caught by the script because they're not obvious, and it's
OC> not being noticed by a human until several steps later.

OC> What I want to do is be able to allow the user to return to a
OC> prior step, but I'm having trouble figuring out how to make that
OC> work using last or next, or a control loop. I could pry make
OC> clever use of control loops in a smaller script, but we're talking
OC> nearly 100 decisions in the tree. I never bothered to learn how
OC> to use goto because it's deprecated (or on it's way?), but it
OC> seems like this would be a good place to use it. At the same
OC> time, I understand that use of goto is akin to sleeping with your
OC> sister among most programmers in the Perl programming community.

keep away from goto. period. perl is very flexible and can easily be
coded to never need gotos.

OC> I'd like to be able to share some code here, but the people who sign my
OC> checks have asked me not to.

my suggestion is to use subs. make each question into a sub call. if the
call is generic enough you can use one sub for all the questions. you
just pass it a hash and args that deal with the question. it could even
be an object which holds all the data and a method. that isn't
important. now you have to get into flow control at a higher level. this
becomes what is known as a state machine (google for tons on this
classic CS topic).

a simple way to do this is to make each question into a hash. it
contains the question, maybe some custom subs that check validity ( they
can be anon subs or code refs to named subs). you can even have an array
of them (stored in an anon array in the hash). you just put all the
needed info about a question in a single hash. you make a few of these
hashes to start and then write the driver code. when that is all working
well, you can make all the rest of the question hashes.

the next level is the driver code. this is passed a hash, it asks the
question, takes in the answer, runs the verify subs and if any of them
fails, it fails this sub call. the outer logic will then recall the same
question until the user enters good data. the driver logic can either
then go to the next question in the array of hashes or maybe
elsewhere. the next location could be in the hash (don't use numbers or
you will screw up when you insert a question later on) or in some
outside list of ordering. there are many ways to handle ordering in a
state machine.

what is good about this design is its simplicity and extreme
flexibility. the driver code can be modified to handle new variations
and options in the hash. you can jump from question to question with
different techniques.

if you need to see some examples of table driven code, look into the t/
dir in File::Slurp. the recently released version has a TestDriver.pm
module in t/ that does this very thing with an array of hashes. it just
loops over each one, deals with the various possible options, runs code,
checks results and errors and such. if all you want is a linear logic
flow of the questions, this is all you need.

anyhow, that should get started.

and your bosses are poopy heads if they think basic question/answer code
is so valuable. tell them i said this and will say it to their
faces. this is basic stuff and no way possibly proprietary or a money
making secret.

uri

--
Uri Guttman ------ uri [at] stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Hi all,

> =A0OC> I never bothered to learn how
> =A0OC> to use goto because it's deprecated (or on it's way?), but it
> =A0OC> seems like this would be a good place to use it. =A0At the same
> =A0OC> time, I understand that use of goto is akin to sleeping with your
> =A0OC> sister among most programmers in the Perl programming community.

Like Owen, I've come across many a recommendation AGAINST using goto
in Perl. And (like Owen?), I have yet to find one that explains
clearly the reasons arguing against its use.
If nothing else, it has made me very curious... Can any of the more
experienced programmers (ie. nearly everyone else on this list by my
standards) point to a good explanation as to why one should avoid goto
in Perl (or coding in general)? I looked around in perl-begin.org but
couldn't find anything obvious. Once again, I make my request from the
purest desire of learning Perl the best way I can.

Thanks Owen for bringing it up, and thanks everyone else in advance.

Mariano

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

>>>>> "MLC" =3D=3D Mariano Loza Coll <malozacoll [at] gmail.com> writes:

MLC> Hi all,
>> =A0OC> I never bothered to learn how
>> =A0OC> to use goto because it's deprecated (or on it's way?), but it
>> =A0OC> seems like this would be a good place to use it. =A0At the same
>> =A0OC> time, I understand that use of goto is akin to sleeping with yo=
ur
>> =A0OC> sister among most programmers in the Perl programming community.

MLC> Like Owen, I've come across many a recommendation AGAINST using goto
MLC> in Perl. And (like Owen?), I have yet to find one that explains
MLC> clearly the reasons arguing against its use.
MLC> If nothing else, it has made me very curious... Can any of the more
MLC> experienced programmers (ie. nearly everyone else on this list by my
MLC> standards) point to a good explanation as to why one should avoid go=
to
MLC> in Perl (or coding in general)? I looked around in perl-begin.org but
MLC> couldn't find anything obvious. Once again, I make my request from t=
he
MLC> purest desire of learning Perl the best way I can.

google for the term spaghetti code. read.

have you ever coded in assembler? or seen goto used a lot? if not, there
is no reason to learn about goto these days. seriously.

this has nothing to do with perl itself. goto is a bad concept from very
long ago in programming. just read about it on the web and you will get
more than you can learn here.

uri

--
Uri Guttman ------ uri [at] stemsystems.com -------- http://www.sysarch.com =
--
----- Perl Code Review , Architecture, Development, Training, Support ----=
--
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com -------=
--

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Wed, 13 Apr 2011 21:57:53 -0700, Mariano Loza Coll wrote:

> Hi all,
>
>> =C2=A0OC> I never bothered to learn how
>> =C2=A0OC> to use goto because it's deprecated (or on it's way?), but i=
t OC>
>> =C2=A0seems like this would be a good place to use it. =C2=A0At the sa=
me OC>
>> =C2=A0time, I understand that use of goto is akin to sleeping with you=
r OC>
>> =C2=A0sister among most programmers in the Perl programming community.
>
> Like Owen, I've come across many a recommendation AGAINST using goto in
> Perl. And (like Owen?), I have yet to find one that explains clearly th=
e
> reasons arguing against its use. If nothing else, it has made me very
> curious... Can any of the more experienced programmers (ie. nearly
> everyone else on this list by my standards) point to a good explanation
> as to why one should avoid goto in Perl (or coding in general)? I looke=
d
> around in perl-begin.org but couldn't find anything obvious. Once again=
,
> I make my request from the purest desire of learning Perl the best way =
I
> can.

Here is the definitive explanation: http://www.cs.utexas.edu/users/EWD/
ewd02xx/EWD215.PDF .

I have never, ever, seen a situation where the use of goto would have
resulted in clearer code. Considering it has always indicated to me that=

the person considering it has not understood the problem properly or
modeled its solution well. Goto simply is not part of the vocabulary of
clear coding.

--
Peter Scott
http://www.perlmedic.com/ http://www.perldebugged.com/
http://www.informit.com/store/product.aspx?isbn=3D0137001274
http://www.oreillyschool.com/courses/perl3/

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

>>>>> "PS" == Peter Scott <Peter [at] PSDT.com> writes:

PS> On Wed, 13 Apr 2011 21:57:53 -0700, Mariano Loza Coll wrote:

>> Like Owen, I've come across many a recommendation AGAINST using goto in
>> Perl. And (like Owen?), I have yet to find one that explains clearly the
>> reasons arguing against its use. If nothing else, it has made me very
>> curious... Can any of the more experienced programmers (ie. nearly
>> everyone else on this list by my standards) point to a good explanation
>> as to why one should avoid goto in Perl (or coding in general)? I looked
>> around in perl-begin.org but couldn't find anything obvious. Once again,
>> I make my request from the purest desire of learning Perl the best way I
>> can.

PS> Here is the definitive explanation: http://www.cs.utexas.edu/users/EWD/
PS> ewd02xx/EWD215.PDF .

having heard about that article for many years it was interesting to
read it. it may be over the head of some members here but useful to read
anyway. it doesn't go into any practical reasons why goto is bad. it
just says the logical complexity (his index data) goes way up with gotos
but stays reasonable with high level flow controls
(if/else/while/sub/etc.).


PS> I have never, ever, seen a situation where the use of goto would have
PS> resulted in clearer code. Considering it has always indicated to me that
PS> the person considering it has not understood the problem properly or
PS> modeled its solution well. Goto simply is not part of the vocabulary of
PS> clear coding.

agreed. but teaching how to avoid gotos is important too. a classic
newbie style was to use many boolean variables and loop and check them
all over and over. that is just as bad as using gotos.

here are my rules on this and they illustrate why goto is bad without
the complexity issues brought up in that article.

code is for people, not computers.
code is for other people, not yourself.

anyone can (eventually) code up a program that works. better programmers
code so other programmers can understand what they were doing and can
easily maintain that code. gotos make that hard to do as they break all
sorts of rules like isolation and cause action at a distance issues. you
write subs and modules to form abstract operations that can be
understood as single entities. goto makes everything into one large
fugly program where anything goes (pun intended) anywhere.

uri

--
Uri Guttman ------ uri [at] stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Hi Uri and Peter,

On Thursday 14 Apr 2011 09:15:35 Uri Guttman wrote:
> >>>>> "PS" == Peter Scott <Peter [at] PSDT.com> writes:
> PS> On Wed, 13 Apr 2011 21:57:53 -0700, Mariano Loza Coll wrote:
> >> Like Owen, I've come across many a recommendation AGAINST using goto
> >> in Perl. And (like Owen?), I have yet to find one that explains
> >> clearly the reasons arguing against its use. If nothing else, it has
> >> made me very curious... Can any of the more experienced programmers
> >> (ie. nearly everyone else on this list by my standards) point to a
> >> good explanation as to why one should avoid goto in Perl (or coding
> >> in general)? I looked around in perl-begin.org but couldn't find
> >> anything obvious. Once again, I make my request from the purest
> >> desire of learning Perl the best way I can.
>
> PS> Here is the definitive explanation:
> http://www.cs.utexas.edu/users/EWD/ PS> ewd02xx/EWD215.PDF .
>
> having heard about that article for many years it was interesting to
> read it. it may be over the head of some members here but useful to read
> anyway. it doesn't go into any practical reasons why goto is bad. it
> just says the logical complexity (his index data) goes way up with gotos
> but stays reasonable with high level flow controls
> (if/else/while/sub/etc.).
>

Regarding the "Goto statement considered harmful" myth, see what I wrote about
it here:

http://discuss.fogcreek.com/joelonsoftware3/default.asp?cmd= show&ixPost=78092

Quoting my post:

[QUOTE]

The entire "GOTO statement considered harmful" is quite a myth. Granted,
Dijkstra wrote an article with this title, and many people agreed with him.
But, on the other hand, some people have demonstrated that it is possible to
do structured programming with goto statements, and sometimes even better with
them than without them.

For example, Don Knuth wrote an article "Structured Programming Using Goto
Statements" (rumouredly sub-titled "'Goto Statement Considered Harmful'
Considered Harmful") in which he deomnstrated exactly that. And I take this
view as well.

Don't get me wrong, I don't advocate a goto-spaghetti, like I once saw in old
BASIC programs. But goto's have their use.

When programming in C, I find myself using goto's whenever I feel the need to.
This occurs less in Perl where I have other powerful constructs.

[/QUOTE]

There are other useful comments there.

Regards,

Shlomi Fish

--
------------------------------------------------------------ -----
Shlomi Fish http://www.shlomifish.org/
The Case for File Swapping - http://shlom.in/file-swap

http://en.wikipedia.org/wiki/Evil redirects to XSLT.

Please reply to list if it's a mailing list post - http://shlom.in/reply .

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 11-04-14 12:57 AM, Mariano Loza Coll wrote:
> I have yet to find one that explains
> clearly the reasons arguing against its use.

It's a religious thing. It is far better to hide your gotos in a state
machine than to expose them to light.

Example of a state machine with hidden gotos:

my $done = 0;
while( !$done ){
...
if( some_condition() ){
...
$done = 1;
...
}
...
}


--
Just my 0.00000002 million dollars worth,
Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

>>>>> "SF" == Shlomi Fish <shlomif [at] iglu.org.il> writes:

SF> On Thursday 14 Apr 2011 09:15:35 Uri Guttman wrote:
>> >>>>> "PS" == Peter Scott <Peter [at] PSDT.com> writes:

PS> Here is the definitive explanation:
>> http://www.cs.utexas.edu/users/EWD/ PS> ewd02xx/EWD215.PDF .
>>
>> having heard about that article for many years it was interesting to
>> read it. it may be over the head of some members here but useful to read
>> anyway. it doesn't go into any practical reasons why goto is bad. it
>> just says the logical complexity (his index data) goes way up with gotos
>> but stays reasonable with high level flow controls
>> (if/else/while/sub/etc.).
>>

SF> Quoting my post:

SF> [QUOTE]

SF> The entire "GOTO statement considered harmful" is quite a
SF> myth. Granted, Dijkstra wrote an article with this title, and many
SF> people agreed with him. But, on the other hand, some people have
SF> demonstrated that it is possible to do structured programming with
SF> goto statements, and sometimes even better with them than without
SF> them.

demonstrations don't mean a thing. i did tons of assembler coding and
was even object oriented and my goto use was cleaner than most high
level coders. i still wouldn't want to go back to that.

SF> For example, Don Knuth wrote an article "Structured Programming
SF> Using Goto Statements" (rumouredly sub-titled "'Goto Statement
SF> Considered Harmful' Considered Harmful") in which he deomnstrated
SF> exactly that. And I take this view as well.

knuth was making more of a joke with that. also he is knuth. you are not
knuth.


SF> Don't get me wrong, I don't advocate a goto-spaghetti, like I once
SF> saw in old BASIC programs. But goto's have their use.

wrong. especially wrong for newbies. even more wrong for newbies
learning perl.

SF> When programming in C, I find myself using goto's whenever I feel
SF> the need to. This occurs less in Perl where I have other powerful
SF> constructs.

then you don't know how to code well in c. it may not be as nice as perl
for some flow control things but goto is never needed in c either. i
have seen it used and there are always better ways to code it than with
gotos. you just need to know other techniques and none of them are
convoluted. a better design helps too.

uri

--
Uri Guttman ------ uri [at] stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

(Sorry, Uri, meant to reply to the list...)

On Thu, Apr 14, 2011 at 10:47 AM, Uri Guttman <uri [at] stemsystems.com> wrote:
> then you don't know how to code well in c. it may not be as
> nice as perl for some flow control things but goto is never
> needed in c either. i have seen it used and there are always
> better ways to code it than with gotos. you just need to know
> other techniques and none of them are convoluted. a better
> design helps too.

I often use gotos in C for error handling within a function. If
you're allocating resources and something later on fails then you
usually want (or need) to clean up those resources before
returning. I've seen a lot of people duplicate the same cleanup
code over and over again. I hate doing that. Goto makes it much
cleaner. Just because you can make spaghetti with goto doesn't
mean goto always has to make spaghetti. You do need to be careful
though and assess any given situation carefully.

That said, I think the clean uses for goto in Perl are probably
much less common, if they exist at all. Perl has plenty of flow
control features to probably eliminate any advantages that goto
might have had. You should never look for opportunities to use
goto in any language though. You should understand how goto works
so that you can recognize where it /might/ benefit the code. Just
be careful to use it for the right reasons.


--
Brandon McCaig <http://www.bamccaig.com/> <bamccaig [at] gmail.com>
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software <http://www.castopulence.org/> <bamccaig [at] castopulence.org>

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 11-04-14 12:52 PM, Brandon McCaig wrote:
> I often use gotos in C for error handling within a function. If
> you're allocating resources and something later on fails then you
> usually want (or need) to clean up those resources before
> returning. I've seen a lot of people duplicate the same cleanup
> code over and over again. I hate doing that. Goto makes it much
> cleaner. Just because you can make spaghetti with goto doesn't
> mean goto always has to make spaghetti. You do need to be careful
> though and assess any given situation carefully.

You can replace the goto with the correct use of setjmp(3) and
longjmp(3). These are the exception handlers in C.


--
Just my 0.00000002 million dollars worth,
Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

>>>>> "BM" == Brandon McCaig <bamccaig [at] gmail.com> writes:

BM> On Thu, Apr 14, 2011 at 10:47 AM, Uri Guttman <uri [at] stemsystems.com> wrote:
>> then you don't know how to code well in c. it may not be as
>> nice as perl for some flow control things but goto is never
>> needed in c either. i have seen it used and there are always
>> better ways to code it than with gotos. you just need to know
>> other techniques and none of them are convoluted. a better
>> design helps too.

BM> I often use gotos in C for error handling within a function. If
BM> you're allocating resources and something later on fails then you
BM> usually want (or need) to clean up those resources before
BM> returning. I've seen a lot of people duplicate the same cleanup
BM> code over and over again. I hate doing that. Goto makes it much
BM> cleaner. Just because you can make spaghetti with goto doesn't
BM> mean goto always has to make spaghetti. You do need to be careful
BM> though and assess any given situation carefully.

that can still be done very cleanly without gotos. one technique is to
collect all the resources into a structure as you initialize. at any
point when it fails, you return to an outer func which is given
pass/fail results. if it failed, the outer func can free up the
resources in the struct (which it has originally). simple and
clean. also a better way to deal with error handling than goto the end
for cleanup. subs make for useful flow control beyond simple abstraction
and reuse.

it takes a certain mindset for a coder to see how to factor out error
handling into a higher sub but it isn't that hard. goto just shouldn't
be in your vocabulary. there is no reason for it at all in any decent
language, especially perl.

note: perl's magic goto doesn't count as it really isn't a classic
goto. it is a sub replacement call.

uri

--
Uri Guttman ------ uri [at] stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Apr 14, 2011, at 10:15 AM, Uri Guttman wrote:

> goto just shouldn't be in your vocabulary. there is no reason for it =
at all in any decent language, especially perl.

I've been following this thread and I'm just curious. If goto =
is so bad, why did they add it to Perl?

Marc=

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 11-04-14 01:47 PM, sono-io [at] fannullone.us wrote:
> On Apr 14, 2011, at 10:15 AM, Uri Guttman wrote:
>
>> goto just shouldn't be in your vocabulary. there is no reason for it at all in any decent language, especially perl.
>
> I've been following this thread and I'm just curious. If goto is so bad, why did they add it to Perl?
>
> Marc

As I said, it's a religious thing. By adding a goto to your language,
you push the debate over its use out of your mailbox and into the public
forum, which you can ignore when you want.


--
Just my 0.00000002 million dollars worth,
Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Thu, 14 Apr 2011 14:05:54 +0300, Shlomi Fish wrote:

> Hi Uri and Peter,
>>
> Regarding the "Goto statement considered harmful" myth, see what I wrot=
e
> about it here:

"Myth" is generally used to descibe something widely thought to be true
that is in fact false. The assertion that goto is harmful has hardly bee=
n
proven false.

> The entire "GOTO statement considered harmful" is quite a myth. Granted=
,
> Dijkstra wrote an article with this title, and many people agreed with
> him. But, on the other hand, some people have demonstrated that it is
> possible to do structured programming with goto statements, and
> sometimes even better with them than without them.

Of course you *can* replace control structures with GOTOs, they all
compile to machine code that uses either GOTO or program counter stacks
anyway. The reason we even have GOTO in languages is because the first
ones were assembler code that reflected the machine code. Ancient histor=
y.

> For example, Don Knuth wrote an article "Structured Programming Using
> Goto Statements" (rumouredly sub-titled "'Goto Statement Considered
> Harmful' Considered Harmful") in which he deomnstrated exactly that. An=
d
> I take this view as well.

Knuth's article is at http://citeseerx.ist.psu.edu/viewdoc/download?
doi=3D10.1.1.103.6084&rep=3Drep1&type=3Dpdf . He doesn't call Dijkstra's=

statement harmful. He spends half the paper discussing how to remove
GOTOs and then brings up some cases where using them would make certain
code run faster, which in 1974 was often more important than programmer
time but almost always isn't now. Knuth also had spent time developing
languages like MIX that needed GOTO; MIX was a hypothetical machine code
(sort of an early Parrot). It included card punch devices and drum
units. So he was used to writing programs that had to use GOTO. Only
assembly programmers these days still need it.

Like I said: I've never seen code that was clearer with a GOTO than
without it. Shorter, maybe; faster, maybe, but not clearer. Even if I
ever did, it would be the exception that proved an unusually universal
rule. Any possible justification for a GOTO would be so arcane that it i=
s
counterproductive to suggest it at all in a beginner's group.

--
Peter Scott
http://www.perlmedic.com/ http://www.perldebugged.com/
http://www.informit.com/store/product.aspx?isbn=3D0137001274
http://www.oreillyschool.com/courses/perl3/

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Hi Uri,

On Thursday 14 Apr 2011 17:47:02 Uri Guttman wrote:
> >>>>> "SF" == Shlomi Fish <shlomif [at] iglu.org.il> writes:
> SF> On Thursday 14 Apr 2011 09:15:35 Uri Guttman wrote:
> >> >>>>> "PS" == Peter Scott <Peter [at] PSDT.com> writes:
> PS> Here is the definitive explanation:
> >> http://www.cs.utexas.edu/users/EWD/ PS> ewd02xx/EWD215.PDF .
> >>
> >> having heard about that article for many years it was interesting to
> >> read it. it may be over the head of some members here but useful to
> >> read anyway. it doesn't go into any practical reasons why goto is
> >> bad. it just says the logical complexity (his index data) goes way up
> >> with gotos but stays reasonable with high level flow controls
> >> (if/else/while/sub/etc.).
>
> SF> Quoting my post:
>
> SF> [QUOTE]
>
> SF> The entire "GOTO statement considered harmful" is quite a
> SF> myth. Granted, Dijkstra wrote an article with this title, and many
> SF> people agreed with him. But, on the other hand, some people have
> SF> demonstrated that it is possible to do structured programming with
> SF> goto statements, and sometimes even better with them than without
> SF> them.
>
> demonstrations don't mean a thing. i did tons of assembler coding and
> was even object oriented and my goto use was cleaner than most high
> level coders. i still wouldn't want to go back to that.

Demonstrations do mean something.

>
> SF> For example, Don Knuth wrote an article "Structured Programming
> SF> Using Goto Statements" (rumouredly sub-titled "'Goto Statement
> SF> Considered Harmful' Considered Harmful") in which he deomnstrated
> SF> exactly that. And I take this view as well.
>
> knuth was making more of a joke with that. also he is knuth. you are not
> knuth.

His "Structured Programming Using Goto Statements" was not a joke - it was a
serious article and you can find it here:

http://www.google.com/search?q=structured%20programming%20go to%20statements

( The "'Goto statement Considered Harmful' Considered Harmful" article was
someone else, BTW).

I may not be Prof. Knuth (no one except him is or was), but I may still agree
with him, and can cite his papers for support. And you shouldn't dismiss what
I say as "You are not Knuth" because this is an
http://en.wikipedia.org/wiki/Ad_hominem .

And as someone on the comments on the post there (which you should read) said,
the idea for the title "Goto statement considered harmful" was introduced by
Dijkstra's editor, and Dijkstra did not mean that any and all use of goto is
bad.

>
>
> SF> Don't get me wrong, I don't advocate a goto-spaghetti, like I once
> SF> saw in old BASIC programs. But goto's have their use.
>
> wrong. especially wrong for newbies. even more wrong for newbies
> learning perl.

In Perl, I don't encourage people using goto statements, and I did not find a
use for them in Perl, yet. But I don't rule out that they have legitimate use
in other languages.

>
> SF> When programming in C, I find myself using goto's whenever I feel
> SF> the need to. This occurs less in Perl where I have other powerful
> SF> constructs.
>
> then you don't know how to code well in c.

Thanks for the compliment. ;-)

> it may not be as nice as perl
> for some flow control things but goto is never needed in c either.

Thanks for avoiding over-generalisations. ;-)

> i
> have seen it used and there are always better ways to code it than with
> gotos. you just need to know other techniques and none of them are
> convoluted. a better design helps too.
>

Well, some use cases for goto in C:

1. Breaking out of more outer loop (as there is no "continue label;" or "break
label;" in C:

<CODE>
for (i=0 ; i < len ; i++)
{
for (j = 0....
{
if (func(i, j)
{
goto after_loops;
}
}
}

after_loops:
</CODE>

2. Another is the de-allocation of resources at the end of the function with
checking for failure:

<CODE>
int alloc_stuff(struct_t * * ref)
{
.
.
.
if (!first = malloc(...))
{
return FAILURE;
}

if (!second = malloc(....))
{
goto first_free;
}

if (!third = malloc(...))
{
goto second_free;
}

.
.
.
*ref = mystruct_ptr;
return SUCCESS;

second_free:
free(second);
first_free:
free(first);

return FAILURE;
}
</CODE>

I should note that in C "continue", "break", and a pre-mature "return" may
also be considered as pseudo-gotos.

Regards,

Shlomi Fish

--
------------------------------------------------------------ -----
Shlomi Fish http://www.shlomifish.org/
Interview with Ben Collins-Sussman - http://shlom.in/sussman

I'd do Windows-- , but this may result in an integer underflow.
-- an Israeli Linuxer.

Please reply to list if it's a mailing list post - http://shlom.in/reply .

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 11-04-14 02:36 PM, Shlomi Fish wrote:
> On Thursday 14 Apr 2011 17:47:02 Uri Guttman wrote:
>> > then you don't know how to code well in c.
> Thanks for the compliment.;-)
>
>> > it may not be as nice as perl
>> > for some flow control things but goto is never needed in c either.
> Thanks for avoiding over-generalisations.;-)
>

See, the religious flame wars have broken out. Time to stop, people.
Let's all agree to disagree. :)


--
Just my 0.00000002 million dollars worth,
Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Thu, Apr 14, 2011 at 1:15 PM, Uri Guttman <uri [at] stemsystems.com> wrote:
>>>>>> "BM" =3D=3D Brandon McCaig <bamccaig [at] gmail.com> writes:
> =C2=A0BM> I often use gotos in C for error handling within a function. If
> =C2=A0BM> you're allocating resources and something later on fails then y=
ou
> =C2=A0BM> usually want (or need) to clean up those resources before
> =C2=A0BM> returning. I've seen a lot of people duplicate the same cleanup
> =C2=A0BM> code over and over again. I hate doing that. Goto makes it much
> =C2=A0BM> cleaner. Just because you can make spaghetti with goto doesn't
> =C2=A0BM> mean goto always has to make spaghetti. You do need to be caref=
ul
> =C2=A0BM> though and assess any given situation carefully.
>
> that can still be done very cleanly without gotos. one technique is to
> collect all the resources into a structure as you initialize. at any
> point when it fails, you return to an outer func which is given
> pass/fail results. if it failed, the outer func can free up the
> resources in the struct (which it has originally). simple and
> clean. also a better way to deal with error handling than goto the end
> for cleanup. subs make for useful flow control beyond simple abstraction
> and reuse.

That seems like a lot of extra code to achieve the same result.
An extra structure for every function, or at least every related
function, and if you don't want to duplicate the cleanup code
then also an extra function for every such structure to release
its resources... This is how I envision your suggestion in code:

result_t * result =3D foo_release(foo(arg1, arg2));

if(result =3D=3D 0)
{
fprintf(stderr, "Failed to foo.\n");
return 1;
}

Or maybe:

foo_result_t * foo_result =3D foo(arg1, arg2);

if(!foo_result->success)
{
foo_result_release_all(&foo_result);
fprintf(stderr, "Failed to foo.\n");
return 1;
}

result_t * result =3D foo_result_release(&foo_result);

Is this what you had in mind or something completely different?

It seems to me that it's much simpler and more reliable to just
clean it up in one place, inside of the function that failed.
Returning the bad state to the caller unnecessarily puts the
responsibility to clean things up on the caller. So instead of
having a little bit of fuss in one self-contained box you'd be
spreading fuss throughout the entire code base. :-/

I imagine that you are a more experienced C programmer than I am,
but nevertheless I think the goto approach can be much simpler
sometimes. Simple and clean are usually synonymous in code. With
sufficiently short functions (and longer ones should be broken up
anyway) it's easy to see the simple goto error handling and the
whole thing is self contained within that function. The C
functions that this applies to usually look like this for me:

result_t * foo(arg1_t arg1, arg2_t arg2)
{
result_t * result =3D 0;

// Main body... If a non-fatal terminating condition is met
// (i.e., the function is successful, but finished early)
// then goto finally. If a fatal terminating condition is met
// then goto catch.

finally:
// Cleanup temporary resources and ignore unallocated ones
// (that is, no matter where in the function the goto is
// called it should work properly and not crash the
// application.

return result;

catch:
// Cleanup all allocated resources and ignore unallocated
// ones (that is, no matter where in the function the goto is
// called it should work properly and not crash the
// application)...
}

It's modeled somewhat after the try...catch...finally construct
found in modern C-like languages (e.g., C#). The "finally"
section always executes. The "catch" section only executes when
an unrecoverable error occurs.


--
Brandon McCaig <http://www.bamccaig.com/> <bamccaig [at] gmail.com>
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software <http://www.castopulence.org/> <bamccaig [at] castopulence=
..org>

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 14/04/2011 19:36, Shlomi Fish wrote:
>
> I should note that in C "continue", "break", and a pre-mature "return" may
> also be considered as pseudo-gotos.

Indeed. Funtionally, Perl has many keywords that transfer control to a
different place in the code (next, break, continue, return, if, elsif,
redo, last, exit, die come to mind) and so are equivalent to goto. But
they have the difference that they 'go to' an implicit place, and are
used as terms to describe a process. goto, however, has no place in
structured code, as there is no indication of its purpose apart from a
(hopefully) well-chosen label.

High-level programming languages are meant to allow us to abstract our
solutions from the machine's execution of those solutions. We write in
terms of abstract concepts, and should be largely oblivious that
underneath the veneer the computer has a program counter and is
executing instructions one by one. All of the keywords that result in a
transfer of control to a different place are carefully chosen so that
they blend as seamlessly as possible into a narrative describing an
alogorithm: when we write 'if ($condition)' we should not be seeing
something that tests a value and transfers control to a different place
in the code depending on the result of that test, we should be seeing
sequence of operations that are performed - or not - depending on the
current conditions.

Writing 'goto' suddenly makes the program 'self-aware' so that it is
suddenly part of the data it is processing. You may argue that
subroutine calls do the same thing but, written well, they fall into the
same scheme as keywords whereby the contents of the subroutine and where
its code is placed can be ignored once it is written and debugged.
Object-oriented programming is very strong on this encapsulation, but I
believe it is and should be applied to procedural programming too.

I think the most common use of gotos is in abandoning a sequence of
steps, any of which may fail and make the rest of the sequence pointless
or impossible. If the language doesn't support a try/catch mechanism
(eval/die for older Perl) or it isn't practicable within the structure
of the program, there is always the possibility of combining the steps
into a subroutine and using 'return' to perform an implicit goto to the
end of the sequence.

A final note, perldoc perlsyn says

A loop's LABEL is not actually a valid target for a goto; it's just
the name of the loop.

and I am left wondering what this means, as I have had no problem
writing a 'goto' targetting such labels. I wonder if this is a mistake
in the documentation, or it is simply saying that such a goto is
deprecated?

Cheers all,

Rob

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

>>>>> "SF" == Shlomi Fish <shlomif [at] iglu.org.il> writes:

SF> Well, some use cases for goto in C:

SF> 1. Breaking out of more outer loop (as there is no "continue label;" or "break
SF> label;" in C:

SF> <CODE>
SF> for (i=0 ; i < len ; i++)
SF> {
SF> for (j = 0....
SF> {
SF> if (func(i, j)
SF> {
SF> goto after_loops;
SF> }
SF> }
SF> }

wrap the loops in a sub and return. no goto needed.

SF> 2. Another is the de-allocation of resources at the end of the
SF> function with checking for failure:

i gave a solution to this in another post. goto is not needed. this is a
crutch for poor coders. you design to not need such constructs. if you

SF> I should note that in C "continue", "break", and a pre-mature
SF> "return" may also be considered as pseudo-gotos.

huh? same as perl then.

uri

--
Uri Guttman ------ uri [at] stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

>>>>> "BM" == Brandon McCaig <bamccaig [at] gmail.com> writes:

BM> On Thu, Apr 14, 2011 at 1:15 PM, Uri Guttman <uri [at] stemsystems.com> wrote:

>> that can still be done very cleanly without gotos. one technique is to
>> collect all the resources into a structure as you initialize. at any
>> point when it fails, you return to an outer func which is given
>> pass/fail results. if it failed, the outer func can free up the
>> resources in the struct (which it has originally). simple and
>> clean. also a better way to deal with error handling than goto the end
>> for cleanup. subs make for useful flow control beyond simple abstraction
>> and reuse.

BM> That seems like a lot of extra code to achieve the same result.
BM> An extra structure for every function, or at least every related
BM> function, and if you don't want to duplicate the cleanup code
BM> then also an extra function for every such structure to release
BM> its resources... This is how I envision your suggestion in code:

BM> result_t * result = foo_release(foo(arg1, arg2));

BM> if(result == 0)
BM> {
BM> fprintf(stderr, "Failed to foo.\n");
BM> return 1;
BM> }

BM> Or maybe:

BM> foo_result_t * foo_result = foo(arg1, arg2);

BM> if(!foo_result->success)
BM> {
BM> foo_result_release_all(&foo_result);
BM> fprintf(stderr, "Failed to foo.\n");
BM> return 1;
BM> }

BM> result_t * result = foo_result_release(&foo_result);

BM> Is this what you had in mind or something completely different?

possibly. i haven't coded in c in too long (after 20 years of it). as i
said, design is more important and you can design around such issues and
not need goto to cleanup.

BM> It seems to me that it's much simpler and more reliable to just
BM> clean it up in one place, inside of the function that failed.
BM> Returning the bad state to the caller unnecessarily puts the
BM> responsibility to clean things up on the caller. So instead of
BM> having a little bit of fuss in one self-contained box you'd be
BM> spreading fuss throughout the entire code base. :-/

not always. i won't go further here as this is getting way off topic for
beginning perl. simple enough to say goto is never needed and good
designs don't need it either.

uri

--
Uri Guttman ------ uri [at] stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

At 23:00 +0300 14/04/2011, Shlomi Fish wrote:

>In Perl, I don't encourage people using goto statements, and I did not find a
>use for them in Perl, yet. But I don't rule out that they have legitimate use
>in other languages...
>
><CODE>
>int alloc_stuff(struct_t * * ref)
>{


Let's stick to Perl and stop bossing people around.



--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Thu, Apr 14, 2011 at 3:11 PM, Brandon McCaig <bamccaig [at] gmail.com> wrote:
> catch:
> =C2=A0 =C2=A0// Cleanup all allocated resources and ignore unallocated
> =C2=A0 =C2=A0// ones (that is, no matter where in the function the goto i=
s
> =C2=A0 =C2=A0// called it should work properly and not crash the
> =C2=A0 =C2=A0// application)...

I forgot to mention that the "catch" section would typically end with
"goto finally;". :)


--
Brandon McCaig <http://www.bamccaig.com/> <bamccaig [at] gmail.com>
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software <http://www.castopulence.org/> <bamccaig [at] castopulence=
..org>

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

>>>>> "s" == sono-io <sono-io [at] fannullone.us> writes:

s> On Apr 14, 2011, at 10:15 AM, Uri Guttman wrote:
>> goto just shouldn't be in your vocabulary. there is no reason for it at all in any decent language, especially perl.

s> I've been following this thread and I'm just curious. If goto
s> is so bad, why did they add it to Perl?

they is larry wall. and he made several mistakes over the design of perl
and almost of which he will plead guilty.

uri

--
Uri Guttman ------ uri [at] stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Thu, 14 Apr 2011 20:44:57 +0100, Rob Dixon wrote:
> [ Good arguments about goto ]
> A final note, perldoc perlsyn says
>
> A loop's LABEL is not actually a valid target for a goto; it's just
> the name of the loop.
>
> and I am left wondering what this means, as I have had no problem
> writing a 'goto' targetting such labels. I wonder if this is a mistake
> in the documentation, or it is simply saying that such a goto is
> deprecated?

Mistake by the look of it. To the discoverer go the rights of perlbug :)

--
Peter Scott
http://www.perlmedic.com/ http://www.perldebugged.com/
http://www.informit.com/store/product.aspx?isbn=3D0137001274
http://www.oreillyschool.com/courses/perl3/

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Thu, 14 Apr 2011 10:47:17 -0700, sono-io wrote:

> On Apr 14, 2011, at 10:15 AM, Uri Guttman wrote:
>
>> goto just shouldn't be in your vocabulary. there is no reason for it a=
t
>> all in any decent language, especially perl.
>
> I've been following this thread and I'm just curious. If goto is
so
> bad, why did they add it to Perl?

Perl's goto is pretty old. Larry was feeling permissive and in a frame
of mind to make BASIC programmers happy. He regrets it. The perldoc for=

goto says he has never found a reason to use it.

--
Peter Scott
http://www.perlmedic.com/ http://www.perldebugged.com/
http://www.informit.com/store/product.aspx?isbn=3D0137001274
http://www.oreillyschool.com/courses/perl3/

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

From: Uri Guttman

>>>>>> "SF" =3D=3D Shlomi Fish <shlomif [at] iglu.org.il> writes:
>
> SF> I should note that in C "continue", "break", and a pre-mature
> SF> "return" may also be considered as pseudo-gotos.
>
> huh? same as perl then.
>

I was going to stay out of this, but here I think I want to challenge
this assertion. Those three statements are controlled, and will
implicitly maintain the block that contains them. Moreover, the "return"
will manage exiting the block and subroutine and marshals the context
changes that implies. But "goto" is uncontrolled and ignores that
context, leaving the stack and related structures in an unknown state.
This is what makes it so dangerous. It can also be used to jump into a
code block without correctly initializing its structures, creating a
even bigger mess.

This is from my perspective as a long time Assembler and C programmer.
Is it any different in Perl?

Bob McConnell

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Thu, Apr 14, 2011 at 11:27 PM, Peter Scott <Peter [at] psdt.com> wrote:
> On Thu, 14 Apr 2011 10:47:17 -0700, sono-io wrote:
>
>> On Apr 14, 2011, at 10:15 AM, Uri Guttman wrote:
>>
>>> goto just shouldn't be in your vocabulary. there is no reason for it at
>>> all in any decent language, especially perl.
>>
>> =A0 =A0 =A0 I've been following this thread and I'm just curious. =A0If =
goto is
> so
>> =A0 =A0 =A0 bad, why did they add it to Perl?
>
> Perl's goto is pretty old. =A0Larry was feeling permissive and in a frame
> of mind to make BASIC programmers happy. =A0He regrets it. =A0The perldoc=
for
> goto says he has never found a reason to use it.
>

but, sense it is jumping to a different place in the stack, isn't it
more efficient than doing the above mentioned

my $done =3D 0;
while( !$done ){
$done =3D 1 if( contition );
do_work;
}

vs

for(;;) {
goto DONE if( contition );
do_work;
}
label DONE;

i'd think the later would be faster not only because you are jumping
to a memory location and because you're not assessing a value every
time.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 11-04-15 08:26 AM, Bob McConnell wrote:
> But "goto" is uncontrolled and ignores that
> context, leaving the stack and related structures in an unknown state.

> This is from my perspective as a long time Assembler and C programmer.
> Is it any different in Perl?

Yes. It sets the state correctly. I even tried jumping between
packages (if they're in the same file), and the sate was correct.


--
Just my 0.00000002 million dollars worth,
Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 11-04-15 08:48 AM, shawn wilson wrote:
> my $done = 0;
> while( !$done ){
> $done = 1 if( contition );
> do_work;
> }
>
> vs
>
> for(;;) {
> goto DONE if( contition );
> do_work;
> }
> label DONE;

for(;;){
do_work;
goto DONE if( condition );
}
DONE:

The first loop always executes `do_work` even if $done is non-zero.


--
Just my 0.00000002 million dollars worth,
Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 15/04/2011 13:48, shawn wilson wrote:
>
> but, sense it is jumping to a different place in the stack, isn't it
> more efficient than doing the above mentioned
>
> my $done = 0;
> while( !$done ){
> $done = 1 if( contition );
> do_work;
> }
>
> vs
>
> for(;;) {
> goto DONE if( contition );
> do_work;
> }
> label DONE;
>
> i'd think the later would be faster not only because you are jumping
> to a memory location and because you're not assessing a value every
> time.

Hi Shawn. I'm not sure what code your comparing to, but there is no
stack involved here at all. The second example would be quicker, simply
because you are testing the condition directly instead of transferring
the state to the variable $done and then testing the variable.

By the way, the loops are not equivalent, as the first executes do_work
at least one, while the second may drop out immediately without doing
anything at all.

It would be better written:

until (condition) {
do_work;
}

Rob

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Thu, Apr 14, 2011 at 11:27 PM, Peter Scott <Peter [at] psdt.com> wrote:
> =C2=A0The perldo=
c for
> goto says he has never found a reason to use it.

Though to be complete:

perldoc -f goto said:
> The author of Perl has never felt the need to use this form of
> "goto" (in Perl, that is--C is another matter).

;D


--
Brandon McCaig <http://www.bamccaig.com/> <bamccaig [at] gmail.com>
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software <http://www.castopulence.org/> <bamccaig [at] castopulence=
..org>

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Fri, 15 Apr 2011 08:48:10 -0400, shawn wilson wrote:
> but, sense it is jumping to a different place in the stack, isn't it
> more efficient than doing the above mentioned
>
> my $done =3D 0;
> while( !$done ){
> $done =3D 1 if( contition );
> do_work;
> }
>
> vs
>
> for(;;) {
> goto DONE if( contition );
> do_work;
> }
> label DONE;
>
> i'd think the later would be faster not only because you are jumping to
> a memory location and because you're not assessing a value every time.

Exactly why would you care about what would be at best milliseconds of
execution speed more than maintainability? Seems like you'd be better
off programming in assembler if that's your priority. Execution speed
hasn't been a primary concern since the '70s, if it was even one then.

--
Peter Scott
http://www.perlmedic.com/ http://www.perldebugged.com/
http://www.informit.com/store/product.aspx?isbn=3D0137001274
http://www.oreillyschool.com/courses/perl3/

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/