In article <jqae6n$1mf$1@speranza.aioe.org>, glen herrmannsfeldt
<gah@ugcs.caltech.edu> writes:

> It is nice to group related variables together. Sometimes there
> are clear groupings and it makes sense to follow them.
>
> I don't understand, though, the "technical stuff, bookkeeping."

Suppose the module is concerned with calculating some quantity and this
is done partly through numerical integration. There might be some
low-level variables in a couple of routines which might save previously
calculated results, flag errors, collect statistics for debugging etc
which are conceptually independent of the real purpose of the module and
certainly not of interest to the calling program.

> Put all the variables in a module and USE it in the appropriate
> places.

Right; this is what I concluded is the best solution.

> > What I like about the COMMON approach here is that the tools
> > (variables and COMMON blocks) are defined only in the routines which use
> > them, and are a small part of these routines. Replacing COMMON blocks
> > one-to-one with MODULEs for shared variables means creating a module at
> > the same logical level as the main module which contains all the
> > routines, including those which need to share a few variables with only
> > one other routine. In other words, what is essentially a small part of
> > a routine is defined two logical levels too high.
>
> I don't understand this. Yes, at some point module variables are
> all at the same level. They are all static, there is no nesting
> level, for example.

Technically, yes, but aesthetically, no. :-)

The structure with COMMON is

module main
global variables
routine alpha
local variables a, b, c
routine beta
local variables a, b, c
common /both/ x, y
routine gamma
local variables a, b, c
routine delta
local variables a, b, c
routine epsilon
local variables a, b, c
common /both/ x, y
routine zeta
local variables a, b, c

so x and y are defined in beta and epsilon, where they are used.

The alternatives are

module main
global variables
x, y
routine alpha
local variables a, b, c
routine beta
local variables a, b, c
routine gamma
local variables a, b, c
routine delta
local variables a, b, c
routine epsilon
local variables a, b, c
routine zeta
local variables a, b, c

In this case, x and y are clutter since they are visible to all
routines, though only a couple use them. In contrast to some of the
other module variables, the calling program doesn't care about them.
They are also defined a level higher than where they are used.

or

module main
global variables
routine alpha
local variables a, b, c
routine beta
use both
local variables a, b, c
routine gamma
local variables a, b, c
routine delta
local variables a, b, c
routine epsilon
use both
local variables a, b, c
routine zeta
local variables a, b, c
module both
x, y

This keeps x and y visible only where they are used (and, in contrast to
common, defines them at only one place), but it means an extra module,
which is on the same logical level as the main module, though it is
concerned with variables used within a procedure contained within the
main module. For another pair, I would have

module main
global variables
routine alpha
local variables a, b, c
routine beta
use betaepsilon
local variables a, b, c
routine gamma
use gammadelta
local variables a, b, c
routine delta
use gammadelta
local variables a, b, c
routine epsilon
use beta epsilon
local variables a, b, c
routine zeta
local variables a, b, c
module both betaepsilon
x, y
module both gammadelta
x, y

which means an additional module for each subset. I think this is
better:

module main
global variables
routine alpha
local variables a, b, c
routine beta
use both, only: x, y
local variables a, b, c
routine gamma
use both, only: v, w
local variables a, b, c
routine delta
use both, only: v, w
local variables a, b, c
routine epsilon
use both, only: x, y
local variables a, b, c
routine zeta
local variables a, b, c
module both
x, y, v, w

> > What I would really like to see is the possibility for a routine in a
> > module to "use" what is essentially a local variable in another routine
> > in the same module:
>
> > module big
> > contains
> > subroutine alpha
> > real :: x, y, z
> > subroutine beta
> > real :: a, b, c
> > use alpha, only: x !maybe another word than "use"
> > subroutine gamma
> > subroutine delta
> > subroutine epsilon
> > end module big
>
> > To make it safe, something similar to TARGET might be useful, e.g.:
>
> > subroutine alpha
> > real :: x, y, z
> > allow beta, only: x
>
> > Does anyone else see a need for this feature? Would it be difficult to
> > implement technically? Is there a chance to get it into the next
> > standard?
>
> Well, since Fortran 95 local variables can be automatic, and
> they have to be in the case of RECURSIVE.

ALLOW would tell the compiler that these could be accessed by another
routine.

> They don't exist before
> a routine is called, or after it returns.

Unless they are SAVEd, presumably.

> Note, though, that
> they are available to internal procedures. Does that help?

Not in this case.

> As well as I know it, there is a very close relationship between
> MODULE variables and COMMON variables. You USE them differently,
> and the ways to misuse them are different, but otherwise they
> are very similar.

Indeed. What I like about COMMON in this case (otherwise, I want to
avoid it and use module variables and will probably do so even here) is
that the variables shared between a pair of routines are mentioned there
and nowhere else. With module variables, I have to define them outside
of these routines.

A country is divided into states, counties, towns etc. Imagine two
towns (in different states) have some sort of cooperation. It would be
logical for each one to have an office dealing with this. This is the
COMMON approach. With the module approach, there is either an office in
the national capital which deals with all such cooperations, or there is
an office in a third town which communicates with both towns in the
partnership.