1. RE: About GOTO (was RE: fixed windows)
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)
> David Cuny wrote...
Thanks, David. Learning what/why without any good/bad connotation is
refreshing.
3. RE: About GOTO (was RE: fixed windows)
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)
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)
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
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.
