1. GOTO
I have an idea for a restricted goto:
1. A label would be allowed only immediately before or immediately after a
loop termination (end for or end while) statement.
2. A label could be branched to only from within the loop, including nested
loops:
for i=1 to 50 do
-- some statements
while 1 do
-- lots of statements
if x=1 then goto continue_while end if
if x=2 then goto continue_for end if
if x=3 then goto exit_while end if -- could use exit here
if x=4 then goto exit_for end if
-- lots more statements
continue_while:
end while
exit_while:
-- more statements
continue_for:
end for
exit_for:
-- rest of program
This would simplying nested loop coding while virtually eliminating
potential abuse. Note that only the case where x=3 is now doable without
flag variables, etc. I believe this is much more readable than flags.
How difficult would this be to implement?
-- Mike Nelson
2. Re: GOTO
- Posted by Robert Craig <rds at RAPIDEUPHORIA.COM>
Jan 19, 2001
-
Last edited Jan 20, 2001
Mike Nelson writes:
> How difficult would this be to implement?
GOTO's, as David Cuny pointed out the other day,
are pretty easy to implement, in almost any form
you can imagine. They aren't in Euphoria
mainly because of my religious convictions.
A multi-level exit is somewhat less objectionable to me,
but I'm not in a big hurry to do it, since I don't think
it comes up that often, and there are ways to
deal with it when it does arise.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: GOTO
Michael Nelson said:
> I have an idea for a restricted goto:
>
> 1. A label would be allowed only immediately before or immediately after a
> loop termination (end for or end while) statement.
Many years ago, the University of Waterloo implemented the UW_Tools, a
series of extensions to the Time Sharing Command Library for Bull's GCOS 8
operating system. Now under the care of Thinkage, Ltd., they still run on
some venerable DPS 9000's.
The UW_Tools included the EXEC command, a command file (read 'batch')
processor with its own internal language. EXEC included one of the strangest
implementations of GOTOs I've ever seen. Two main differences were apparent:
a) With a $*$REWIND [ ON | OFF ] statement you could control whether the
search for the label, if failed at EOF, would restart at the beginning of
the file. This let you build very interesting recursions, especially since
you could reset $*$REWIND any way and any place you chose.
b) You could add a $*$CATCH statement, which acted as a 'catch-all' label
for any $*$GOTO without a matching label. Very useful for debugging.
Goes without saying that this made for some of the strangest-looking code
I've ever seen or written, hardest to follow since APL.
> 2. A label could be branched to only from within the loop, including
nested
> loops:
>
> for i=1 to 50 do
> -- some statements
> while 1 do
> -- lots of statements
> if x=1 then goto continue_while end if
> if x=2 then goto continue_for end if
> if x=3 then goto exit_while end if -- could use exit here
> if x=4 then goto exit_for end if
> -- lots more statements
> continue_while:
> end while
> exit_while:
> -- more statements
> continue_for:
> end for
> exit_for:
> -- rest of program
>
> This would simplying nested loop coding while virtually eliminating
> potential abuse. Note that only the case where x=3 is now doable without
> flag variables, etc. I believe this is much more readable than flags.
>
This is actually useful in some cases. However, I would suggest using 'next'
and 'exit' statements instead of the 'goto / label' constructs. Still more
readable, less code and probably less overhead:
> for i=1 to 50 do
> -- some statements
> while 1 do
> -- lots of statements
> if x=1 then next while end if
> if x=2 then next for end if
> if x=3 then exit while end if
> if x=4 then exit for end if
> -- lots more statements
> end while
> -- more statements
> end for
> -- rest of program
And maybe we could even bring back an updated version of Fortran's 'computed
goto':
goto (next while, next for, exit while, exit for), x
Sorry. I just couldn't resist adding to the confusion ...
Gerardo E. Brandariz
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
4. Re: GOTO
- Posted by Jim <futures8 at earthlink.net>
Jan 20, 2001
-
Last edited Jan 21, 2001
Hi, Rob,
But how about a "loop" (or, as some call it, "continue") to conditionally
return to the beginning of a loop from any
point within? I guess some would call this a 'goto', but if it is, it's a
controlled goto, one which I would find quite
useful. Given that we have, in Euphoria, an 'exit' statement, how about the
reverse?
How say ye?
Regards (and thanks for Euphoria!)
Jim
Robert Craig wrote:
> Mike Nelson writes:
> > How difficult would this be to implement?
>
> GOTO's, as David Cuny pointed out the other day,
> are pretty easy to implement, in almost any form
> you can imagine. They aren't in Euphoria
> mainly because of my religious convictions.
>
> A multi-level exit is somewhat less objectionable to me,
> but I'm not in a big hurry to do it, since I don't think
> it comes up that often, and there are ways to
> deal with it when it does arise.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
5. Re: GOTO
- Posted by Robert Craig <rds at RAPIDEUPHORIA.COM>
Jan 20, 2001
-
Last edited Jan 21, 2001
Jim writes:
> But how about a "loop" (or, as some call it, "continue")
> to conditionally return to the beginning of a loop from any
> point within?
This was discussed a while back.
My personal view of "continue" is that
I rarely feel the need for it, and I don't see
much difference between:
while ... do
...
if x != 0 then
continue
end if
<more statements>
end while
and:
while ... do
...
if x = 0 then
<more statements>
end if
end while
I cheated a bit by using != in the continue example
and = in the second example, but the continue
example actually requires one more statement.
In more complicated, but less common situations
continue would be more convenient.
continue is an example of a statement that
would provide some convenience in some
situations, and so you might think it should
be added. The trouble is, there are dozens of
such features, and I believe if they were all
added, the language manual would be harder
to digest without there being much more power.
The small size of the language is also helpful
when porting to other platforms, and in writing
various tools, such as Euphoria To C, and David's
Euphoria To Java, etc.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: GOTO
- Posted by Tony Bucholtz <tony_bucholtz at HOTMAIL.COM>
Jan 21, 2001
-
Last edited Jan 22, 2001
G'day all
I get my postings via digest, and haven't followed this thread word for
word, so if I'm repeating someone else's ideas... oops, sorry :(
Using the following as an example:
while 1 do
while 1 do
if condition then
doExit = true -- set flag
exit
end if
end while
-- we now have to check this flag "every time"
if doExit = true then
exit
end if
-- more code
end while
can lead to some ugly code (especially when the doExit flag is a long way
from the interior end while, or where lots of conditions are being tested,
etc. What I propose is a new "until" statement, in the form
until <condition> then
-- code
end until
The code inside the "until" block would execute until <condition> becomes
true. Euphoria could detect that <condition> had become true at any point
in the code, and "pretend" that the programmer had coded an "if..exit..end
if" thing. For example:
until doExit = true do
while 1 do
if condition then
doExit = true -- triggers immediate exit from "until" block
end if
end while
-- more code (run only if doExit is still false)
end until
This change to the language would result in nice neat code, and wouldn't
break any existing stuff out there. Of course, it should be possible to
use a normal "exit" statement somewhere inside the "until" block, eg:
until doExit = true do
while 1 do
if condition1 then
doExit = true -- triggers immediate exit from "until" block
end if
-- some more code (run only if doExit is still false)
if condition2 then
exit -- only exit from this "while" block
end if
for i = 1 to 20 do
if condition3 then
doExit = true -- triggers immediate exit from "until" block
end if
-- some more code (run only if doExit is still false)
if condition4 then
exit
end if
next
end while
-- more code (run only if "exit" used inside "while" loop)
end until
The "until" statement should be able to handle multiple flags by a method
similar to the next example. This example shows a method for determining
where in the "until" block the exit came from, as well as an example of
exiting a for loop:
until or_all(doExit1, doExit2) = true do
while 1 do
if condition1 then
doExit1 = true -- triggers immediate exit from "until" block
end if
-- some more code (run only if doExit is still false)
if condition2 then
exit -- only exit from this "while" block
end if
for i = 1 to 20 do
if condition3 then
doExit2 = true -- triggers immediate exit from "until" block
end if
-- some more code (run only if doExit is still false)
if condition4 then
exit
end if
next
end while
-- more code (run only if "exit" used inside "while" loop)
end until
if doExit1 = true then
-- oopscode #1
elsif doExit2 = true then
-- oopscode #2
end if
This assumes that a "goto"-like thing would only be used for exiting loops,
and not implemented in a "goto label" style generic goto. Personally, I've
maintained enough spaghetti code already in this lifetime, and I'd hate to
see Euspaghetti!
Regards
Tony
7. Re: GOTO
G'day all
I just re-read my last post, what a shambles. Please forget I spoke, and
I'll go away quietly...
Regards
Tony
8. GOTO
I am a GW-BASIC Programming veteran.
I know how to use GOTO.
I know how not to use GOTO.
I know many of the messes I got myself into using GOTO.
I know how easy it is to use it and then forget how many
times and from where I used it.
GOTO, as it was used in BASIC provides room to create
some very nasty code. Just as others have said, The
problem with GOTO is that once you reach the label.
You don't really have anything telling you how you got
to the label.
Examine the following code.
SENTENCE$="This is a relatively short sentence."
INPUT B
IF B > 7 THEN GOTO Second
INPUT A
ON A GOTO First, Second
First:
A = A + B
Second:
PRINT MID$(SENTENCE$, A, 1)
Now assume that the code crashed at the PRINT MID$() command.
Did the error happen because of A = A + 5. Or was that even
called? Obviously this is a very small program example and
would be easy enough to track. But assume that this is larger
program. Say 200 lines or more. Many variables. Many
commands called. You aren't really sure what the value of 'A'
or 'B' is at the point when it crashed. And even if you do,
You don't really know how you reach the line that finally
crashed. Also, That example only covers calling either
label from 1 or 2 places. It is entirely possible for a
program to jump to a Label from many different places in a
program.
------------------
Let's consider nested for loop exit problem more carefully.
------------------
integer exit_flag
exit_flag = 0
for A = 1 to 50 do
for B = 1 to 30 do
for C = 1 to 75 do
if get_key() != -1 then
exit_flag = 1
exit
end if
end for
if exit_flag = 1 then
exit
end if
end for
if exit_flag = 1 then
exit
end if
end for
------------------
Why don't we consider suggesting this instead.
------------------
integer exit_flag
exit_flag = 0
for A = 1 to 50 do
for B = 1 to 30 do
for C = 1 to 75 do
if get_key() != -1 then
exit_flag = 1
exit(A)-- or exit[A]
end if
end for
end for
end for
------------------
In this case A isn't being used as a variable.
It is being used as a descriptor to a specific for
loop that has been automagically created thanks to Roberts
Genius creation called Euphoria.
This really does look like a much more pleasing alternative to
GOTO.
Do you want GOTO?
Do you think it should be limited to only 1 GOTO per LABEL?
Do you think it should ONLY go forward?
Do you think you should NOT be able to jump into program BLOCKS?
Do you think you should be allowed to jump out of program BLOCKS?
Oops. That sure kills jumping out of a for loop.
Maybe jumping out of a for loop is to be allowed.
Just can't jump out of a procedure or function.
PS: I consider myself to be very good at using/abusing GOTO.
That is one reason I am so dead set against its introduction.
PLEASE, consider other options.
Lucius L. Hilley III
lhilley at cdc.net lucius at ComputerCafeUSA.com
+----------+--------------+--------------+
| Hollow | ICQ: 9638898 | AIM: LLHIII |
| Horse +--------------+--------------+
| Software | http://www.cdc.net/~lhilley |
+----------+-----------------------------+
9. Re: GOTO
Lucius L. Hilley III wrote:
> integer exit_flag
>
> exit_flag = 0
> for A = 1 to 50 do
> for B = 1 to 30 do
> for C = 1 to 75 do
> if get_key() != -1 then
> exit_flag = 1
> exit(A)-- or exit[A]
> end if
> end for
> end for
> end for
This will only exit the innermost loop (C).
> Do you want GOTO?
Not necessarily.
> Do you think it should be limited to only 1 GOTO per LABEL?
No.
> Do you think it should ONLY go forward?
Yes.
> Do you think you should NOT be able to jump into program BLOCKS?
Yes.
> Do you think you should be allowed to jump out of program BLOCKS?
Yes - otherwise, there would be little use for it.
-- David Cuny
10. Re: GOTO
I wrote:
> ... only exit the inner loop (C).
Sorry, I misread your comment. I convered my complaint in a prior post: This
only works with FOR loops.
-- David Cuny
11. Re: GOTO
> ---------------------- Information from the mail
header -----------------------
> Sender: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
> Poster: "Cuny, David at DSS" <David.Cuny at DSS.CA.GOV>
> Subject: Re: GOTO
> --------------------------------------------------------------------------
-----
>
> Lucius L. Hilley III wrote:
>
>
> > integer exit_flag
> >
> > exit_flag = 0
> > for A = 1 to 50 do
> > for B = 1 to 30 do
> > for C = 1 to 75 do
> > if get_key() != -1 then
> > exit_flag = 1
> > exit(A)-- or exit[A]
> > end if
> > end for
> > end for
> > end for
>
> This will only exit the innermost loop (C).
>
Correction, It will crash.
Euphoria doesn't support that proposed method.
<SNIP polling votes>
>
> -- David Cuny
>
Lucius L. Hilley III
lhilley at cdc.net lucius at ComputerCafeUSA.com
+----------+--------------+--------------+
| Hollow | ICQ: 9638898 | AIM: LLHIII |
| Horse +--------------+--------------+
| Software | http://www.cdc.net/~lhilley |
+----------+-----------------------------+
12. Re: GOTO
- Posted by Everett Williams <rett at GVTC.COM>
Nov 15, 1999
-
Last edited Nov 16, 1999
Lucius L. Hilley III wrote:
>Why don't we consider suggesting this instead.
>------------------
>integer exit_flag
>
>exit_flag = 0
>for A = 1 to 50 do
> for B = 1 to 30 do
> for C = 1 to 75 do
> if get_key() != -1 then
> exit_flag = 1
> exit(A)-- or exit[A]
> end if
> end for
> end for
>end for
>
>------------------
>In this case A isn't being used as a variable.
>It is being used as a descriptor to a specific for
>loop that has been automagically created thanks to Roberts
>Genius creation called Euphoria.
>
>This really does look like a much more pleasing alternative to
>GOTO.
>
>Do you want GOTO?
>Do you think it should be limited to only 1 GOTO per LABEL?
>Do you think it should ONLY go forward?
>Do you think you should NOT be able to jump into program BLOCKS?
>Do you think you should be allowed to jump out of program BLOCKS?
> Oops. That sure kills jumping out of a for loop.
> Maybe jumping out of a for loop is to be allowed.
> Just can't jump out of a procedure or function.
>
>
>
>PS: I consider myself to be very good at using/abusing GOTO.
> That is one reason I am so dead set against its introduction.
> PLEASE, consider other options.
>
I love that construct. It allows exit from any depth of for without any
knowledge of what that depth is. Now if we can have something of the
form of
while(A) x = 1 do
while(B) y = 2 do
while(C) z = 3 do
...
exit(A)
end while
end while
end while
Then most of the problem will have been solved with no need for labels
additional blocks or goto's and with only a tiny extension to the exit
verb.
I like it! Let's do it...oops...let's hope someone else does it.
Everett L.(Rett) Williams
rett at gvtc.com
13. Re: GOTO
>I love that construct. It allows exit from any depth of for without any
>knowledge of what that depth is. Now if we can have something of the
>form of
>
>while(A) x = 1 do
> while(B) y = 2 do
> while(C) z = 3 do
>
> ...
>
> exit(A)
>
> end while
> end while
>end while
how about:
while:A x = 1 do
while y = 2 do
while z = 3 do
...
exit:A
end while
end while
end while
--
That way it won't break existing code, and you get a choice of only naming
the loops that you realy need to.
you can then either use:
while / exit
or
while:label / exit:label
I think that seems like quite a tidy way to fix that problem.
-Mark.
14. Re: GOTO
On Mon, 15 Nov 1999 20:58:04 -0500, Liquid-Nitrogen Software <nitrogen_069 at
HOTMAIL.COM> wrote:
>>I love that construct. It allows exit from any depth of for without any
>>knowledge of what that depth is. Now if we can have something of the
>>form of
>>
>>while(A) x = 1 do
>> while(B) y = 2 do
>> while(C) z = 3 do
>>
>> ...
>>
>> exit(A)
>>
>> end while
>> end while
>>end while
>
>
>how about:
>
> while:A x = 1 do
> while y = 2 do
> while z = 3 do
>
> ...
>
> exit:A
>
> end while
> end while
> end while
>
>--
>That way it won't break existing code, and you get a choice of only naming
>the loops that you realy need to.
>
>you can then either use:
> while / exit
> or
> while:label / exit:label
>
>I think that seems like quite a tidy way to fix that problem.
>
>-Mark.
Funny you should ask, I was planning to retain the original forms and
my purpose was to avoid adding labels. The less we ask for, the more
likely we are to get it. Besides, I don't really want labels. They would
create a demand for goto...again and that I consider anathema.
There should be a slightly better syntax that would preserve those goals,
but my tired old brain just won't kick one out right now.
Somebody else take a shot.
Everett L.(Rett) Williams
rett at gvtc.com
15. GOTO
I don't like GOTO. I am strongly opposed to GOTO being added.
It easily allows for very difficult to understand coding styles.
It isn't required for the language.
It may not be used improperly with the current Eu list.
What about the future users on the list? They may use it terribly.
Lucius L. Hilley III
16. Re: GOTO
- Posted by Colin Taylor <71630.1776 at COMPUSERVE.COM>
Sep 23, 1997
-
Last edited Sep 24, 1997
Sorry to malign the much-loved *goto* statement.
In my earlier comments about global variables I simply wanted to point ou=
t
that these can become a quick fix and create spaghetti-like code that is
difficult to debug. For that reason, it is better to encapsulate routine=
s
as much as possible by passing variables to the routines and having
variables returned.
Colin Taylor
