1. Goto?
Kat has brought up the subject of Goto and while we are talking about 4.0 and
new keywords, let's just talk about this one too.
I have mixed emotions about it. Goto in some situations can be a very valuable
construct but it can also be a construct that novice programmers can really get
in trouble with causing hours of unnecessary debugging.
So, I guess the real decision is does Euphoria take a stand at trying to protect
the programmer from writing bad code or does it provide to them power and if the
programmer wishes to shoot himself with it, they can.
I know this will be a controversial subject. All I am doing is the same thing
I've done with things in the past. Raise the subject and let's talk about it.
Since it is controversial, let's not get upset. All we are doing is talking about
it. Let's not revert to name calling, yelling or getting upset. It's just a talk
about goto.
There is an existing wiki page that you may wish to read before commenting. I am
unsure of it's original author:
http://euwiki.ayo.biz/Goto
--
Jeremy Cowgar
http://jeremy.cowgar.com
2. Re: Goto?
Jeremy Cowgar wrote:
>
> Kat has brought up the subject of Goto and while we are talking about 4.0 and
> new keywords, let's just talk about this one too.
>
> I have mixed emotions about it. Goto in some situations can be a very valuable
> construct but it can also be a construct that novice programmers can really
> get in trouble with causing hours of unnecessary debugging.
>
> So, I guess the real decision is does Euphoria take a stand at trying to
> protect
> the programmer from writing bad code or does it provide to them power and if
> the programmer wishes to shoot himself with it, they can.
>
> I know this will be a controversial subject. All I am doing is the same thing
> I've done with things in the past. Raise the subject and let's talk about it.
> Since it is controversial, let's not get upset. All we are doing is talking
> about it. Let's not revert to name calling, yelling or getting upset. It's
> just
> a talk about goto.
>
> There is an existing wiki page that you may wish to read before commenting.
> I am unsure of it's original author:
>
> <a href="http://euwiki.ayo.biz/Goto">http://euwiki.ayo.biz/Goto</a>
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
I don't think it's "protecting the programmer from writing bad code" as much as
it is "protecting the maintainer from maintaining bad code".
Yes, I'm relying on Derek Parnell's argument that a piece of code's human
readability is very important.
I mean, if we all wanted to shoot ourselves in the foot we might as well keep
using C. 
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
3. Re: Goto?
What no one understands about implementing goto is how
complicated it is to implement in an interpreter.
Maybe if someone would demonstrate how easy it is to implement;
then they could post the code and that could be discussed on EUforum.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
4. Re: Goto?
Bernie Ryan wrote:
> What no one understands about implementing goto is how
> complicated it is to implement in an interpreter.
> Maybe if someone would demonstrate how easy it is to implement;
> then they could post the code and that could be discussed on EUforum.
The front end code is pretty easy actually, at first glance. Now, what may be
difficult is what I mentioned in the post in regards to the for loop. Jumping out
of a for loop is going to leave things pretty dirty, but I am certain that can be
solved with a bit of thought. But, I do not wish to spend any time developing
code that will be rejected, so I think the discussion must come first.
--
Jeremy Cowgar
http://jeremy.cowgar.com
5. Re: Goto?
Jeremy Cowgar wrote:
>
> I have mixed emotions about it. Goto in some situations can be a very valuable
> construct but it can also be a construct that novice programmers can really
> get in trouble with causing hours of unnecessary debugging.
I've never encountered a case where a goto is the best solution. Never.
One thing I want to avoid on any interpreter upgrade is bloating the
interpreter and/or slowing it down. If goto is going to be considered, I'm
sure there are more popular options to be considered first.
6. Re: Goto?
Bernie Ryan wrote:
>
>
> What no one understands about implementing goto is how
>
> complicated it is to implement in an interpreter.
>
> Maybe if someone would demonstrate how easy it is to implement;
>
> then they could post the code and that could be discussed on EUforum.
See the 1200 words on it is done, with options and etc:
http://ooeu.sourceforge.net/docs/USING_GOTO.htm
Kat
7. Re: Goto?
Jeremy Cowgar wrote:
>
> the subject of Goto
I vote to have it.
I will never use it.
I will not use Euphoria programs that use it.
I will not try to maintain Euphoria code that uses it.
GOTO in Euphoria would serve two purposes ...
(A) If the only way to get the extra microseconds of performance from your
critical section of code is to use it, then it is justified. However, this
assumes you have actually exhusted all other methods first. Even then, if you are
actually trying for speed, code in assembler.
(B) To demonstrate that GOTO is the wrong tool in nearly every case.
However having said all that, if someone wants to use it in the privacy of their
own code and its not hurting anyone else, they should be free to do so.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
8. Re: Goto?
Kat wrote:
>
> Bernie Ryan wrote:
> >
> >
> > What no one understands about implementing goto is how
> >
> > complicated it is to implement in an interpreter.
> >
> > Maybe if someone would demonstrate how easy it is to implement;
> >
> > then they could post the code and that could be discussed on EUforum.
>
> See the 1200 words on it is done, with options and etc:
>
> <a
> href="http://ooeu.sourceforge.net/docs/USING_GOTO.htm">http://ooeu.sourceforge.net/docs/USING_GOTO.htm</a>
>
Kat:
If OOEU works then why aren't you using it for all your coding instead
of keep asking for it ?
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
9. Re: Goto?
Bernie Ryan wrote:
>
> What no one understands about implementing goto is how
> complicated it is to implement in an interpreter.
> Maybe if someone would demonstrate how easy it is to implement;
> then they could post the code and that could be discussed on EUforum.
Already done. All of it.
We already have goto. It's called exit. Seriously, look at what it does.
A simple, static goto is trivial. Making it dynamic is slightly more
difficult, but not impossible. I even made it work with dynamic labels!
(Which I think was a bridge too far.)
Look at the code for yourself:
http://ooeu.sourceforge.net/svn.htm
Matt
10. Re: Goto?
Jeremy Cowgar wrote:
>
> Bernie Ryan wrote:
> > What no one understands about implementing goto is how
> > complicated it is to implement in an interpreter.
> > Maybe if someone would demonstrate how easy it is to implement;
> > then they could post the code and that could be discussed on EUforum.
>
> The front end code is pretty easy actually, at first glance. Now, what may be
> difficult is what I mentioned in the post in regards to the for loop. Jumping
> out of a for loop is going to leave things pretty dirty, but I am certain that
> can be solved with a bit of thought. But, I do not wish to spend any time
> developing
> code that will be rejected, so I think the discussion must come first.
What's dirty about it? It's no different than exit. Jumping *into* a
for loop is bad juju.
Matt
11. Re: Goto?
Bernie Ryan wrote:
> If OOEU works then why aren't you using it for all your coding instead
> of keep asking for it ?
>
> Bernie
>
> My files in archive:
> WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
>
> Can be downloaded here:
> <a
> href="http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan">http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan</a>
I think that OOEU has a lot of features that it would be nice to fold back into
the "official" version of Euphoria. And it's at least worthwhile to discuss them.
Even the dreaded "goto". And OO.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
12. Re: Goto?
Jeremy Cowgar wrote:
<snip=huge>
> An exit and continue could be modified pretty easy to do something like this:
>
> }}}
<eucode>
> for a = 1 to 5 do
> for b = 1 to 5 do
> for c = 1 to 5 do
> exit 2 -- exit 2 loops
> end for
> -- never reached
> puts(1, "Hello!\n")
> end for
>
> printf(1, "%d,", {a})
> end for
> </eucode>
{{{
>
> Output of above is 1,2,3,4,5. The same could be done for continue. Before
> enabling
> goto to exit a loop, I would nominate the above construct. If a parameter was
> not given to exit or continue, it would simply exit 1 loop as normal.
Sure, but then like you said you'd do, you'd add another layer of loop, and then
look up all the exits and change them, whereas the goto :target would not need
changing. Besides, could you do all the variations on :target that Matt did? Then
why not just do "goto" and not limit all that work to just "exit"?
Like Daryl said about debug blocks and conditional compilation (and i agree -
with CK that we need them, and with Daryl too), exit is a specialised goto, let's
have a general goto.
Kat
13. Re: Goto?
Matt Lewis wrote:
>
> What's dirty about it? It's no different than exit. Jumping *into* a
> for loop is bad juju.
>
How does the loop status get updated? in_loop or loop_stack, etc... ? When
jumping out of a loop via a goto, will it not leave those variables untouched,
thus, the stack could build and build and build?
--
Jeremy Cowgar
http://jeremy.cowgar.com
14. Re: Goto?
Kat wrote:
>
>
> Like Daryl said about debug blocks and conditional compilation (and i agree
> - with CK that we need them, and with Daryl too), exit is a specialised goto,
> let's have a general goto.
>
That's what this discussion is about Just your previous was why have 6
keywords when it could be done with 1, goto... in which I described why that was
not feasible. But let's keep this to a discussion about the general goto.
--
Jeremy Cowgar
http://jeremy.cowgar.com
15. Re: Goto?
Bernie Ryan wrote:
>
> Kat wrote:
> >
> > Bernie Ryan wrote:
> > >
> > >
> > > What no one understands about implementing goto is how
> > >
> > > complicated it is to implement in an interpreter.
> > >
> > > Maybe if someone would demonstrate how easy it is to implement;
> > >
> > > then they could post the code and that could be discussed on EUforum.
> >
> > See the 1200 words on it is done, with options and etc:
> >
> > <a
> > href="http://ooeu.sourceforge.net/docs/USING_GOTO.htm">http://ooeu.sourceforge.net/docs/USING_GOTO.htm</a>
> >
>
> Kat:
>
> If OOEU works then why aren't you using it for all your coding instead
>
> of keep asking for it ?
It has a couple,, umm,, issues that i can't get around. The readme still makes
me drool and keep trying tho. There's a *lot* more in OOEU that is appealing
besides goto. Just the fact that Matt could do all that is in OOEU, when RobC
couldn't/wouldn't in the last 10 years speaks volumes. I know Matt would be doing
even more if he wasn't already so busy. I'd help if not for real life, and
essentially being told in #Euphoria that i shouldn't.
Kat
16. Re: Goto?
Matt Lewis wrote:
>
> Bernie Ryan wrote:
> >
> > What no one understands about implementing goto is how
> > complicated it is to implement in an interpreter.
> > Maybe if someone would demonstrate how easy it is to implement;
> > then they could post the code and that could be discussed on EUforum.
>
> Already done. All of it.
>
> We already have goto. It's called exit. Seriously, look at what it does.
> A simple, static goto is trivial. Making it dynamic is slightly more
> difficult, but not impossible. I even made it work with dynamic labels!
> (Which I think was a bridge too far.)
It's a wonderful option, and i hope that now you wrote it, you don't remove it.
There's a line between wonderful options that few people would use, and those
bridges that go too far. I see no pain in keeping it.
Kat
17. Re: Goto?
Kat wrote:
>
> Matt Lewis wrote:
> >
> > We already have goto. It's called exit. Seriously, look at what it does.
> > A simple, static goto is trivial. Making it dynamic is slightly more
> > difficult, but not impossible. I even made it work with dynamic labels!
> > (Which I think was a bridge too far.)
>
> It's a wonderful option, and i hope that now you wrote it, you don't remove
> it. There's a line between wonderful options that few people would use, and
> those bridges that go too far. I see no pain in keeping it.
>
I think he's talking about in OOeu. I do not see any code in EU that supports
Goto.
--
Jeremy Cowgar
http://jeremy.cowgar.com
18. Re: Goto?
Jeremy Cowgar wrote:
>
> Kat wrote:
> >
> > Matt Lewis wrote:
> > >
> > > We already have goto. It's called exit. Seriously, look at what it does.
> > > A simple, static goto is trivial. Making it dynamic is slightly more
> > > difficult, but not impossible. I even made it work with dynamic labels!
> > > (Which I think was a bridge too far.)
> >
> > It's a wonderful option, and i hope that now you wrote it, you don't remove
> > it. There's a line between wonderful options that few people would use, and
> > those bridges that go too far. I see no pain in keeping it.
> >
>
> I think he's talking about in OOeu. I do not see any code in EU that supports
> Goto.
Yes,,, and?
Kat
19. Re: Goto?
Jeremy Cowgar wrote:
>
> Matt Lewis wrote:
> >
> > What's dirty about it? It's no different than exit. Jumping *into* a
> > for loop is bad juju.
> >
>
> How does the loop status get updated? in_loop or loop_stack, etc... ? When
> jumping
> out of a loop via a goto, will it not leave those variables untouched, thus,
> the stack could build and build and build?
Execution doesn't really care about that stuff. That's all front-end stuff.
Again, take a look at what exit actually does. It's just a goto, with the
target implicitly defined as just outside the current loop.
Matt
20. Re: Goto?
Kat wrote:
>
> Matt Lewis wrote:
> >
> > We already have goto. It's called exit. Seriously, look at what it does.
> > A simple, static goto is trivial. Making it dynamic is slightly more
> > difficult, but not impossible. I even made it work with dynamic labels!
> > (Which I think was a bridge too far.)
>
> It's a wonderful option, and i hope that now you wrote it, you don't remove
> it. There's a line between wonderful options that few people would use, and
> those bridges that go too far. I see no pain in keeping it.
Well, I'm not going to remove it from OOEU, but I'd be interested to hear
about how you use it. Specifically, the ability to define your labels as
variables, and how the interpreter will assess what the variable is at the
time of the goto.
It just seems like a nightmare to have the value of the labels changing.
Matt
21. Re: Goto?
Matt Lewis wrote:
>
> Jeremy Cowgar wrote:
> >
> > Matt Lewis wrote:
> > >
> > > What's dirty about it? It's no different than exit. Jumping *into* a
> > > for loop is bad juju.
> > >
> >
> > How does the loop status get updated? in_loop or loop_stack, etc... ? When
> > jumping
> > out of a loop via a goto, will it not leave those variables untouched, thus,
> > the stack could build and build and build?
>
> Execution doesn't really care about that stuff. That's all front-end stuff.
> Again, take a look at what exit actually does. It's just a goto, with the
> target implicitly defined as just outside the current loop.
>
Hm, but couldn't it invite bugs in the compiler? For instance, look at compile.e
around line 146. It checks the length of the loop_stack and makes a decision
based on it. Line 3792 dereferences variables (which I assume opens it up for
either freeing or re-use of that memory) in the end loop. Now, I do see on line
3873 where return will deref any open loop vars but that will not handle
top-level stuff.
Just trying to learn the code.
--
Jeremy Cowgar
http://jeremy.cowgar.com
22. Re: Goto?
Jeremy Cowgar wrote:
>
> Kat wrote:
> >
> > Matt Lewis wrote:
> > >
> > > We already have goto. It's called exit. Seriously, look at what it does.
> > > A simple, static goto is trivial. Making it dynamic is slightly more
> > > difficult, but not impossible. I even made it work with dynamic labels!
> > > (Which I think was a bridge too far.)
> >
> > It's a wonderful option, and i hope that now you wrote it, you don't remove
> > it. There's a line between wonderful options that few people would use, and
> > those bridges that go too far. I see no pain in keeping it.
> >
>
> I think he's talking about in OOeu. I do not see any code in EU that supports
> Goto.
Not only is he talking about OOeu, he is specifically speaking about the ability
to have the labels be defined dynamically. I agree with Kat that it is a neat
option. But I don't think she was imploring him to maintain GOTO itself. She
was talking about dynamic labels.
Mike
23. Re: Goto?
- Posted by CChris <christian.cuvier at agriculture.go??.fr>
May 12, 2008
-
Last edited May 13, 2008
c.k.lester wrote:
>
> Jeremy Cowgar wrote:
> >
> > I have mixed emotions about it. Goto in some situations can be a very
> > valuable
> > construct but it can also be a construct that novice programmers can really
> > get in trouble with causing hours of unnecessary debugging.
>
> I've never encountered a case where a goto is the best solution. Never.
>
> One thing I want to avoid on any interpreter upgrade is bloating the
> interpreter and/or slowing it down. If goto is going to be considered, I'm
> sure there are more popular options to be considered first.
There is one frequent case where goto could be tempting: exiting nested loops or
if blocks.
It would be very useful, and not very difficult, to implement an "exit n" or
"exit <loop_label" or exif for if blocks. This would be a valuable addition,
without any new keyword.
Of course (as for goto targets), the values must be constants. Otherwise, it
becomes very difficult, as Bernie pointed out.
CChris
24. Re: Goto?
- Posted by Kat <KAT12 at coo??hs.net>
May 12, 2008
-
Last edited May 13, 2008
CChris wrote:
>
> c.k.lester wrote:
> >
> > Jeremy Cowgar wrote:
> > >
> > > I have mixed emotions about it. Goto in some situations can be a very
> > > valuable
> > > construct but it can also be a construct that novice programmers can
> > > really
> > > get in trouble with causing hours of unnecessary debugging.
> >
> > I've never encountered a case where a goto is the best solution. Never.
> >
> > One thing I want to avoid on any interpreter upgrade is bloating the
> > interpreter and/or slowing it down. If goto is going to be considered, I'm
> > sure there are more popular options to be considered first.
>
> There is one frequent case where goto could be tempting: exiting nested loops
> or if blocks.
>
> It would be very useful, and not very difficult, to implement an "exit n" or
> "exit <loop_label" or exif for if blocks. This would be a valuable addition,
> without any new keyword.
In developing a syntactic parser, i discovered exponential explosions in
possibilities, and 90% of them could be eliminated early in the reparse. Having a
goto more than doubled parse speed and eliminated if-then flag tests all over the
place. Had i been forced to use exit(n), i'd have needed to keep an eye on all
exits every time i added or removed code during development.
Kat
25. Re: Goto?
- Posted by CChris <christian.cuvier at agricultu?e?gouv.fr>
May 12, 2008
-
Last edited May 13, 2008
Kat wrote:
>
> CChris wrote:
> >
> > c.k.lester wrote:
> > >
> > > Jeremy Cowgar wrote:
> > > >
> > > > I have mixed emotions about it. Goto in some situations can be a very
> > > > valuable
> > > > construct but it can also be a construct that novice programmers can
> > > > really
> > > > get in trouble with causing hours of unnecessary debugging.
> > >
> > > I've never encountered a case where a goto is the best solution. Never.
> > >
> > > One thing I want to avoid on any interpreter upgrade is bloating the
> > > interpreter and/or slowing it down. If goto is going to be considered, I'm
> > > sure there are more popular options to be considered first.
> >
> > There is one frequent case where goto could be tempting: exiting nested
> > loops
> > or if blocks.
> >
> > It would be very useful, and not very difficult, to implement an "exit n" or
> > "exit <loop_label" or exif for if blocks. This would be a valuable addition,
> > without any new keyword.
>
> In developing a syntactic parser, i discovered exponential explosions in
> possibilities,
> and 90% of them could be eliminated early in the reparse. Having a goto more
> than doubled parse speed and eliminated if-then flag tests all over the place.
> Had i been forced to use exit(n), i'd have needed to keep an eye on all exits
> every time i added or removed code during development.
>
> Kat
Which is why
label "my_loop"
for i=1 to n do
while 1 do
while f(x)=3 do
---....
if done() then
exit "my_loop"
end if
end end end
is better than "exit 3", even though the latter is probably useful - but harder
to maintain as you pointed out.
CChris
26. Re: Goto?
- Posted by Kat <KAT12 at co??ahs.net>
May 12, 2008
-
Last edited May 13, 2008
I should probably stop posting in regards to goto. I have been in favor of and
used goto, since the ZX80 days, nearly 30 years ago. I used machine code jmps in
various forms before that. I shall continue to use goto when it's available and
the best choice for the task.
Kat
27. Re: Goto?
Jeremy Cowgar wrote:
>
> Matt Lewis wrote:
> >
> > Execution doesn't really care about that stuff. That's all front-end stuff.
> > Again, take a look at what exit actually does. It's just a goto, with the
> > target implicitly defined as just outside the current loop.
> >
>
> Hm, but couldn't it invite bugs in the compiler? For instance, look at
> compile.e
> around line 146. It checks the length of the loop_stack and makes a decision
> based on it. Line 3792 dereferences variables (which I assume opens it up for
> either freeing or re-use of that memory) in the end loop. Now, I do see on
> line
> 3873 where return will deref any open loop vars but that will not handle
> top-level
> stuff.
>
> Just trying to learn the code.
Not sure if this would be a problem or not. I haven't gotten into the
translator as much as the interpreter. But in general, goto worked in the
translator for me.
That part you pointed to looks like something Rob put in there to decide
when to break up files to keep certain compilers from choking. I don't think
it has an effect on the code otherwise. I think it would only affect
top level code with gotos. An easy solution is to disallow them at the
top level.
Matt
28. Re: Goto?
CChris wrote:
>
> There is one frequent case where goto could be tempting: exiting nested loops
> or if blocks.
>
> It would be very useful, and not very difficult, to implement an "exit n" or
> "exit <loop_label" or exif for if blocks. This would be a valuable addition,
> without any new keyword.
Should definitely be a label. Using a number for the levels is too fragile.
Matt
29. Re: Goto?
Heh, don't forget that some of us anti-gotos started about thirty years ago as
well.
(Almost).
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
