> >> 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.
> 
> Phillip Helbig:
> > I don't think so.  I have struggled with this quite a bit, and 
> > never got a satisfactory solution from this or any other source.
> 
> Phillip Helbig:
> > One CAN write the interface by hand, which might be better than
> > nothing (i.e. better than the EXTERNAL routine approach) but then
> > one has to make sure that B, when it is written, corresponds to the
> > interface.
> 
> This is, indeed, what I doing now (see below). Unfortunately there
> seems to be no (standard) way to provide the module information for
> (B), which would be necessary to compile (A) seperatly. Only the
> interface of the requested procedure (P) can be put into a module.
> P itself has then to be a naked procedure. I can live with this
> solution. However, it is incompatible with the F language which 
> is offen referred to as "good style" Fortran.

And has the problem that you have to rely on the naked procedure really
corresponding to the interface.  You might as well rely on the naked
procedure really corresponding to what you expect in the calling
routine, i.e. bad old F77 style.  (To be sure, your method will detect 
improper calls due to mistakes IN THE CALLING ROUTINE.)

Maybe I can offer some more insight on this today or tomorrow, since I
hope to be able to get back to my "real work" by then.  Having the
procedure in a module which gives an automatic interface is great, but
won't work here.  I might have mentioned INCLUDE.  I never used it when
it was non-standard, and most uses for it after it became standard now
have better solutions.  However, it might have NEW uses, as in Van
Snyder's "poor man's templates".  Another use might be here.  One could
write the INTERFACE and INCLUDE the same code both in the procedure
which needs the information (but can't get it automatically, since the
user routine isn't written when the former is compiled) AND in the
user-written procedure.  After all, you know what the interface is when 
you write the calling routine, so you might as well code it.

Consider these separate files:

!STUFF.F90
!this is not compiled directly but included
SUBROUTINE USER_WRITTEN(BAR,BLA)
REAL, INTENT(IN)  :: BAR
REAL, INTENT(OUT) :: BLA

!CALL_IT.F90
!this is compiled before user-written stuff is compiled
PROGRAM CALL_IT
IMPLICIT NONE
INTERFACE
INCLUDE 'STUFF.F90'
END SUBROUTINE USER_WRITTEN
END INTERFACE
INTEGER :: L
REAL :: BAR=2, BLA
CALL USER_WRITTEN(BAR,BLA)
!decomment the next line to get a compilation error
!CALL USER_WRITTEN(BAR,L)
PRINT*, BAR, BLA, EXP(BAR)
END PROGRAM CALL_IT

!TEST.F90
!this is the user-written routine
INCLUDE 'STUFF.F90'
BLA = EXP(BAR)
END SUBROUTINE USER_WRITTEN

You have control of CALL_IT.F90 and STUFF.F90.  All you have to make 
sure of is that the user-written routine begins with 

   INCLUDE 'STUFF.F90'

which should be easy enough to verify.  You have to re-link after the 
user-written routine is compiled anyway (unless you are doing some sort 
of dynamic linking), so it is not improbable that the source code is 
present on your system.

The above UGLY HACK will provide checking.  In other words, if during
re-writing the calling routine you make a typo or whatever, then when
you compile this again, an argument mismatch will show up if you
declared something to be the wrong data type etc.  Also, and this is
probably your goal, it is guaranteed that user-written routines will
have the arguments you expect, since THE SAME SOURCE CODE is used to
declare these in the user-written routine and in the calling routine. 

There is still the disadvantage that the user-written routine is a naked 
procedure.  This means that it could be called---possibly with improper 
arguments---by any routine which is linked to it.  However, you could 
take the point of view that whoever does this is responsible for his own 
actions; YOU can use the INTERFACE, as outlined above.  I'm assuming 
that your real worry is that the user-written routine is guaranteed to 
be what the calling routine expects, and the above hack solves this 
problem.

One ADVANTAGE of this scheme is that it does not involve a compilation
cascade.  In other words, since the "public" stuff is cast in stone in
STUFF.F90, there is no reason to recompile CALL_IT.F90 after the
user-written TEST.F90 is recompiled, possibly after completely changing 
the body, say replacing 

   BLA = EXP(BAR)

with

BLA = 2*SIN(BAR) + 2.52352 + BAR**2/3

(As many have pointed out, in principle this compilation cascade is not
necessary with modules, but the way the standard is currently written
the compilation cascade has to take place, though things "might work"
otherwise.) 

A very common case is where one has a user-defined function and does 
something with it like integrating it.  You want to make sure that the 
user-written function has the argument types the calling routine expects 
etc.  The solution above will work in this case.  Of course, one can 
pass the name of the user-written routine to the library routine so as 
to avoid having to change the code of the library routine each time it 
is used---after all, one of the goals is to avoid recompiling this.


--
Phillip Helbig                       Email .............. [log in to unmask]
Kapteyn Instituut                    Email ................. [log in to unmask]
Rijksuniversiteit Groningen          Tel. ................... +31 50 363 4067
Postbus 800                          Fax .................... +31 50 363 6100
NL-9700 AV Groningen                 Web ... http://www.astro.rug.nl/~helbig/

My opinions are not necessarily those of my employer.

<A HREF=" http://gladia.astro.rug.nl:8000/helbig/hire/hire.html ">HIRE ME!</A>



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