Consider the following example,
PROGRAM Proggie ! scope Proggie IMPLICIT NONE REAL :: A, B, C ! scope Proggie CALL sub(A) ! scope Proggie CONTAINS SUBROUTINE Sub(D) ! scope Sub REAL :: D ! D is dummy (alias for A) REAL :: C ! local C (diff to Proggies' C) C = A**3 ! A cannot be changed D = D**3 + C ! D can be changed B = C ! B from Proggie gets new value END SUBROUTINE Sub SUBROUTINE AnuvvaSub ! scope AnuvvaSub REAL :: C ! another local C (unrelated) ..... END SUBROUTINE AnuvvaSub END PROGRAM Proggie
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) program unit then this new variable supersedes the one from the outer scope for the duration of the procedure, for example, Sub accesses B from Proggie but supersedes C by declaring its own local object called C. This C (in Sub) is totally unrelated to the C of Proggie.
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, Sub 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 Sub as if it possessed the INTENT(IN) attribute (see Section 13.7 for the implications of the INTENT attribute).
A local variable called A could be declared in Sub which would clearly bear no relation to the A which is argument associated with d. When Sub is exited and control is returned to Proggie, the value that C had before the call to the subroutine is restored.
The C declared in AnuvvaSub bears no relation to the C from Proggie or the C from Sub.
Return to corresponding overview page