1. Return from nested subroutines (still goto discussion)
- Posted by akusaya at gmx.net
Nov 12, 2004
Code..
(I used to use this in PASCAL long time ago)
procedure r(integer x)
if x = 5 then
puts(1, "success")
goto ok
end if
r(x+1)
puts(1, "don't come here!")
end procedure
procedure main()
r(1)
ok:
puts(1, "program end")
end procedure
When main() is executed, it will call r(1), r(1) will call r(2), etc,
r(4) will call r(5), r(5) will print "success" and then goto ok which
will print "program end" without no printing of "don't come here!"
That is the very convenient use of goto, and I used goto only on
programs like that.
Is there any method to perform the same as above without goto and
without decreasing performance?
2. Re: Return from nested subroutines (still goto discussion)
On Fri, 12 Nov 2004 15:09:11 +0800, aku saya <akusaya at gmx.net> wrote:
>
> Code..
> (I used to use this in PASCAL long time ago)
<SNIP>
>
> When main() is executed, it will call r(1), r(1) will call r(2), etc,
> r(4) will call r(5), r(5) will print "success" and then goto ok which
> will print "program end" without no printing of "don't come here!"
>
> That is the very convenient use of goto, and I used goto only on
> programs like that.
>
> Is there any method to perform the same as above without goto and
> without decreasing performance?
uh....
for i = 1 to 5 do
*code*
end for
puts(1, "success\n")
puts(1, "program end\n")
Gives the same output, and runs some section of code 5 times?
--
MrTrick
3. Re: Return from nested subroutines (still goto discussion)
unknown wrote:
>
>
> Code..
> (I used to use this in PASCAL long time ago)
>
>
> procedure r(integer x)
> if x = 5 then
> puts(1, "success")
> goto ok
> end if
> r(x+1)
> puts(1, "don't come here!")
> end procedure
>
> procedure main()
> r(1)
> ok:
> puts(1, "program end")
> end procedure
>
>
> When main() is executed, it will call r(1), r(1) will call r(2), etc,
> r(4) will call r(5), r(5) will print "success" and then goto ok which
> will print "program end" without no printing of "don't come here!"
>
> That is the very convenient use of goto, and I used goto only on
> programs like that.
>
> Is there any method to perform the same as above without goto and
> without decreasing performance?
>
>
procedure r(integer x)
if x = 5 then
puts(1, "success")
else
r(x+1)
end if
end procedure
procedure main()
r(1)
puts(1, "program end")
end procedure
--
Derek Parnell
Melbourne, Australia
4. Re: Return from nested subroutines (still goto discussion)
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.
Regards,
Juergen
5. Re: Return from nested subroutines (still goto discussion)
You know...this discussion reminds me of a scenario like this.
ADVERTISEMENT:
All new butter knives! For sale! Slices butter like never before! You'll
have butter sliced in record time! This new tool should reduce your butter
slicing time by one-half! Because of it's unique design, it is also easier
to use than any other butter knife! Hurry while supplies last! Only $1.99!
However, you do have to sign a contract that states that you will never use
this butter knife as a screwdriver, since we, the manufacturers, did not
make it to be used as a butter knife. If you refuse to sign the contract,
we will not sell the butter knife to you.
ADVERTISEMENT
Bottom Line: Don't limit someone else's creativity just because it's not
the way you want things done. It doesn't hurt you one bit if someone else
uses that butter knife as a screwdriver. And, if you question the safety of
some machine that has had the screws put in place with the
butterknife...then just don't use that machine. In a capitalistic world,
the person will stop using the butter knife if there is no demand for it.
On the other hand, if it produces demand, even against the way you think it
should, don't be jealous of that demand and find ways to question it.
Instead, make a better product. It's called competition.
Michelle Rogers
----- Original Message -----
From: "Juergen Luethje" <j.lue at gmx.de>
To: <EUforum at topica.com>
Sent: Friday, November 12, 2004 5:39 AM
Subject: Re: Return from nested subroutines (still goto discussion)
>
>
> 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.
>
> Regards,
> Juergen
>
>
>
>
6. Re: Return from nested subroutines (still goto discussion)
Oh, wait. I just realized something though. Euphoria is created in Canada,
right? So, from what I understand, living here in America, there is no
capitalism in Canada, right? Maybe that's why we're even having this
discussion. Because (and I know it's hard to tell over the internet, but I
am being serious NOT sarcastic) maybe if you don't live in a capitalistic
society, it might be hard to understand how a situation would just take care
of itself like that, based on supply and demand.
Michelle Rogers
----- Original Message -----
From: "Michelle Rogers" <michellerogers at bellsouth.net>
To: <EUforum at topica.com>
Sent: Friday, November 12, 2004 5:51 AM
Subject: Re: Return from nested subroutines (still goto discussion)
>
>
> You know...this discussion reminds me of a scenario like this.
>
> ADVERTISEMENT:
> All new butter knives! For sale! Slices butter like never before!
You'll
> have butter sliced in record time! This new tool should reduce your
butter
> slicing time by one-half! Because of it's unique design, it is also
easier
> to use than any other butter knife! Hurry while supplies last! Only
$1.99!
> However, you do have to sign a contract that states that you will never
use
> this butter knife as a screwdriver, since we, the manufacturers, did not
> make it to be used as a butter knife. If you refuse to sign the contract,
> we will not sell the butter knife to you.
> ADVERTISEMENT
>
> Bottom Line: Don't limit someone else's creativity just because it's not
> the way you want things done. It doesn't hurt you one bit if someone else
> uses that butter knife as a screwdriver. And, if you question the safety
of
> some machine that has had the screws put in place with the
> butterknife...then just don't use that machine. In a capitalistic world,
> the person will stop using the butter knife if there is no demand for it.
> On the other hand, if it produces demand, even against the way you think
it
> should, don't be jealous of that demand and find ways to question it.
> Instead, make a better product. It's called competition.
>
>
> Michelle Rogers
> ----- Original Message -----
> From: "Juergen Luethje" <j.lue at gmx.de>
> To: <EUforum at topica.com>
> Sent: Friday, November 12, 2004 5:39 AM
> Subject: Re: Return from nested subroutines (still goto discussion)
>
>
> > 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.
> >
> > Regards,
> > Juergen
> >
> >
>
>
>
7. Re: Return from nested subroutines (still goto discussion)
> Bottom Line: Don't limit someone else's creativity just because it's not
> the way you want things done.
Actually, I could have said, "Don't limit someone else's creativity just
because it's not the way you would do it. Afterall, if it's the same way
that you would do it, then it's not being creative.
8. Re: Return from nested subroutines (still goto discussion)
Michelle Rogers wrote:
[snipped stories about butter knifes]
> ----- Original Message -----
> From: "Juergen Luethje"
> Sent: Friday, November 12, 2004 5:39 AM
[snipped part of my previous post]
>> 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.
This is just a technical question, isn't it?
Here are enough experts(*), so I think there is someone who can answer
it.
Regards,
Juergen
----------------------
(*) I mean programming experts, not butter knife experts.
9. Re: Return from nested subroutines (still goto discussion)
If you're right, then the program either won't run or won't run well. Then,
you can make one that runs better than him. Everyone will buy yours instead
of his. You'll be all smug that you were right. He'll be defeated and stop
coding that program, using GOTO in that way.
On, the other hand, if he uses it and the program runs great, then why
question it?
Michelle Rogers
----- Original Message -----
From: "Juergen Luethje" <j.lue at gmx.de>
To: <EUforum at topica.com>
Sent: Friday, November 12, 2004 5:39 AM
Subject: Re: Return from nested subroutines (still goto discussion)
>
>
> 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.
>
> Regards,
> Juergen
>
>
>
>
10. Re: Return from nested subroutines (still goto discussion)
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
11. Re: Return from nested subroutines (still goto discussion)
On Fri, 12 Nov 2004 05:14:42 -0800, Derek Parnell
<guest at rapideuphoria.com> wrote:
> > 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.
If it would do that, it'd have to restore the stack, which would take
a bit of execution time, too. Not everything about GOTO is fast.
--
MrTrick
12. Re: Return from nested subroutines (still goto discussion)
Man, I thought that we were going to drop this.
After Juergen's link regarding goto, I am not against having it. But Rob
will never add it.
When 2.5 is released maybe someone will figure out how to implement it.
On another note, when 2.5 is released will RDS be folding (some) submitted
changes into the code base and change the Euphoria development model to
'release early and release often' or are we going to end up with several
dozen one-off versions of Euphoria and a slew of programs that use features
not included in the main distribution?
j.
13. Re: Return from nested subroutines (still goto discussion)
Derek Parnell wrote:
> Juergen Luethje wrote:
[snipped code by aku saya]
>> 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.
Ohh... Interesting, I didn't know 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.
I didn't want to re-start the general GOTO debate, but I actually
thought there might have been a source for a bug in aku saya's code.
Thanks for the specific information, and thanks even more for a serious,
straightforward answer to a serious, straightforward question (which
is obviously too hard for some other people).
Regards,
Juergen
14. Re: Return from nested subroutines (still goto discussion)
Jason Gade wrote:
>
> <snippage>
> On another note, when 2.5 is released will RDS be folding (some) submitted
> changes into the code base and change the Euphoria development model to
> 'release early and release often' or are we going to end up with several
> dozen one-off versions of Euphoria and a slew of programs that use features
> not included in the main distribution?
>
>
> j.
>
Probably the latter.
15. Re: Return from nested subroutines (still goto discussion)
Enough with the goto's already....I did not mean to open a can of worms when
I said I would not use them and did not care for them. We had this discussion
in depth 4 or 5 years ago, no use in rehasing old ground.
Here is a couple of messages from Robert Craig from the past.
>Date: Mon, 15 Nov 1999 18:06:48 -0500
>From: Robert Craig <rds at ATTCANADA.NET>
>Subject: Goto
>
>Since some people think I should come out of hiding
>and voice an opinion on language design proposals,
>here's my current thinking about goto.
>
>1. completely general goto, including jumps
> between routines: 0% chance
>
>2. goto within a routine: 0.01% chance
>
>3. specialized goto to break out of nested loops: 1% chance
>
>I'm not religiously opposed to goto's. There are some
>goto's coded into the C source of the interpreter, and
>at one point in the early days I even had one of the
>"between routines" gotos that are possible in C using
>setjmp()/longjmp(). It proved to be nightmarishly hard
>to understand and maintain so I took it out.
>
>I agree that a specialized goto (or special "exit")
>to get out of a nested loop is probably less clumsy
>than setting up artificial state variables. I just don't think
>that this occurs often enough, or causes enough pain
>to warrant a new language feature, such as labelled
>statements and a special kind of exit.
>
>The normal sort of gotos, that let you jump around within
>a routine are like cigarettes. One or two, once in a while,
>will not harm you. The trouble is they become addictive.
>If you never start using them, you will never have a craving
>for one.
>
>When I had to maintain code written by someone
>else, the sight of a heavily goto'd section of code would
>really be discouraging. The guy who wrote the goto's
>probably had some idea of what the control-flow was
>supposed to be, but I had to struggle to get the
>same picture into my head. Standard control-flow
>statements, like for..end for, if-elsif-else etc are much
>easier to digest and reason about.
>
>Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
>Date: Sat, 10 Jun 2000 11:59:11 -0400
>From: Robert Craig <rds at ATTCANADA.NET>
>Subject: Re: (Fwd) Re: compiler?? step 4
>
>Kat writes:
>> another repost, no answer recieved again.....
>
>Rob Craig writes:
>>> Extra temp variables
>>> are used where needed, and all control-flow
>>> constructs are reduced to goto's.
>
>Kat writes:
>> Oh goodie, goto's!! 
)
>> Can we use them in the Eu code before compiling too?
>
>Sorry, because of your smiley I didn't think this was a serious
>question. No, goto's will not be allowed in Euphoria.
>The compiler generates them because it is mapping
>from the low-level intermediate language into C.
>In the intermediate language (used by both the interpreter
>and the compiler) control-flow has already been
>broken down into goto's.
>
>Rob Craig writes:
>>>You can see
>>> the original Euphoria statement as a C comment,
>>> followed by the C statements that implement that
>>> Euphoria statement.
>
>Kat writes:
>>Hmm,,, sounds like you'll be giving away the store with that one.
>
>Yes, some very interesting information will be revealed.
>However there is still a lot of information that won't be
>revealed. I think it's worth the risk.
>
>Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
So, there you have it, the GOD or CREATOR of Euphoria has spoken, and the
result is:
"No, goto's will not be allowed in Euphoria."
So, let's not beat a dead dog to death.....
Later.
Ferlin Scarborough
Learn To Program Games in Free Courses At
http://www.gameuniv.net
My Euphoria Home Page
http://mywebpage.netscape.com/shadetreesoft
16. Re: Return from nested subroutines (still goto discussion)
Michelle Rogers wrote [quoting order rearranged]:
> ----- Original Message -----
> From: "Juergen Luethje"
> Sent: Friday, November 12, 2004 5:39 AM
<snip>
>> 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.
>
> If you're right, then the program either won't run or won't run well. Then,
> you can make one that runs better than him. Everyone will buy yours instead
> of his. You'll be all smug that you were right. He'll be defeated and stop
> coding that program, using GOTO in that way.
>
> On, the other hand, if he uses it and the program runs great, then why
> question it?
First of all, I didn't "question" aku saya's code snippet, but I "asked
a question" concerning it. According to my dictionary, this is something
different.
This is a mailing list concerning Euphoria or closely-related issues.
Aku saya posted a code snippet, and I thought it might contain a source
of a bug, that could lead to corruption of the stack (which actually is
a technical problem, believe it or not).
I don't have the slightest idea, why you think it wasn't appropriate
that I mentioned it, and what your "lessons" about capitalism and such
have got to do with my question or the question of the original poster
of this thread.
--
Have you read a good program lately?
17. Re: Return from nested subroutines (still goto discussion)
- Posted by rudy toews <rltoews at ilos.net>
Nov 12, 2004
-
Last edited Nov 13, 2004
Evan Marshall wrote:
>
> Jason Gade wrote:
> >
> > <snippage>
>
> > On another note, when 2.5 is released will RDS be folding (some) submitted
> > changes into the code base and change the Euphoria development model to
> > 'release early and release often' or are we going to end up with several
> > dozen one-off versions of Euphoria and a slew of programs that use features
> > not included in the main distribution?
> >
> >
> > j.
> >
>
> Probably the latter.
IS there going to me a moderator?
a naming convention? interpreter author initials-progname-version#
will a check need to be put into place to find out what version of interpreter?
or interpreter check the program if it belongs to another interpreter?
if program interpreter author not mine then
goto end <---don't want to corrupt files
else run it
end if
rudy
18. Re: Return from nested subroutines (still goto discussion)
- Posted by "Kat" <gertie at visionsix.com>
Nov 12, 2004
-
Last edited Nov 13, 2004
On 12 Nov 2004, at 7:11, Jason Gade wrote:
>
>
> posted by: Jason Gade <jaygade at yahoo.com>
>
> Man, I thought that we were going to drop this.
>
> After Juergen's link regarding goto, I am not against having it. But Rob
> will never add it.
Some of the examples of goto given is what scares people, me included. I'd
not allow jumping in/out of a proc/function. I am not sure i'd allow jumping
into a loop of another sort, but i would allow jumping out of one (like exit or
break or continue or resume or repeat-until). Jumping into/out of procedures
breaks what goto is for.
> When 2.5 is released maybe someone will figure out how to implement it.
>
>
> On another note, when 2.5 is released will RDS be folding (some) submitted
> changes into the code base and change the Euphoria development model to
> 'release early and release often' or are we going to end up with several
> dozen one-off versions of Euphoria and a slew of programs that use features
> not
> included in the main distribution?
We'll have the one-off routines. Then it will compound, there'll be one-off
merges with other one-off versions, but with different code, and therefor
different quirks. Who uses Bach? Hellooo..... <echo>
Kat
19. Re: Return from nested subroutines (still goto discussion)
- Posted by "Kat" <gertie at visionsix.com>
Nov 12, 2004
-
Last edited Nov 13, 2004
On 12 Nov 2004, at 10:38, Ferlin Scarborough wrote:
<snip>
> So, there you have it, the GOD or CREATOR of Euphoria has spoken, and the
> result is:
> "No, goto's will not be allowed in Euphoria."
Maybe not in the official release, which just means a restricted market for
RDS, and a wider market for OpenEu (or whatever it's called now).
Kat
20. Re: Return from nested subroutines (still goto discussion)
- Posted by "Kat" <gertie at visionsix.com>
Nov 12, 2004
-
Last edited Nov 13, 2004
On 13 Nov 2004, at 0:25, Patrick Barnes wrote:
>
> On Fri, 12 Nov 2004 05:14:42 -0800, Derek Parnell
> <guest at rapideuphoria.com> wrote:
> > > 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.
>
> If it would do that, it'd have to restore the stack, which would take
> a bit of execution time, too. Not everything about GOTO is fast.
Jumping into/out of proceedures has never been on my wish list, quite the
contrary.
Kat
21. Re: Return from nested subroutines (still goto discussion)
- Posted by cklester <cklester at yahoo.com>
Nov 12, 2004
-
Last edited Nov 13, 2004
Kat wrote:
> On 12 Nov 2004, at 10:38, Ferlin Scarborough wrote:
> > So, there you have it, the GOD or CREATOR of Euphoria has spoken, and the
> > result is:
> > "No, goto's will not be allowed in Euphoria."
> Maybe not in the official release, which just means a restricted market for
> RDS, and a wider market for OpenEu (or whatever it's called now).
Given that a majority of modern programmers do NOT use goto (I'd say 1 out
of 1000 Euphorians advocate or would use it), it's disingenuous to suggest
that RDS' market will be less than OpenEu (or whatever it's called now).
I say "modern" to differentiate those who have learned programming recently
vs. those of us who started learning computer programming way back in the
80s, when goto was BASIC practice. :)
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
