This is a problem that I have been struggling with also. In my case the general 
purpose module A requires certain problem specific information from the user. 
This information is but one by-product of a complex system model and associated 
operations. The information required by module A is naturally represented by 
Fortran's intrinsic data structures (scalars and vectors); however the data 
from which this information is obtained has a much more complex structure.

So one solution I have implemented (for evaluation) is a reverse communication 
interface in module A. That is module A requests information from the user 
module (B) when required. The implementation and maintenance of a reverse-
communication interface in Fortran 95 is facilitated by derived types. 
(Information on the state of module A can be encapsulated in a single derived 
type variable and the components can be made private)

The prime advantages that I see for such an interface are:
(1) The user has complete freedom in the way they implement higher-level data-
structures and procedures. (In my case sparse matrices and the solution of 
sparse-linear equations).
(2) Since module A is but one tool in my problem domain it is not given special 
precedence; module B USEs module A and not the other way around -- (i.e. the 
tail does not wag the dog).
(3) The interface of Module A can be published and a compiled version of Module 
A is all that needs to be distributed to end users.

The disadvantages that I see are:
(1) The user module B must call the driver routine of module A repeatedly and
include logic and procedures to provide the information requested by module A. 
(In my own case the procedures to service module A are generally required and 
would have to be provided anyway). One way to ameliorate the calling sequence 
complexity is to publish examples that can be easily adapted by the user.
(2) A more complex module A, including the maintenance of a stack of state 
information to allow module A to return to the state it was in prior to 
reversal (but updated with the requested information). Note that the SAVEd 
attribute is not used to preserve state information between calls. This allows 
for the possibility of multiple simultaneous use of module A.
(3) A higher level of programmer discipline is required for module A.

I would appreciate comments from list members on any additional pro's and con's 
of reverse-communication interfaces in the context of Fortran95.

Regards,
David Vowles.

Date sent:      	Tue, 13 Jun 2000 17:03:25 +0200
Organization:   	TU Dresden
Subject:        	module
From:           	Jörg Stiller <[log in to unmask]>
To:             	[log in to unmask], [log in to unmask]
Send reply to:  	Jörg Stiller <[log in to unmask]>

> Hello,
> 
> I am working on a library module (A), which makes uses of an 
> user supplied procedure (P) which, preferably, is placed in 
> another module (B). In particular, it should be possible to 
> compile A without knowing the body of B. However, a rudimental
> version of B containing a dummy for P could be supplied. 
> 
> Is there a legal way to do this in Fortran 95?
> If not, what is the "textbook solution" for this problem?
> 
> Regards
> Joerg
> 
> -- 
> Dr.-Ing. Joerg Stiller, Dozent fuer Geo- und Magnetofluiddynamik
> ----------------------------------------------------------------
> Technische Universitaet Dresden          TEL : (0351) 463 - 8328
> Institut f. Luft- und Raumfahrtechnik    FAX : (0351) 463 - 8087
> D-1062 Dresden                           [log in to unmask]


Regards,
David.

----------------------------------------------------------

David Vowles
Research Officer
Department of Electrical and Electronic Engineering
The University of Adelaide
Australia 5005

Voice:     +61 8 8303 5416
Fax:       +61 8 8303 4360
Email:     [log in to unmask]
Home Page: http://www.eleceng.adelaide.edu.au/Personal/dvowles/home.html


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