OpenEuphoria

The 'goto' debate

• Posted by Derek Parnell <ddparnell at bigpond.com> Feb 05, 2002
• 482 views

6/02/2002 3:00:06 PM, euman at bellsouth.net wrote:
>
>Either Im totaly missing something about GOTO or I just
>havent had a real pressing need for them in any language
>I've tried out.

DISCLAIMER. The following are just opinions.

The only justification for GOTO is create the fastest or smallest (memory
footprint) routine
possible. And nobody in their right mind would be using Euphoria to do that.
Most people would use C
or, more likely, Assembler for that. And those languages already have a GOTO.

All the other reasons for using a GOTO can, and should, be coded using other
constructs. I would
argue that Euphoria has not got all the possible GOTO-less solutions and could
still do with a few
new keywords to help us out. But that is another issue.

I believe the the main purpose of programming languages is to convey the meaning
of the program to
human readers. That is why we have compliers/interpreters/translators - to
convert the program into
machine language. If programming languages are meant to the read by people, they
should strive to
make that easy. One of the problems with GOTO is that it tends to hide or
obscure logic and
algorithm flows. This is because one can never be sure of the processing scope
of a line of code, if
you can't know how the processing gets there. And with GOTO it is easy to cause
the physical code
layout to misrepresent the local processing flow. And this causes people to make
mistakes.

For example...

    if functionA() then
  label_1:
       fld1 = functionB()
    end if

If one sees these four lines of code, you can not be sure that functionB() will
only be called if
functionA() returns TRUE. This is because it is possible that a GOTO somewhere
else in the code
references label_1. If this is in the back of one's mind, it makes coding and
debugging all that
much harder. You constantly have to be checking all the possible processing
paths to make sure you
don't trip over some side-effect of the GOTO.

Another issue with Euphoria and GOTO is that due to Euphoria's philosophy of 'no
forward
references', any GOTO would be restricted to labels lexically before the GOTO
statement. In other
words, you couldn't skip forward to a label. This could hamper earlier exits to
handle error
conditions - a common use of GOTOs.

And it must be realised that non-use of GOTO is not automatically a sign of good
programming style.
Consider this example...

   integer x
   x = 1
   while x <> 0 do
      if x = 1 then
          procedureA()
          x = 5
      elsif x = 2 then
          x = functionB()
      elsif x = 3 then
          procedureC()
          x = 2
      elsif x = 4 then
          procedureD()
          x = 1
      elsif x = 5 then
          if functionE() then
              x = functionF()
          else
              x = 0
          end if
      else
         x = 1
      end if 
   end while

Using the code above, when is functionB() called?

Having seen the source code for RDS's implementation of Euphoria, I also believe
that it would be
difficult to implement GOTO without significant rework. That is not to say that
Euphoria's syntax
couldn't cope with a GOTO, just that this particular implementation would
struggle.

Finally, in spite of these opinions, I have no problem with anybody else using
GOTO in their
programs. I will just have a reduced confidence level with using those programs.

---------
Cheers,
Derek Parnell