Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!pacbell.com!ames!skipper!elxsi!maine
From: maine@elxsi.dfrf.nasa.gov (Richard Maine)
Newsgroups: comp.lang.fortran
Subject: Re: global data
Message-ID: <MAINE.91Jan4095143@altair.dfrf.nasa.gov>
Date: 4 Jan 91 17:51:43 GMT
References: <1991Jan4.022750.24875@ariel.unm.edu>
	<1991Jan4.165223.7212@maverick.ksu.ksu.edu>
Sender: news@skipper.dfrf.nasa.gov
Distribution: usa
Organization: NASA Dryden, Edwards, Cal.
Lines: 89
In-reply-to: mac@harris.cis.ksu.edu's message of 4 Jan 91 16:52:23 GMT

On 4 Jan 91 16:52:23 GMT, mac@harris.cis.ksu.edu (Myron A. Calhoun) said:

Myron> In article <1991Jan4.022750.24875@ariel.unm.edu> you write:

>Does anyone know how to make these PARAMETERs global so that
>subprograms have instant access to them, thereby obviating
>the need for all those arguments?  Common doesn't seem to
>work on PARAMETERs.

Myron> I, too, would like to see a "global" PARAMETER statements, but since
Myron> FORTRAN permits separate compilations, such globals probably are just
Myron> not possible.

Fortran 90 modules can contain "global" parameters, among other things.
Sample code follows (quickly thrown together, so pardon if there is
something not quite right).

     module some_parameters
       integer, parameter :: max_things=100
       integer, parameter :: max_other_things=50
     end module some_parameters

     subroutine do_it
       use some_parameters
       real :: a(max_things), b(max_other_things)
       ...
     end subroutine do_it

There are, as you might guess, some implications to "separate compilation".
The some_parameters module must be "available" when the do_it routine is
compiled.

Used like this, the module looks little different from an "include"
other than syntactic details, plus of course the advantage that modules
are standard in F90 (though so are includes).  This is a very limitted
example; there are lots of other "neat" things that can be done with
modules, some of them having no direct F77 comparisons.

Another way to use modules for this kind of application is to put
all the subroutines that share information into a module as follows
(in the extreme case, this module can legally contain  every subroutine
in the program, but of course, that's poor form except in small programs).

     module something
       integer, parameter :: max_things=100
       integer, parameter :: max_other_things=50
     contains
       ...
       subroutine do_it
         real :: a(max_things), b(max_other_things)
         ...
       end subroutine do_it
     end module something

All the subroutines in this module share the parameters (or other data)
declared above the "contains".

And you can combine these two ways of using modules so that you
don't have to put everything into one module, yet you also don't
need a "use" in every subroutine.  Sample (referencing the above
some_parameters module).

     module something
       use some_parameters
     contains
       ...
       subroutine do_it
         real :: a(max_things), b(max_other_things)
         ...
       end subroutine do_it
     end module something

Of course, F90 lessens (but does not eliminate) the need for parameters
declaring matrix dimensions because

   1. You would dynamically allocate some matrices as needed, instead
      of dimensioning them to fixed maximum sizes.

   2. Matrices in argument lists automatically carry size information
      along with them; you don't have to do it separately.  (Much like
      character string lengths are automatically passed in F77).

Til F90 "arrives" for real, variants of the non-standard include statement
and/or source code preprocessors (possibly to implement the inclusion) seem
the only realistic options for global parameters.
--

Richard Maine
maine@elxsi.dfrf.nasa.gov [130.134.64.6]