1. The 'goto' debate
6/02/2002 3:00:06 PM, euman at bellsouth.net wrote:
>
>Either Im totaly missing something about GOTO or I just
>havent had a real pressing need for them in any language
>I've tried out.
DISCLAIMER. The following are just opinions.
The only justification for GOTO is create the fastest or smallest (memory
footprint) routine
possible. And nobody in their right mind would be using Euphoria to do that.
Most people would use C
or, more likely, Assembler for that. And those languages already have a GOTO.
All the other reasons for using a GOTO can, and should, be coded using other
constructs. I would
argue that Euphoria has not got all the possible GOTO-less solutions and could
still do with a few
new keywords to help us out. But that is another issue.
I believe the the main purpose of programming languages is to convey the meaning
of the program to
human readers. That is why we have compliers/interpreters/translators - to
convert the program into
machine language. If programming languages are meant to the read by people, they
should strive to
make that easy. One of the problems with GOTO is that it tends to hide or
obscure logic and
algorithm flows. This is because one can never be sure of the processing scope
of a line of code, if
you can't know how the processing gets there. And with GOTO it is easy to cause
the physical code
layout to misrepresent the local processing flow. And this causes people to make
mistakes.
For example...
if functionA() then
label_1:
fld1 = functionB()
end if
If one sees these four lines of code, you can not be sure that functionB() will
only be called if
functionA() returns TRUE. This is because it is possible that a GOTO somewhere
else in the code
references label_1. If this is in the back of one's mind, it makes coding and
debugging all that
much harder. You constantly have to be checking all the possible processing
paths to make sure you
don't trip over some side-effect of the GOTO.
Another issue with Euphoria and GOTO is that due to Euphoria's philosophy of 'no
forward
references', any GOTO would be restricted to labels lexically before the GOTO
statement. In other
words, you couldn't skip forward to a label. This could hamper earlier exits to
handle error
conditions - a common use of GOTOs.
And it must be realised that non-use of GOTO is not automatically a sign of good
programming style.
Consider this example...
integer x
x = 1
while x <> 0 do
if x = 1 then
procedureA()
x = 5
elsif x = 2 then
x = functionB()
elsif x = 3 then
procedureC()
x = 2
elsif x = 4 then
procedureD()
x = 1
elsif x = 5 then
if functionE() then
x = functionF()
else
x = 0
end if
else
x = 1
end if
end while
Using the code above, when is functionB() called?
Having seen the source code for RDS's implementation of Euphoria, I also believe
that it would be
difficult to implement GOTO without significant rework. That is not to say that
Euphoria's syntax
couldn't cope with a GOTO, just that this particular implementation would
struggle.
Finally, in spite of these opinions, I have no problem with anybody else using
GOTO in their
programs. I will just have a reduced confidence level with using those programs.
---------
Cheers,
Derek Parnell
2. Re: The 'goto' debate
My simple meaning to the long lasting GOTO debate:
The GOTO (better: 'jump', or whatever is equivalent to it) is simply
PRACTICAL, and all arguments due to the so called 'good programming
style' is nonsense as far as the code will be much easier to write/read,
and that's the main point of Euphoria!
When I had to transfer code formerly written in FORTRAN and BASIC
(FORTRAN and today BASIC does not need a GOTO, but it's used sometimes)
it was a lot of work to transfer it to Euphoria, and the 'structured
code doesn't look cleaner. As it's easy to (mis)use GOTOs to write
'unreadable' code, so it's easy to write 'unreadable' code with
structured elements like 'if.. then.. elsif.. ..else.. end if'.
The arguments pro GOTO - from the standpoint off the high level
programmer - was said often, and I will not repeat it here. Only one
serious reason might stand against introducing a GOTO (only inside sub
routines of course!), namely, if it would slow down Euphoria's execution
speed, nothing else, dot.
Another solution would be to write a (Euphoria) program which
automatically translates code (i.e. BASIC or FORTRAN) with GOTOs into
'clean' structured Euphoria code. I don't know of any EFFECTIVE program
to do the job (don't come with the simple 'GOTO ... :LABEL' peace, which
easily could be replaced by 'if ... end if').
Don't be a fanatic or fundamentalist, and have a nice day, Rolf
3. Re: The 'goto' debate
> > EX can get by with a GOTO, but EXW will need a COMEFROM.
>
> A COMEFROM? You mean like to know how one got to that point in the
> execution? Good idea, i was trying to hack Turbo Pascal to do that at one
> point. But why not make that possible in both dos and windows, and *nix?
Okay, then while we're at it, how about a WHEREFORE and a WHONOT?
4. Re: The 'goto' debate
- Posted by vern at lvp.eastlink.ca
Feb 06, 2002
I thought the goto statement in TP was for labels only with a specific
block?? What do I know, I'll GOTO sleep and mind my business now.
Vern
----- Original Message -----
From: "Kat" <gertie at PELL.NET>
To: "EUforum" <EUforum at topica.com>
Subject: RE: The 'goto' debate
>
> On 6 Feb 2002, at 5:51, kennethroger at prodigy.net wrote:
>
> >
> > EX can get by with a GOTO, but EXW will need a COMEFROM.
>
> A COMEFROM? You mean like to know how one got to that point in the
> execution? Good idea, i was trying to hack Turbo Pascal to do that at one
> point. But why not make that possible in both dos and windows, and *nix?
>
> Kat
>
>
>
>
5. Re: The 'goto' debate
On 6 Feb 2002, at 18:21, vern at lvp.eastlink.ca wrote:
>
> I thought the goto statement in TP was for labels only with a specific
> block??
I was questioning the COMEFROM , not the GOTO.
>What do I know, I'll GOTO sleep and mind my business now.
You can't just GOTO bed. First you haveto set up the flow control vars, and
repeatedly test them in that big stacked if-elsif-endif mess in the life
function.
Be sure to verify isinside(cat), islocked(door), possess(me,bed),
appropriate(me,time(sleep)), and the all important
exists(house,{"roof","walls","floor"}) and not
exists(bedroom,{harmful_animals_list,magma})) and not
exists.*(bed,{garden,list.aircraft}).
Kat
> Vern
>
> ----- Original Message -----
> From: "Kat" <gertie at PELL.NET>
> To: "EUforum" <EUforum at topica.com>
> Sent: Wednesday, February 06, 2002 4:21 PM
> Subject: RE: The 'goto' debate
>
>
> > On 6 Feb 2002, at 5:51, kennethroger at prodigy.net wrote:
> >
> > >
> > > EX can get by with a GOTO, but EXW will need a COMEFROM.
> >
> > A COMEFROM? You mean like to know how one got to that point in the
> > execution? Good idea, i was trying to hack Turbo Pascal to do that at one
> > point. But why not make that possible in both dos and windows, and *nix?
> >
> > Kat
> >
> >
>
>
>
6. Re: The 'goto' debate
On 6 Feb 2002, at 16:20, Derek Parnell wrote:
>
> 6/02/2002 3:00:06 PM, euman at bellsouth.net wrote:
> >
> >Either Im totaly missing something about GOTO or I just
> >havent had a real pressing need for them in any language
> >I've tried out.
>
> DISCLAIMER. The following are just opinions.
>
> The only justification for GOTO is create the fastest or smallest (memory
> footprint) routine possible. And nobody in their right mind would be using
> Euphoria to do that.
/me looks at Jiri......
> Most people would use C or, more likely, Assembler for
> that. And those languages already have a GOTO.
Kewl, so it can't be all that bad, eh?
> All the other reasons for using a GOTO can, and should, be coded using other
> constructs. I would argue that Euphoria has not got all the possible GOTO-less
> solutions and could still do with a few new keywords to help us out. But that
> is
> another issue.
No it isn't. Coding in this one functionality could replace the continue, the
exit, and give us the functionality of case and repeat. That's 4:1 in payback
for coding time.
> I believe the the main purpose of programming languages is to convey the
> meaning
> of the program to human readers. That is why we have
> compliers/interpreters/translators - to convert the program into machine
> language. If programming languages are meant to the read by people, they
> should
> strive to make that easy.
One reason i left Rebol was just that, they strive to make it human-readable,
which it is, complete with the differing meanings in each context!
> One of the problems with GOTO is that it tends to hide
> or obscure logic and algorithm flows.
A "goto here" is mighty unambiguous, in my opinion.
>This is because one can never be sure of
> the processing scope of a line of code, if you can't know how the processing
> gets there. And with GOTO it is easy to cause the physical code layout to
> misrepresent the local processing flow. And this causes people to make
> mistakes.
"physical code layout"? Arrrrgggggg!
> For example...
>
> if functionA() then
> label_1:
> fld1 = functionB()
> end if
>
> If one sees these four lines of code, you can not be sure that functionB()
> will
> only be called if functionA() returns TRUE. This is because it is possible
> that
> a GOTO somewhere else in the code references label_1.
A common constrain is to not allow jumping *into a loop*. Jumping into a if-
endif clause is iffy, but shouldn't break anything. To jump into a loop puts the
loop vars into an undefined state. Jumping out of a loop is something we
already have for while(continue) and whole procedures(exit), so that is known
to not be a problem in existing Eu code.
> If this is in the back of
> one's mind, it makes coding and debugging all that much harder. You constantly
> have to be checking all the possible processing paths to make sure you don't
> trip over some side-effect of the GOTO.
If one wants to make wierd code, they can do that with the existing words,
as you demo below. In some cases, the goto and labels can clarify the code,
and even make it run faster by eliminating the flow control vars.
> Another issue with Euphoria and GOTO is that due to Euphoria's philosophy of
> 'no
> forward references', any GOTO would be restricted to labels lexically before
> the
> GOTO statement. In other words, you couldn't skip forward to a label. This
> could
> hamper earlier exits to handle error conditions - a common use of GOTOs.
Not true: you realise, if Rob added one parameter to continue(), the target, it
would would be the equal to a forward-only goto? The same code that
implements the continue() and the exit() could probably make this form of
goto work *easily*, at least in the interpreter. The continue must know where
to jump to, so must the exit. Even if the nests in the Eu code are written as
un-nested functions in the machine code or C calls, the same code to
forward all the way out of a while loop could be used to partially forward in a
section of code.
With a few changes, the same code reuse might make the go-back goto
work too.
> And it must be realised that non-use of GOTO is not automatically a sign of
> good
> programming style. Consider this example...
>
> integer x
> x = 1
> while x <> 0 do
> if x = 1 then
> procedureA()
> x = 5
> elsif x = 2 then
> x = functionB()
> elsif x = 3 then
> procedureC()
> x = 2
> elsif x = 4 then
> procedureD()
> x = 1
> elsif x = 5 then
> if functionE() then
> x = functionF()
> else
> x = 0
> end if
> else
> x = 1
> end if
> end while
>
> Using the code above, when is functionB() called?
>
> Having seen the source code for RDS's implementation of Euphoria, I also
> believe
> that it would be difficult to implement GOTO without significant rework. That
> is
> not to say that Euphoria's syntax couldn't cope with a GOTO, just that this
> particular implementation would struggle.
See what i said about the continue above.
> Finally, in spite of these opinions, I have no problem with anybody else using
> GOTO in their programs. I will just have a reduced confidence level with using
> those programs.
I worry about those big if-elsif-endif stacks, for other than the careful
indenting, and runtime error checks, i am never sure if 5 pages of such a
stack is going to execute properly. Many times i have printed out the pile,
and manually checked off matching elsif-elsif indents to be more sure of just
what was going to happen. Besides, with that many in the if-pile, the goto
functioning at a case statement, resolving the possible targets at compile
time, should be *much* faster for those statements at the bottom of the
stack. And yes, i could have broken each then-clause off to a separate
function, except for the local var passing back and forth.
Kat
7. Re: The 'goto' debate
On 7 Feb 2002, at 2:32, Kat wrote:
To: EUforum <EUforum at topica.com>
From: Kat <gertie at PELL.NET>
Subject: Re: The 'goto' debate
Date sent: Thu, 7 Feb 2002 02:32:16 -0600
Send reply to: EUforum at topica.com
>
> I worry about those big if-elsif-endif stacks, for other than the careful
> indenting, and runtime error checks, i am never sure if 5 pages of such a
> stack is going to execute properly. Many times i have printed out the pile,
> and
> manually checked off matching elsif-elsif indents to be more sure of just what
> was going to happen. Besides, with that many in the if-pile, the goto
> functioning at a case statement, resolving the possible targets at compile
> time,
> should be *much* faster for those statements at the bottom of the stack. And
> yes, i could have broken each then-clause off to a separate function, except
> for
> the local var passing back and forth.
>
Well Kat, I agree with you here. It's *very* difficult (and quite annoying) to
handle those stacks. I had the same problem with Clipper but I learned how to
handle it. On that time, I was porting a MUMPS application (huge) into Clipper.
The first time it was too slow, then it got a lot better and finally it worked
as perfect as (or better than). It's still working today though I'm not in
charge anymore. I used a debugger (not Clipper's debug) do show open laces or
wrong closing. It helped a lot.
Of course I had to use too much indentation which quite often force code to
side scroll (what I personally hate) but when you have a good editor this is
not a problem at all. On other side, unconditional moving (GOTO :LABEL:) will
turn it on vertical scroll which is no good either. So, the only way to debug
is to hardprint the code to get an overall view.
I have no complains on using GOTOs, EXITs, CONTINUEs, IFs..END_IFs,
CASEs..END_CASEs or whatsoever. I have been working with so many languages an
dialects for so many years that I simply don't care. I just accept the language
'AS IS' and try to get along. Right now, I'm nothing but a (Euphoria) newbie.
I'll try it and see if I can get along...
Cheers!
-- Euler
