Scope, association, and information hiding in Fortran 90 - scope

Question

1
This question is concerned with calling and called subroutines in Fortran 90. I am quite confused about the rules for host/use/arguments association; I have trouble understanding the scoping logic that results from these rules. Perhaps the simplest way to expose my problem is to explain what I would like to achieve and why.
I would like to meet two design requirements:
(i) A calling subroutine only allows the called subroutine to access its entities that are passed as arguments, no other.
(ii) A called subroutine does not allow a calling subroutine to access any of the entities it locally defines.
If a picture helps, I can provide one. I wish I could think of the calling and the called subroutines as two rooms connected by a channel they use to pass or return arguments. I would like this argument association to be the only means by which two subroutines could have any influence on each other. I believe a code that meets these requirements will be more robust to side effects. If I am mistaken in this idea, I would be grateful to be explained why. If there is a strong reason for which these requirements should not be desired, I also would be happy to know.
2
Certainly, fortran 90 offers the possibility to use modules and the ‘only’ option. For example, one can do the following:
module my_mod_a
contains
subroutine my_sub_a
use my_mod_b, only: my_sub_b
…
call my_sub_b(arg_list_b)
…
end subroutine my_sub_a
end module my_mod_a
!………
module my_mod_b
contains
subroutine my_sub_b(arg_list_b’)
do stuff with arg_list_b’
end my_sub_b
…
end module my_mod_b
!………
Sure enough, my_sub_a will at most be allowed to access those entities of my_mod_b for which my_sub_b is a scoping unit. But will it be able to access entities of my_sub_b other than the argument list it is passing? In particular, will my_sub_a be able to access entities that are local to my_sub_b? Conversely, does the use association allow my_sub_b to access entities of my_sub_a different than those passed as actual arguments?
3
Is the following ‘buffer module’ construction sufficient in order to meet the requirements of #1?
module my_mod_a
contains
subroutine my_sub_a
use my_mod_b_shell, only: my_sub_b_shell
…
call my_sub_b_shell(arg_list_b)
…
end subroutine my_sub_a
end module my_mod_a
!………
module my_mod_b_shell
contains
subroutine my_sub_b_shell(arg_list_b’)
!passes arguments, does not do anything else
use my_mod_b, only: my_sub_b
call my_sub_b(arg_list_b’)
end my_sub_b_shell
end module my_mod_b_shell
!………
module my_mod_b
contains
subroutine my_sub_b(arg_list_b’)
do stuff with arg_list_b’
end my_sub_b
…
end module my_mod_b
!………
4
Is there any simpler construction to achieve the goals of #1?
5
Following the suggestions proposed by Ross and Vladimir F,
one possibility could be:
(i’) to have a one-to-one correspondence between modules and subroutines,
(ii’) to declare local variables in the module instead of the subroutine; one is then able to tag local variables as ‘private’.
Just to be sure I have got the point right, here is a trivial program that illustrates (i’) and (ii’):
program main
use sub_a_module
implicit none
double precision :: x
x=0.0d+0
write(*,*) 'x ante:',x
call sub_a(x)
write(*,*) 'x post:',x
end program main
!-------------------------------------------------
module sub_a_module
double precision, private :: u0
double precision, private :: v0
contains
!.-.-.-.-.-.-.-.-
subroutine sub_a(x)
use sub_b_module
implicit none
double precision :: x
u0=1.0d+0
v0=2.0d+0
call sub_b(v0)
x=x+u0+v0
end subroutine sub_a
!.-.-.-.-.-.-.-.-
end module sub_a_module
!-------------------------------------------------
module sub_b_module
double precision, private :: w0
contains
!.-.-.-.-.-.-.-.-
subroutine sub_b(v)
implicit none
double precision :: v
w0=1.0d-1
v=v+w0
end subroutine sub_b
!.-.-.-.-.-.-.-.-
end module sub_b_module
In this example, the only entity of sub_a that sub_b can access is v0 (argument association); u0 will remain hidden to sub_b. Conversely, the 'private' tag guarantees that the variable w0 remains out of the scope of sub_a even if sub_a USEs the sub_b_module. Is that right?
#Ross: Thank you for pointing out a previous post where association is inherited. However, my impression is that it only addresses half of my problem; the construction discussed in that post illustrates how one can prevent a caller program unit to access entities of a called program unit that should remain hidden ('use only' and/or 'private' options), but I am unable to assert with certainty that entities of the caller program unit that are not argument-associated will remain unaccessible to the called program unit.

Answer 1

You can always create a small module that contains only the subroutine and nothing else and use it from a larger module that collect these and which is than actually used for calling the subroutine.
Fortran 2015 brings more control for host asociation using IMPORT. I am not sure whether that affects also module procedures, but it might. But you ask for the ancient Fortran 90 so probably you are not interested in this (compilers don't implement it yet anyway), but I will leave it here for the future:
If one import statement in a scoping unit is an import,only statement,
they must all be, and only the entities listed become accessible by
host association.
If an import,none statement appears in a scoping unit, no entities are
accessible by host association and it must be the only import
statement in the scoping unit. ...
(From: Reid (2017) The new features of Fortran 2015)
Yes, your example is more or less correct, although there are many possible variations. You can always add the only clause to document why do you use the module and which symbols are imported.
Important: I suggest you do not put implicit none inside contained procedures but once in the module. You definitely do want to have the module variables covered by implicit none! And use some indentation, so that the structure is actually visible when looking at a block of code.
If you use only one source file you definitely have to put there the modules and the program in a different order:
module sub_b_module
implicit none
double precision, private :: w0
contains
subroutine sub_b(v)
double precision :: v
w0=1.0d-1
v=v+w0
end subroutine sub_b
end module sub_b_module
module sub_a_module
implicit none
double precision, private :: u0
double precision, private :: v0
contains
subroutine sub_a(x)
use sub_b_module, only: sub_b
double precision :: x
u0=1.0d+0
v0=2.0d+0
call sub_b(v0)
x=x+u0+v0
end subroutine sub_a
end module sub_a_module
program main
use sub_a_module, only: sub_a
implicit none
double precision :: x
x=0.0d+0
write(*,*) 'x ante:',x
call sub_a(x)
write(*,*) 'x post:',x
end program main
If you are super concern about data access, you can make modules mod_sub_a, mod_sub_b, mod_sub_c each with one public subroutine only. Then module subroutines which uses those and let all other code use only module subroutines to access those.
To be clear - from the IanH's answer I can see there may have been some misunderstanding here - I certainly do NOT recommend one to one correspondence of modules and subroutines. I regard it as a rather extreme thing to do to ensure your main point:
A calling subroutine only allows the called subroutine to access its
entities that are passed as arguments, no other.
So I showed you how to make sure that your subroutine does not have access anything outside - by placing it into a module which does not have anything more to have access to. I also showed you the future way with import that can be used to disable access to other entities defined in the host module.
I just ignored your second point
A called subroutine does not allow a calling subroutine to access any
of the entities it locally defines.
because that is fulfilled automatically,unless the calling subroutine is internal and contained within the calling subroutine.

Answer 2

Local variables of a subroutine are only accessible from within the scope of that subroutine (and its internal procedures) - that's why they are called "local variables". You can achieve your design goals in part 1 of your question without any particular effort.
Variables that are not local variables (for example, module variables, variables in a common block) may be accessible or share information across different scopes - that's typically the reason those other sorts of variable exist in the language. If you don't want that sort of information sharing, then don't use those other sorts of variable!
The suggestions in part 5 of the edited question are going the wrong way...