1. goto considered essential
Consider the following program fragment, which copies one text file into
another text file:
sequence cmd_args
sequence cmd_line_words
sequence input_file_name
integer input_file_nr
object line
sequence output_file_name
integer output_file_nr
cmd_line_words = command_line ( )
if length ( cmd_line_words ) != 4 then
Printf ( "Exactly two arguments expected -- %d supplied.\n",
{ length ( cmd_line_words ) - 2 } )
else
cmd_args = cmd_line_words [ 3..4 ]
input_file_name = cmd_args [ 1 ]
input_file_nr = open ( input_file_name, "r" )
if input_file_nr = -1 then
Printf ( "Can't open input file %s.\n",
{ input_file_name } )
else
output_file_name = cmd_args [ 2 ]
output_file_nr = open ( output_file_name, "w" )
if output_file_nr = -1 then
Printf ( "Can't open output file %s.\n",
{ output_file_name } )
else
while 1 do
line = gets ( input_file_nr )
if atom ( line ) then
exit
end if
puts ( output_file_nr, line )
end while
Printf ( "%s copied to %s.\n",
{ input_file_name, output_file_name } )
end if
end if
end if
Without a goto statement, or something like it, we have the creeping margin
problem. In production code, with many error checks in the main logic, this
can make code very hard to understand. With a goto, we have
cmd_line_words = command_line ( )
if length ( cmd_line_words ) != 4 then
goto arg_count_is_wrong
end if
cmd_args = cmd_line_words [ 3..4 ]
input_file_name = cmd_args [ 1 ]
input_file_nr = open ( input_file_name, "r" )
if input_file_nr = -1 then
goto cant_open_input_file
end if
output_file_name = cmd_args [ 2 ]
output_file_nr = open ( output_file_name, "w" )
if output_file_nr = -1 then
goto cant_open_output_file
end if
while 1 do
line = gets ( input_file_nr )
if atom ( line ) then
exit
end if
puts ( output_file_nr, line )
end while
Printf ( "%s copied to %s.\n",
{ input_file_name, output_file_name } )
goto halt
arg_count_is_wrong:
Printf ( "Exactly two arguments expected -- %d supplied.\n",
{ length ( cmd_line_words ) - 2 } )
goto halt
cant_open_input_file:
Printf ( "Can't open input file %s.\n", { input_file_name } )
goto halt
cant_open_output_file:
Printf ( "Can't open output file %s.\n", { output_file_name } )
goto halt
halt:
Here, the main (non-error) logic is much more apparent. But what, you ask,
is then to prevent evil programmers from generating spaghetti code? Well,
nothing. So perhaps a more constrained construct would be better. In the
spirit of Ada exceptions, we might try something like this:
--
-- Function/procedure body or main program starts here.
--
cmd_line_words = command_line ( )
exception arg_count_is_wrong if length ( cmd_line_words ) != 4
cmd_args = cmd_line_words [ 3..4 ]
input_file_name = cmd_args [ 1 ]
input_file_nr = open ( input_file_name, "r" )
exception cant_open_input_file if input_file_nr = -1
output_file_name = cmd_args [ 2 ]
output_file_nr = open ( output_file_name, "w" )
exception cant_open_output_file if output_file_nr = -1
while 1 do
line = gets ( input_file_nr )
exit if atom ( line )
puts ( output_file_nr, line )
end while
Printf ( "%s has been copied to %s.\n",
{ input_file_name, output_file_name } )
--
-- Normal function/procedure return or program termination occurs here.
-- Exception handlers follow function/procedure body or main program.
--
when arg_count_is_wrong do
Printf ( "Exactly two arguments expected -- %d supplied.\n",
{ length ( cmd_line_words ) - 2 } )
-- implicit return or halt here
when cant_open_input_file do
Printf ( "Can't open input file %s.\n", { input_file_name } )
-- implicit return or halt here
when cant_open_output_file do
Printf ( "Can't open output file %s.\n", { output_file_name } )
-- implicit return or halt here
--
-- Function/procedure body or main program source code ends here.
--
The main logic is really obvious here. Not only have we eliminated the
unconstrained goto, but we have reduced the number of lines per exception
check from three to one, thus reducing the visual noise that these checks
introduce into the main logic. (Also, note the Ada-like conditional exit
statement.)
For me, some such capability is necessary in any programming language that
is to be used to write large production-quality programs. I make these
points because I understand that a major new release of Euphoria might be
in the works, and so this might be a good time to consider new features.
What do you think?
Tom Dailey
2. Re: goto considered essential
Tom Dailey wrote:
>
>
> Consider the following program fragment, which copies one text file into
> another text file:
>
> sequence cmd_args
> sequence cmd_line_words
> sequence input_file_name
> integer input_file_nr
> object line
> sequence output_file_name
> integer output_file_nr
>
> cmd_line_words = command_line ( )
> if length ( cmd_line_words ) != 4 then
> Printf ( "Exactly two arguments expected -- %d supplied.\n",
> { length ( cmd_line_words ) - 2 } )
> else
> cmd_args = cmd_line_words [ 3..4 ]
> input_file_name = cmd_args [ 1 ]
> input_file_nr = open ( input_file_name, "r" )
> if input_file_nr = -1 then
> Printf ( "Can't open input file %s.\n",
> { input_file_name } )
> else
> output_file_name = cmd_args [ 2 ]
> output_file_nr = open ( output_file_name, "w" )
> if output_file_nr = -1 then
> Printf ( "Can't open output file %s.\n",
> { output_file_name } )
> else
> while 1 do
> line = gets ( input_file_nr )
> if atom ( line ) then
> exit
> end if
> puts ( output_file_nr, line )
> end while
> Printf ( "%s copied to %s.\n",
> { input_file_name, output_file_name } )
> end if
> end if
> end if
>
> Without a goto statement, or something like it, we have the creeping margin
> problem. In production code, with many error checks in the main logic, this
> can make code very hard to understand. With a goto, we have
>
> cmd_line_words = command_line ( )
> if length ( cmd_line_words ) != 4 then
> goto arg_count_is_wrong
> end if
> cmd_args = cmd_line_words [ 3..4 ]
> input_file_name = cmd_args [ 1 ]
> input_file_nr = open ( input_file_name, "r" )
> if input_file_nr = -1 then
> goto cant_open_input_file
> end if
> output_file_name = cmd_args [ 2 ]
> output_file_nr = open ( output_file_name, "w" )
> if output_file_nr = -1 then
> goto cant_open_output_file
> end if
> while 1 do
> line = gets ( input_file_nr )
> if atom ( line ) then
> exit
> end if
> puts ( output_file_nr, line )
> end while
> Printf ( "%s copied to %s.\n",
> { input_file_name, output_file_name } )
> goto halt
>
> arg_count_is_wrong:
> Printf ( "Exactly two arguments expected -- %d supplied.\n",
> { length ( cmd_line_words ) - 2 } )
> goto halt
> cant_open_input_file:
> Printf ( "Can't open input file %s.\n", { input_file_name } )
> goto halt
> cant_open_output_file:
> Printf ( "Can't open output file %s.\n", { output_file_name } )
> goto halt
> halt:
>
> Here, the main (non-error) logic is much more apparent. But what, you ask,
> is then to prevent evil programmers from generating spaghetti code? Well,
> nothing. So perhaps a more constrained construct would be better. In the
> spirit of Ada exceptions, we might try something like this:
>
> --
> -- Function/procedure body or main program starts here.
> --
> cmd_line_words = command_line ( )
> exception arg_count_is_wrong if length ( cmd_line_words ) != 4
> cmd_args = cmd_line_words [ 3..4 ]
> input_file_name = cmd_args [ 1 ]
> input_file_nr = open ( input_file_name, "r" )
> exception cant_open_input_file if input_file_nr = -1
> output_file_name = cmd_args [ 2 ]
> output_file_nr = open ( output_file_name, "w" )
> exception cant_open_output_file if output_file_nr = -1
> while 1 do
> line = gets ( input_file_nr )
> exit if atom ( line )
> puts ( output_file_nr, line )
> end while
> Printf ( "%s has been copied to %s.\n",
> { input_file_name, output_file_name } )
> --
> -- Normal function/procedure return or program termination occurs here.
> -- Exception handlers follow function/procedure body or main program.
> --
> when arg_count_is_wrong do
> Printf ( "Exactly two arguments expected -- %d supplied.\n",
> { length ( cmd_line_words ) - 2 } )
> -- implicit return or halt here
> when cant_open_input_file do
> Printf ( "Can't open input file %s.\n", { input_file_name } )
<snip>
Robert Craig has expressed his opionion about the goto statement many times in
the past.
According to him, there is almost no chance of "goto" ever being added into
official Euphoria. He and others feel it causes "spaghetti code" execution. I am
against the goto construct for the bad programming habits it taught me in Liberty
Basic.
If you really want the goto and labels, implement them yourself in the public
domain or C back-end source code. Or use Matt's Object Oriented Euphoria and/or
Bach.
Regards,
Vincent
3. Re: goto considered essential
Your example is not the best. You probably want to refactor it, goto is not
necessary in this case. Plus, I think you use 'else' excessively where you don't
need to.
-- tested code
procedure exception(integer fatal, sequence message)
puts(2, message)
if fatal then abort(fatal) end if -- use fatal as return code
return
end procedure
sequence cmd_args
sequence cmd_line_words
sequence input_file_name
integer input_file_nr
object line
sequence output_file_name
integer output_file_nr
cmd_line_words = command_line()
if length(cmd_line_words) != 4 then
exception(1, sprintf("Exactly two arguments expected -- %d supplied.\n",
{length(cmd_line_words) - 2}))
end if
-- No need for else, it's implied
cmd_args = cmd_line_words[3..4]
input_file_name = cmd_args[1]
input_file_nr = open(input_file_name, "r")
if input_file_nr = -1 then exception(1, sprintf("Can't open input file %s.\n",
{input_file_name}))
end if
output_file_name = cmd_args[2]
output_file_nr = open(output_file_name, "w")
if output_file_nr = -1 then exception(1, sprintf("Can't open output file %s.\n",
{output_file_name}))
end if
while 1 do
line = gets(input_file_nr)
if atom(line) then exit end if
puts(output_file_nr, line)
end while
printf(1, "%s copied to %s.\n", {input_file_name, output_file_name})
This could probably be factored even better by making the argument check a
procedure and wrapping your open/close file into a procedure or function.
Now, there are generally two kinds of exceptions to handle, fatal ones such as
in the example and recoverable ones.
Exceptions that can be corrected and continue processing might benefit more from
goto. But there are still ways of working around it and still writing clear code.
For sure, Rob will *never* put goto into Euphoria. He has said as much. For much
interesting conversation and viewpoints, just do a search through the list for
"goto". Then spend a few hours (or days!) reading through all of the arguments.
If you must have goto, Matt Lewis' OOEU (Object-Oriented Euphoria) has them.
--
"The author regrets that he is unable to reconcile himself to the
thoughtful point of view you have expressed. However, it must be kept
in mind that being raised in different cultures and different places can
result in such differences of viewpoint between individuals.
The author is from planet Earth." [author unknown]
j.
4. Re: goto considered essential
- Posted by Jason Gade <jaygade at yahoo.com>
Jan 21, 2006
-
Last edited Jan 22, 2006
Vincent wrote:
> Robert Craig has expressed his opionion about the goto statement many times
> in the past.
>
> According to him, there is almost no chance of "goto" ever being added into
> official Euphoria. He and others feel it causes "spaghetti code" execution.
> I am against the goto construct for the bad programming habits it taught me
> in Liberty Basic.
>
> If you really want the goto and labels, implement them yourself in the public
> domain or C back-end source code. Or use Matt's Object Oriented Euphoria
> and/or
> Bach.
>
>
> Regards,
> Vincent
I've been thinking a bit about the next release of Euphoria. Although the major
enhancement will be for cooperative multitasking, I think that it will also
enable a general exception library to be built.
I think the yield() feature will be very powerful for certain constructs not
necessarily related to multitasking. Mainly I'm thinking of closures, I think
that's the right word, routines that maintain state and can be resumed at the
point where they yield.
--
"The author regrets that he is unable to reconcile himself to the
thoughtful point of view you have expressed. However, it must be kept
in mind that being raised in different cultures and different places can
result in such differences of viewpoint between individuals.
The author is from planet Earth." [author unknown]
j.
5. Re: goto considered essential
- Posted by John E. Franklin <johnericfranklin at rock.com>
Jan 21, 2006
-
Last edited Jan 22, 2006
How about a goto that only jumps down in the code, not back up to repeat.
Use loops to repeat: while or for loop.
But goto that jumps forward is good enough for Tom's example, but
prohibits spagetti code quite a bit.
Or have a jumpback command and a jumpforward command
to make the code easier to read and find where you
are going.
I personally like gotos because a really
smart guy whose code I used to read in C would only
return from a function at the end of it with
"return retval" usually, and he would jump to egress:,
which was a label prior to the end of a function.
Egress means to exit, so that's what he called it.
So that way you don't have two or more return statements
in one function. He set the retval and did "goto egress".
Anyhow, a jump forward and jump back would be nice for me, but
I can stand the exit_loop statement, whatever it is, I just learned
Euphoria three days ago.
6. Re: goto considered essential
- Posted by Tom Dailey <thomasdailey at comcast.net>
Jan 21, 2006
-
Last edited Jan 22, 2006
Jason:
Thank you for your detailed reply.
You characterize errors as falling into two categories,
at least in the context of this discussion. But I submit
that there is a third category, at least from the
viewpoint of a function that detects an error. In
this category are errors that are to be handled by the
caller. The function itself neither panics nor performs
recovery, but simply reports the error to the caller.
It is this class of errors that concern me most here,
insofar as code clarity is concerned. For such situations,
gotos (or something like them) are really the only answer --
unless one defines a full-blown nonlocal goto semantics,
like Java or Ada exceptions, or PL/I on-units.
Tom
7. Re: goto considered essential
- Posted by Al Getz <xaxo at aol.com>
Jan 21, 2006
-
Last edited Jan 22, 2006
John E. Franklin wrote:
>
> How about a goto that only jumps down in the code, not back up to repeat.
> Use loops to repeat: while or for loop.
> But goto that jumps forward is good enough for Tom's example, but
> prohibits spagetti code quite a bit.
> Or have a jumpback command and a jumpforward command
> to make the code easier to read and find where you
> are going.
> I personally like gotos because a really
> smart guy whose code I used to read in C would only
> return from a function at the end of it with
> "return retval" usually, and he would jump to egress:,
> which was a label prior to the end of a function.
> Egress means to exit, so that's what he called it.
> So that way you don't have two or more return statements
> in one function. He set the retval and did "goto egress".
>
> Anyhow, a jump forward and jump back would be nice for me, but
> I can stand the exit_loop statement, whatever it is, I just learned
> Euphoria three days ago.
Hi John,
There's no goto in Eu because Rob (as well as many other people who
have a lot of programming experience) believes that the resulting
code is not as structured when using goto's, and that like Vincent had
mentioned, it could lead to bad programming habits.
The best you could do is break the code into sections and call
each one from conditional statements, or use multiple returns
to exit code from various points.
I know some people dont like to use multiple returns (rather one
return at the end so that everything that happens before the return
is easier to see) but it seems to be essential to do this sometimes.
Should it be up to the programmer to use 'goto' or not?
I suppose so, after all the C compilers have it.
Will Rob ever implement this into Eu?
Who knows :) but probably not.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
8. Re: goto considered essential
- Posted by Tom Dailey <thomasdailey at comcast.net>
Jan 21, 2006
-
Last edited Jan 22, 2006
John:
The mechanism you propose sounds like a somewhat less
restricted version of what I was proposing in my final
code fragment. In fact, my C code looks just like what
you've described your friend writing, except my "egress"
is named "return_point", and what you find there is
typically "return rv;", or, for boolean functions,
"return answer;".
I think we're on the same page here.
Tom
9. Re: goto considered essential
- Posted by Jason Gade <jaygade at yahoo.com>
Jan 21, 2006
-
Last edited Jan 22, 2006
Tom Dailey wrote:
>
>
> Jason:
>
> Thank you for your detailed reply.
>
> You characterize errors as falling into two categories,
> at least in the context of this discussion. But I submit
> that there is a third category, at least from the
> viewpoint of a function that detects an error. In
> this category are errors that are to be handled by the
> caller. The function itself neither panics nor performs
> recovery, but simply reports the error to the caller.
> It is this class of errors that concern me most here,
> insofar as code clarity is concerned. For such situations,
> gotos (or something like them) are really the only answer --
> unless one defines a full-blown nonlocal goto semantics,
> like Java or Ada exceptions, or PL/I on-units.
>
> Tom
Yes, I consider those to be "recoverable" errors, whether they are handled by
the caller or by the callee or by a more generic function.
The one instance where I can see goto being useful is where you have several
conditions or loops and they all have to jump to the same point on an exception.
I would like to see better handling of jumping out of nested loops (continue x
levels or exit x levels) but I don't know how likely that will be.
--
"The author regrets that he is unable to reconcile himself to the
thoughtful point of view you have expressed. However, it must be kept
in mind that being raised in different cultures and different places can
result in such differences of viewpoint between individuals.
The author is from planet Earth." [author unknown]
j.
10. Re: goto considered essential
- Posted by Jason Gade <jaygade at yahoo.com>
Jan 21, 2006
-
Last edited Jan 22, 2006
Tom Dailey wrote:
>
>
> John:
>
> The mechanism you propose sounds like a somewhat less
> restricted version of what I was proposing in my final
> code fragment. In fact, my C code looks just like what
> you've described your friend writing, except my "egress"
> is named "return_point", and what you find there is
> typically "return rv;", or, for boolean functions,
> "return answer;".
>
> I think we're on the same page here.
>
> Tom
According to "best practices", every function should have one entrance and one
exit.
But I think you can have either multiple return statements or a goto. I don't
think there is a middle ground here. Just the nature of the beast.
I guess you could wrap the entire thing in a while loop and use exit...
while 1 do
-- some stuff
if condition1 then
-- do some condition one stuff
exit
elsif condition2 then
-- do some condition two stuff
exit
-- etcetera
end if
end while
return result
But that would break if you tried to exit out of more than one level of loop.
You would have to set a flag variable.
--
"The author regrets that he is unable to reconcile himself to the
thoughtful point of view you have expressed. However, it must be kept
in mind that being raised in different cultures and different places can
result in such differences of viewpoint between individuals.
The author is from planet Earth." [author unknown]
j.
11. Re: goto considered essential
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com>
Jan 21, 2006
-
Last edited Jan 22, 2006
Jason Gade wrote:
>
> The one instance where I can see goto being useful is where you have several
> conditions or loops and they all have to jump to the same point on an
> exception.
>
Another instance is when porting code from other languages (like C) that uses
them. It would save having to re-engineer the program flow, and adding extra
flags to the code to simulate fall through in case statements.
Matt Lewis
12. Re: goto considered essential
- Posted by Jason Gade <jaygade at yahoo.com>
Jan 21, 2006
-
Last edited Jan 22, 2006
Matt Lewis wrote:
>
> Jason Gade wrote:
> >
> > The one instance where I can see goto being useful is where you have several
> > conditions or loops and they all have to jump to the same point on an
> > exception.
> >
>
> Another instance is when porting code from other languages (like C) that uses
> them. It would save having to re-engineer the program flow, and adding extra
> flags to the code to simulate fall through in case statements.
>
> Matt Lewis
I forgot about fall through in case statements!
But yeah, I was going to try to port rogue to Euphoria several years ago and I
got stumped on a part that used a goto. Basically it checked a condition and then
either started at the beginning of the game loop or jumped into the middle of it.
I couldn't figure out how to do it without writing a section of code twice.
Someone gave me the answer, it's here in the message archive somewhere.
I never did finish porting that program...
--
"The author regrets that he is unable to reconcile himself to the
thoughtful point of view you have expressed. However, it must be kept
in mind that being raised in different cultures and different places can
result in such differences of viewpoint between individuals.
The author is from planet Earth." [author unknown]
j.
13. Re: goto considered essential
- Posted by C Bouzy <eucoder at hotmail.com>
Jan 21, 2006
-
Last edited Jan 22, 2006
Tom,
If you were to do a search you will come across numerous discussions regarding
goto. Robert is not going to add goto, and in my opinion it does very little
to help the language.
----If you continue to do what you have always done,
you will get what you have always gotten.----
14. Re: goto considered essential
C Bouzy wrote:
>
> Tom,
>
> If you were to do a search you will come across numerous discussions regarding
> goto. Robert is not going to add goto, and in my opinion it does very little
> to help the language.
>
> ----If you continue to do what you have always done,
> you will get what you have always gotten.----
If we are talking about "bad programming habits" as main deterrent for goto,
then I would say that no programming language can have any bad habits. It is
the programmer who can.
Any programming language provides various resources for the programmer to
build his/her logic. It is really up to the programmer to use the bad or
good logic using these resources.
It is possible to write a program with worst logic which doesn't have a
single goto as well as a best program which makes use of goto’s at
essential points. To pick up these essential points is the programmer’s job.
In end, goto’s won’t hurt from the programming language perspective, but
can hurt from programmer’s viewpoint, if not used properly.
Eu should implement goto if possible and allow the programmer to take
a call on it.
Regards,
Rad.
15. Re: goto considered essential
Rad wrote:
>
> C Bouzy wrote:
> >
> > Tom,
> >
> > If you were to do a search you will come across numerous discussions
> > regarding
> > goto. Robert is not going to add goto, and in my opinion it does very little
> > to help the language.
> >
> > ----If you continue to do what you have always done,
> > you will get what you have always gotten.----
>
> If we are talking about "bad programming habits" as main deterrent for goto,
> then I would say that no programming language can have any bad habits. It is
> the programmer who can.
>
> Any programming language provides various resources for the programmer to
> build his/her logic. It is really up to the programmer to use the bad or
> good logic using these resources.
>
> It is possible to write a program with worst logic which doesn't have a
> single goto as well as a best program which makes use of goto’s at
> essential points. To pick up these essential points is the programmer’s job.
>
> In end, goto’s won’t hurt from the programming language perspective, but
> can hurt from programmer’s viewpoint, if not used properly.
> Eu should implement goto if possible and allow the programmer to take
> a call on it.
>
> Regards,
> Rad.
I'm weird this way. I don't normally think this way but in this case I do.
I don't want to tell people they can or can't do something, but I wouldn't want
to see goto added to Euphoria. I've seen a lot of good arguments for it but none
of them have swayed me.
Adding goto probably wouldn't change my personal style. It is just one of those
things that I think would lessen the beauty of the language.
--
"The author regrets that he is unable to reconcile himself to the
thoughtful point of view you have expressed. However, it must be kept
in mind that being raised in different cultures and different places can
result in such differences of viewpoint between individuals.
The author is from planet Earth." [author unknown]
j.
16. Re: goto considered essential
Rad wrote:
>
> C Bouzy wrote:
> >
> > Tom,
> >
> > If you were to do a search you will come across numerous discussions
> > regarding
> > goto. Robert is not going to add goto, and in my opinion it does very little
> > to help the language.
> >
> > ----If you continue to do what you have always done,
> > you will get what you have always gotten.----
>
> If we are talking about "bad programming habits" as main deterrent for goto,
> then I would say that no programming language can have any bad habits. It is
> the programmer who can.
>
> Any programming language provides various resources for the programmer to
> build his/her logic. It is really up to the programmer to use the bad or
> good logic using these resources.
>
> It is possible to write a program with worst logic which doesn't have a
> single goto as well as a best program which makes use of goto’s at
> essential points. To pick up these essential points is the programmer’s job.
>
> In end, goto’s won’t hurt from the programming language perspective, but
> can hurt from programmer’s viewpoint, if not used properly.
> Eu should implement goto if possible and allow the programmer to take
> a call on it.
>
> Regards,
> Rad.
Hello Rad,
There are still two schools of thought on that...
1. It's all up the the programmer so allow the user to decide
so include a 'goto'.
2. Put 'goto' in the hands of an inexperienced programmer and he/she,
will develop bad programming habits, so dont include a 'goto'.
The argument of which one is right (1 or 2 above) has been going on
for years and years (earlier than 1980) so it's doubtful that we will
come up with any conclusive argument one way or the other here.
It's all been said 100000 times over and over again.
Some people believe (1) and some (2) and that's all there is to it.
If you write your own language you put it or dont put it according
to what YOU want.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
17. Re: goto considered essential
> In end, goto’s won’t hurt from the programming language perspective, but
> can hurt from programmer’s viewpoint, if not used properly.
> Eu should implement goto if possible and allow the programmer to take
> a call on it.
In the end Robert will never implement goto, so this thread is a waste of
everyone’s time. This subject has been raised countless times, and as you
can see goto has not been added to the language, and it should be that way.
If goto is so important to you, you could always add it yourself, but according
to Robert goto will remain out of the official version of EU.
----If you continue to do what you have always done,
you will get what you have always gotten.----
18. Re: goto considered essential
C Bouzy wrote:
>
>
> > In end, goto’s won’t hurt from the programming language perspective, but
> > can hurt from programmer’s viewpoint, if not used properly.
> > Eu should implement goto if possible and allow the programmer to take
> > a call on it.
>
> In the end Robert will never implement goto, so this thread is a waste of
> everyone’s time. This subject has been raised countless times, and as you
> can see goto has not been added to the language, and it should be that way.
> If goto is so important to you, you could always add it yourself, but
> according
> to Robert goto will remain out of the official version of EU.
>
Yes, I agree that there are 2 separate lines of thinking on goto.
As I am not a systems programmer by any standards, writing my own language
with goto's is not possible for me. But yes, if I had a decision making
power regarding inclusion of goto in any language, I would have granted it.
Goto is just an item in my wish-list. I was not telling anybody to do
anything about it. I apologise if I have stepped on anybody's toes
unknowingly.
I would rather appreciate a practical programming language than a beautiful
one.
It is just like using Credit Card services, a payment option available for a
person. It can be said that CC might put you in bad habits. It can be
misused. Precautions should be taken. Yes. True. But still the CC system
is in place. Depends on the person and how he uses it, if at all used in
first place.
Hmmmmmm.....
Regards,
Rad.
