OpenEuphoria

Re: Return from nested subroutines (still goto discussion)

• Posted by Derek Parnell <ddparnell at bigpond.com> Nov 12, 2004
• 489 views

Juergen Luethje wrote:
> 
> aku saya wrote:
> 
> <snip>
> 
> > Thank you, but...
> >
> > Maybe my code was too much simplified. What I meant is algorithms such
> > as backtracking or permutation. Now modified example:
> >
> > object d
> > d = {0,0,0,0,0}
> >
> > procedure r(integer x, integer y)
> >     d[x] = y
> >     if x = 5 then
> >         if d[1]+d[2]+d[3]+d[4]+d[5] = 10 then
> >             puts(1, "success")
> >             -- (print d here)
> >             goto ok
> >         end if
> >     else
> >         for i = 0 to 3 do
> >             r(x+1, i)
> >         end for
> >     end if
> > end procedure
> >
> > procedure main()
> >     for i = 0 to 3 do
> >         r(1, i)
> >     end for
> > ok:
> >     puts(1, "program end")
> > end procedure
> >
> >
> > Now the purpose of the program is to search d so that sum(d) = 10 and
> > every element of d is from 0 to 3. But when a solution is found, it
> > will just print the first solution found and continue to printing
> > "program end".
> >
> > Now how can it modified to use no GOTO and no decrease on performance?
> > (using  flags  to  indicate  whether  a  solution has been found would
> > decrease performance, I think)
> 
> If I'm right, performance is not the main question here.
> Using GOTO this way, i.e. jumping out of procedures will corrupt the
> stack, no? So this should not be done anyhow, should it? Please correct
> me if I'm wrong.

It depends. A sophisticated compiler might recognise that the flow has 
transferred from the current stack frame and compensate for that.

However, I agree that speed is may not be the primary issue. In nearly
ever case, the cost of maintaining the program over its lifetime is a
much more important issue.

But if someone is willing to pay the cost of maintaining the code
with it using GOTO, then its not my problem. 

-- 
Derek Parnell
Melbourne, Australia