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
|
Not Categorized, Please Help
|
|
