Prev: Allocattable and namelist object
Next: How to control/prevent cast between from complex to real variables
From: Richard Maine on 15 Feb 2010 11:56
Woody <ols6000(a)sbcglobal.net> wrote:

> I'm having difficulty setting up declarations for functions whose
> names are being passed as arguments to a subroutine. What I am trying
> to accomplish in outline is
....
> I have placed MyFunc1 and MyFunc2 in a module. That code looks like
....
> In a different module, I have interface blocks for MyFunc1 and
> MyFunc2. I am not sure whether these are needed, though.

Mike and Arjen showed what you need to do. Let me briefly describe what
the code you wrote does. There is a chance that might help in
understanding why you need to do it the way that Mike and Arjen showed.

Interface bodies can declare external or dummy procedures. (In f2003,
they can also declare procedure pointers or abstract interfaces, but
that's just a distraction for the moment.) Note that they can never
declare the interfaces of module procedures because a module procedure's
interface is already known anywhere that the module is used.

Your interface blocks in the second module declare the interfaces of two
external (not module) procedures. They aren't declaring the interfaces
of any module procedures because you can't ever do that with an
interface body. In fact, there is almost nothing that you can declare
about any kind of module entity outside of its own module; there are
only a few exceptions and those aren't relevant here. They aren't
declaring the interfaces of dummy procedures because nothing in your
second module makes them dummy procedures - and a module doesn't have
dummy procedures anyway (a module procedure can have dummy procedures,
but a module itself can't). It is important to understand that modules
don't look at where they are used to figure out what they are declaring.
In general, a module doesn't "know" where it might be used; the usage
might happen in code that hasn't even been written yet. There being no
dummy procedures "in sight" when your second module is compiled, the
declarations aren't going to be for dummy procedures.

If you later USE the second module, you will access its declaration that
there are external procedures with these names and interfaces. If you
use it somewhere that there are dummy procedures of the same name, it
won't change the module declarations to apply to those dummy procedures;
you can't change module declarations after the fact like that. Instead,
you would get a compilation error because you were using the same name
for two diferent things in the same scope; one would be the dummy
procedure and the other would be the external procedure whose interface
the module declared.

When you correct your code to put the interface bodies in the procedure
tht has dummy arguments, as Mike and Arjen describe, then the interface
bodies declare those dummy procedures as desired, and all is well.

Do let me aditionally clarify that the interface bodies, when correctly
placed, declare only the dummy procedures. They do not declare the
interfaces of the module procedures (recall that I said you can never do
that). Your code slightly obscures the point because your dummy
procedures have the same names as the module procedures. That's ok (as
long as you don't USE the names from the module in the same scope), but
it can be confusing and encourage a misconception. The dummy procedures
and the module procedures are separate things. They get argument
associated by the CALL statement, so that a call using the dummy
procedure name ends up referencing the module procedure, but they are
still separate things. There could be some other call in which the dummy
arguments are associated with different actual arguments.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
 | 
Pages: 1
Prev: Allocattable and namelist object
Next: How to control/prevent cast between from complex to real variables