1. RE: About GOTO (was RE: fixed windows)
- Posted by Peter Willems <peter at integratedmoves.com> Aug 06, 2003
- 388 views
David Cuny wrote: > Peter Williems wrote: > > > I'm not saying that goto is evil (although every informatics > > teacher will tell you) but the availability of a goto command > > generally does more bad than good, so there is a reason why many > > languages don't implement it. > > I suspect the reasons are more pragmatic. I do agree with you that the (snipped) examples you gave do indeed illustrate that. But I still think it also has a lot to do with coding philosophy (not sure if I spelled that right I suspect that Wirth's teachings have a profound inpact on todays language developments. He has always been advocating structured programming in his languages and he did develop Pascal as a structured oponent to basic. So I'm fairly sure that in the case of Pascal the omission of goto in the language has a lot to do with his philosophy. And as he has also written several books on language design and compiler development I suspect his beliefs to be visible in several (read: a lot of) programming languages. > On the down side, neither of these solutions are as simple as a GOTO. Agreed, but none of these solutions leave room to do "spagetty" programming either BTW, I realy enjoy your insightfull replies, I'm learning new things constantly. Hans Peter Willems
2. RE: About GOTO (was RE: fixed windows)
- Posted by Kenneth Roger <kennethroger at comcast.net> Aug 06, 2003
- 367 views
> David Cuny wrote... Thanks, David. Learning what/why without any good/bad connotation is refreshing.
3. RE: About GOTO (was RE: fixed windows)
- Posted by Ed Davis <ed_davis2 at yahoo.com> Aug 06, 2003
- 396 views
Peter Willems wrote: > modularization of code. This is one of the main reasons why > N. Wirth omitted goto in Pascal and many languages have followed > that omission. Well, at least in 1976, Pascal had the goto. I have N. Wirth's excellent book, "Algorithms + Data Structures = Programs", and in this book, he develops a Pascal subset compiler/interpreter, and the code uses goto. Also, it is listed in the Pascal EBNF published in Wirths 1978 book "Pascal User Manual and Report". Additionally, Wirth wrote another fairly famous compiler/interpreter, Pascal-S (See Barron's, "Pascal, the Language and its Implementation"), which also used the goto. Apparently later Wirth changed his ways, as I can't find mention of the goto statement in the EBNF for his Modula-2 language ("Programming in Modula-2, 1982 by N. Wirth), or in the EBNF for his Oberon language ("Compiler Construction", 1996 by N. Wirth). Note - I'm not anti/pro goto. I rarely use it myself (in C). The only time I use it is when the code is clearer with it, mainly when using an FSM.
4. RE: About GOTO (was RE: fixed windows)
- Posted by Peter Willems <peter at integratedmoves.com> Aug 06, 2003
- 376 views
Ed Davis wrote: > Well, at least in 1976, Pascal had the goto. I stand corrected then. I remember my teachers telling me the story about Wirth and goto... but that is quite some time ago. One thing is sure, they teached me that goto is a bad thing > I have N. Wirth's excellent book, "Algorithms + Data Structures = > Programs", and in this book, he develops a Pascal subset > compiler/interpreter, and the code uses goto. I don't have that book myself, but I do have one of his books (probably from a later date) about compiler design and implementation. I don't remember him discussing goto in that book though. > Also, it is listed in the Pascal EBNF published in Wirths 1978 > book "Pascal User Manual and Report". > > Additionally, Wirth wrote another fairly famous > compiler/interpreter, Pascal-S (See Barron's, "Pascal, the > Language and its Implementation"), which also used the goto. Didn't know that. > Apparently later Wirth changed his ways, as I can't find mention > of the goto statement in the EBNF for his Modula-2 language > ("Programming in Modula-2, 1982 by N. Wirth), or in the EBNF for > his Oberon language ("Compiler Construction", 1996 by N. Wirth). Yep, that's the book I have (although mine is a Dutch translation). Your information is welcome, I see I have to read back into the matter about Wirth. After my Pascal training I did some stuff with Modula 2 (I realy like that language) and currently I'm also looking into Oberon again. Hans Peter Willems
5. RE: About GOTO (was RE: fixed windows)
- Posted by Tony Bucholtz <tony_bucholtz at hotmail.com> Aug 07, 2003
- 377 views
David Cuny wrote: > > > Peter Williems wrote: > > > I'm not saying that goto is evil (although every informatics > > teacher will tell you) but the availability of a goto command > > generally does more bad than good, so there is a reason why many > > languages don't implement it. > > I suspect the reasons are more pragmatic. > > For example, I couldn't implement GOTO in the Eu (Euphoria written in > Euphoroia) because the code was stored in a tree structure. Since > Euphoria > won't give you the address of an arbitrary node, you can't just jump to > a > node - you have to traverse the tree. So coding Goto is non-trivial. > > In other languages (Lua 4, FORTH) loop values are often placed on the > stack, > incremented and ultimately discarded by the END FOR construct. Jump out > of a > FOR loop, and you leave junk on the stack. > > I can imagine that there might be some similar issues in Euphoria, where > an > arbitrary JUMP might cause a sequence not to be dereferenced properly. > (I > suspect that Robert's too clean a coder for that to be the case.) > > The main reason that I can see for a GOTO is to get you out of a deeply > nested > routine. I've seen two interesting approaches to this. > <snipped by biological entity> Sorry for jumping in late, I'm way behind on my email reading. It seems to me that a conditional goto, designed only for loop control and exiting, woould be much better than an unlimited "goto". Here's some pseudocode that outlines my thinking: for i = 1 to 10 -- imaginary "label A" <some code here> if <condition> redo -- acts like goto label A - repeats this pass thru -- the loop; index variable i doesn't change end if if <condition> loop -- acts like goto label B - skips the remainder of -- the code for this pass thru the loop end if if <condition> exit -- acts like goto label C - get out of loop NOW! end if -- imaginary "label B" end for -- imaginary "label C" The exit, redo and loop syntax would give us more control than the simple existing "exit", without using the (apparently unpopular) goto. The idea could be extended to nested loops, e.g.: for i = 1 to 10 -- imaginary "label A" for j = 1 to 10 -- imaginary "label B" <code> if <condition> redo -- goto label B end if if <condition> redo i -- here's where it gets tricky: goto label A -- note the use of the "outer loop" index to -- identify where it is we're going end if if <condition> loop -- goto label C - there's no index identifier, so -- this "loop" is scoped to the containing j loop end if if <condition> exit -- goto label D end if if <condition> exit i -- goto label E end if -- imaginary label C end for -- imaginary label D end for -- imaginary label E This would also work for "while" loops, although identifying the "while" loop in nested code may be problematic: for i = 1 to 10 while 1 do while 1 do if <condition> exit 1 -- huh? end if end while end while end for Please bear in mind that the above is the opinion of a 30-something year COBOL accounting package developer... Regards... Tony B
6. RE: About GOTO (was RE: fixed windows)
- Posted by kbochert at copper.net Aug 07, 2003
- 371 views
On 7 Aug 2003 at 14:01, Tony Bucholtz wrote: > > It seems to me that a conditional goto, designed only for loop control > and exiting, woould be much better than an unlimited "goto". Here's some > pseudocode that outlines my thinking: > > for i = 1 to 10 > -- imaginary "label A" > <some code here> > if <condition> > redo -- acts like goto label A - repeats this pass thru > -- the loop; index variable i doesn't change > end if > if <condition> > loop -- acts like goto label B - skips the remainder of > -- the code for this pass thru the loop > end if > if <condition> > exit -- acts like goto label C - get out of loop NOW! > end if > -- imaginary "label B" > end for > -- imaginary "label C" > > The exit, redo and loop syntax would give us more control than the > simple existing "exit", without using the (apparently unpopular) goto. > The idea could be extended to nested loops, e.g.: > > for i = 1 to 10 > -- imaginary "label A" > for j = 1 to 10 > -- imaginary "label B" > <code> > if <condition> > redo -- goto label B > end if > if <condition> > redo i -- here's where it gets tricky: goto label A > -- note the use of the "outer loop" index to > -- identify where it is we're going > end if > if <condition> > loop -- goto label C - there's no index identifier, so > -- this "loop" is scoped to the containing j loop > end if > if <condition> > exit -- goto label D > end if > if <condition> > exit i -- goto label E > end if > -- imaginary label C > end for > -- imaginary label D > end for > -- imaginary label E > > This would also work for "while" loops, although identifying the "while" > loop in nested code may be problematic: > > for i = 1 to 10 > while 1 do > while 1 do > if <condition> > exit 1 -- huh? > end if > end while > end while > end for > Whats interesting in the above is that comments are used to document precisely what the control constructs do, and those comments consist mostly of goto and label! If goto and label explain the flow so well... Disallowing goto jumping into loops prevents the development of spaghetti. Karl B.