I wrote a perhaps too-long treatise on the problem of getting extra
information into user-supplied code needed by library routines.

Alexander Donev remarked:

> I do not like the above flow of control a lot. Also, the routines I use will
> usually be handled as ELEMENTAL and/or PURE in HPF, so that such alternate
> entry points and GO TO's and such make life difficult to debug and maintain,
> especially in parallel codes.

> Now, I am really interested in seing what people think the best approach is in
> Fortran 95. There must be a way to use modules to somehow encapsulate user
> defined routines. But of course the provided user module can not be USEd in my
> library modules, since these should be compiled beforehand.

> My idea of doing this would be the following: having a dummy rouine that only
> accepts one argument (like x in case of quadrature) which in turn calls all
> the things the user wants....

> ! Now this module will be written by the user later on, containing all the
> ! things needed
> ! for calculating the cost function, such as spectroscopic tables and
> ! interpolations etc.
 ...
> ! Finally, the user would compile the main program, having access to both
> previous .mod files
 ...
> Is there some problem or improvement to this scheme that I am not seeing.

Not having coroutines, and realizing that some users prefer forward
communication, I have used four schemes in the past to get extra information
through a library routine into user-supplied code:

1.  In Fortran 77, it was not unusual for library routines to expect their
    calling procedures to supply work space.  I organized the library
    routines so that the beginning of the work space was used for arguments
    the library routine was passing to user-supplied code, e.g. independent
    variables and bounds in a multidimensional quadrature code.  The library
    routine therefore passed the provided work space to the user-supplied
    code.  In simplest usage, it was just an array of independent variables,
    but the documentation explained that it really was the supplied work
    space, and therefore extra data could be passed at the end of it
    (and formulae were given to calculate where the end was).

2.  COMMON could be used to send data around the library routine from the
    caller of the library routine to the user-supplied code accessed as
    a procedure.

3.  In Fortran 90, module variables would be a nicer solution than COMMON.

4.  In extremis, I have changed library routines, to add extra arguments
    to them, and the user-supplied routines.

I think the solution Donev proposes is #3:  The user-supplied code is a
module procedure, that is passed as an actual argument associated to a
dummy procedure of the library routine.  The extra information needed by
the user code is stored in module variables in the same module as the
user-supplied module procedure.

The relation between data flow and control flow is somewhat obscured by
this approach: One stores some data in advance, then calls the library
routine, which calls the user-supplied code, which looks at the previously
stored data.  Nonetheless, it is a workable solution.

Best regards,
Van Snyder




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%