Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert
From: hirchert@uxe.cso.uiuc.edu
Newsgroups: comp.lang.fortran
Subject: Re: EQUIVALENCE, COMPUTED GO TO in FORT
Message-ID: <50500173@uxe.cso.uiuc.edu>
Date: 15 Dec 89 01:36:28 GMT
References: <143@suntc.UUCP>
Lines: 105
Nf-ID: #R:suntc.UUCP:143:uxe.cso.uiuc.edu:50500173:000:3560
Nf-From: uxe.cso.uiuc.edu!hirchert    Dec 14 12:02:00 1989


jlg@lambda.UUCP writes:
>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.

In the sense that internal procedures are nested, procedures simulated with
assigned GO TO are not nested at all; i.e. they have no local scope.
Procedures simulated with assigned GO TO can call each other, but then so can
internal procedures.  What is it that you can do with the assigned GO TO that
you think you can't do with an internal procedure?

>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.

This is very much a matter of taste.  Some people would argue that

      IF (1 <= iselect .and. iselect<=3) THEN
         IF (iselect <= 2) THEN
            IF (iselect <= 1) THEN
               [Print the day of week]
            END IF
            [Print the date]
         END IF
         [Print the time]
      ELSE
         STOP 'ISELECT is out of range'
      END IF

is more descriptive of what you are doing.  Others would argue in favor of

      SELECT CASE (iselect)
      CASE(1)
         CALL PRINT_DAY_OF_WEEK
         CALL PRINT_DATE
         CALL PRINT_TIME
      CASE(2)
         CALL PRINT_DATE
         CALL PRINT_TIME
      CASE(3)
         CALL PRINT_TIME
      CASE DEFAULT
         STOP 'ISELECT is out of range'
      END SELECT

where the logic to print the day of week, date, and time has been moved to
appropriately named internal procedures.  Another might argue in favor of

      itemp=iselect
      DO
         SELECT CASE (itemp)
         CASE(1)
            [Print day of week]
         CASE(2)
            [Print date]
         CASE(3)
            [Print time]
            EXIT
         CASE DEFAULT
            STOP 'ISELECT is out of range'
         END SELECT
         itemp=itemp+1
      END DO

Yet another might replace the above loop with a DO loop starting at iselect.
Someone else might control the who process by a decision table.  Finally, some
people might simply replace your computed GO TO with

      SELECT CASE (iselect)
      CASE(1); GO TO 101
      CASE(2); GO TO 102
      CASE(3); GO TO 103
      CASE DEFAULT; STOP 'ISELECT is out of range'
      END SELECT

and claim that although this is somewhat more verbose it is equally readable 
and maintainable.

Fortunately, computed GO TO is an ordinary part of Fortran 8x, which means
that at worst it would be made obsolescent in the next revision in order to be
removed from the revision following that, so none of us are likely to have to
worry about replacing any computed GO TOs for at least 20 years.

Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications