Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!ccnysci!phri!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: EQUIVALENCE, COMPUTED GO TO in FORTRAN 88?
Message-ID: <14167@lambda.UUCP>
Date: 12 Dec 89 00:28:44 GMT
References: <581@unmvax.unm.edu>
Lines: 63

From article <581@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd):
> [...]
> 1.  Arithmetic IF obviously can be replaced with logical or block IF.

And ... Logical or block IFs can obviously be replaced by arithmetic
IFs as well.  The battle over which is better _in_general_ has already
been waged elsewhere.  My question is: if you don't want people to use
the arithmetic if, WHY define the IOSTAT parameter in such a way that
a three way branch is the most natural?

> [...]
> 5.  An ASSIGN and assigned GO TO can be replaced by assigning the value
>     to an integer and then branching with a block IF based on the value.

Suppose I have a code sequence:

C      With assigned GOTO            C     Without assigned GOTO

  999 continue                         999 continue
      ...                                  ...
      [code to do some useful thing]       [code for same useful thing]
      ...                                  ...
      goto iret                            if (iret.eq.1) then
                                              [goto the first return]
                                           ...
                                           endif

This faces two problems.  First, the assigned GOTO is MUCH more
readible and easy to maintain.  Second, if you add another 'call'
to the 999 label the assigned GOTO version doesn't need to be
modified - the other does.

The feature that REALLY replaces the assigned GOTO is internal
procedures.  Except internal procedures can't be nested and
assigned GOTO can allow nested usage.

> [...]
> (The computed GO TO could be replaced by block IFs, but not
> as gracefully and efficiently, but will be replaceable by the 8x
> CASE statement.)

MOST uses of the computed GOTO can be done as CASE statements.  Indeed,
most of my usage of computed GOTO directly emulates CASE statement
semantics.  However, neither block IFs nor CASE statements allow a
satisfactory replacement for the following:

      GOTO (101,102,103), iselect
      STOP 'ISELECT is out of range'

  101 continue
         [Print the day of week]
  102 continue
         [Print the date]
  103 continue
         [Print the time]

Here the code has been written to "gradually" change its behaviour
based on the ISELECT variable.  It either prints just the time, or
the date and the time, or the day-of-week plus date and time.
Solutions to do this without the computed GOTO always are harder
to read and maintain than this is.  I come across this "gradual"
code shift problem only once in a while, but when I do there's
nothing better than the existing computed GOTO.