Example of Scoping Issues

Consider the following example,

    SUBROUTINE sub1         ! scope sub1
      IMPLICIT NONE         ! scope sub1
      REAL A, B, C          ! scope sub1
       ...                  ! scope sub1
      CALL sub2             ! scope sub1
      CALL sub3(A)          ! scope sub1
      CALL sub4(A)          ! scope sub1
       ...                  ! scope sub1
    CONTAINS
      SUBROUTINE sub2       ! scope sub2
        REAL B              ! scope sub2
         ...                ! scope sub2
        B = ...             ! scope sub2
        A = B               ! B from sub2; A from sub1
      END SUBROUTINE sub2
      SUBROUTINE sub3(D)    ! scope sub3
        REAL C, D           ! local C, D
         ...                ! scope sub3
        C = A**3   ! A cannot be changed
        D = D**3 + C        ! D is A
        B = C               ! B from sub1; C from sub3 
         ...                ! scope sub3
      END SUBROUTINE sub3
    END SUBROUTINE sub1

    SUBROUTINE sub4       ! scope sub4
     IMPLICIT NONE        ! scope sub4
      REAL B, C           ! scope sub4
       ...                ! scope sub4
      B = C               ! scope sub4
       ...                ! scope sub4
    END SUBROUTINE sub4

This demonstrates most of the issues concerning the scope of names in procedures.

If an internal procedure declares an object with the same name as one in the host (containing) procedure then this new variable supersedes the one from the outer scope for the duration of the procedure, for example, sub2 accesses A from sub1 but supersedes B by declaring its own local object called B. This B (in sub2) is totally unrelated to the B of sub1.

Internal procedures may have dummy arguments, however, any object used as an actual argument to an internal procedure cannot be changed by referring to it by its original name in that procedure; it must be assigned to using its dummy name. For example, sub3 accesses A, known locally as D, by argument association and is forbidden to assign a value to or modify the availability of A; it must be altered through its corresponding dummy argument (see P180 of Fortran 90 standard, [1]). The variable A can still be referenced in sub3 as if it possessed the INTENT(IN) attribute (see Section 4.1.11 for the implications of the INTENT attribute).

A local variable called A could be declared in sub3 which would clearly bear no relation to the A which is argument associated with d. sub3 also accesses B from sub1, but C is entirely local and supersedes C from sub1 for the duration of the call. When sub3 is exited and control is returned to sub1, the value that C had before the call to sub3 is restored.

sub4 does not access any objects from sub1, sub2 or sub3 -- it is an external procedure and consequently is totally separate.

Now try this question