Re: generic interface question

fj <francois.jacq@xxxxxxx> wrote:

Yes I have now a small test case which reproduces the trouble :

MODULE a
USE iso_c_binding
INTERFACE
SUBROUTINE foo1(a) BIND(C,name="a_c_routine")
IMPORT C_INT
INTEGER(C_INT) ::a
END SUBROUTINE
END INTERFACE
END MODULE
MODULE b
USE a,ONLY : foo1
INTERFACE foo
MODULE procedure foo1,foo2,foo3
END INTERFACE
CONTAINS
SUBROUTINE foo2(a)
DOUBLE PRECISION ::a
END SUBROUTINE
SUBROUTINE foo3(a)
CHARACTER ::a
END SUBROUTINE
END MODULE

[lcoul@b04p0004 test]$ g95 -c test2.f90
In file test2.f90:13

MODULE procedure foo1,foo2,foo3
1
Error: Cannot change attributes of USE-associated symbol 'foo1' at (1)

Ah. Now that I think I can help with.

The error message is a little confusing (though not so much so as the
paraphrasing that talked about changing host association), but I think
the critical bit here is that foo1 is *NOT* a module procedure.

Yes, I know that you accessed it via a USE statement, but that doesn't
make it a module procedure. It is an external procedure whose interface
happens to be defined in a module.

So I don't think this is a compiler bug, other than perhaps insomuch as
the error message could be better.

There is a bit of "silliness" in the f95 module procedure statement.
Mostly the whole business about restricting it to module procedures is
what seems silly to me. I don't think that restriction was well thought
out. It isn't as though the restriction achieves anything useful. I
think the writers just overlooked the fact that it could be useful for
procedures other than module ones. There are several things that are
really awkward because of this restriction. (Notably, it is hard to put
a single external procedure in two different generics; I'm not even sure
there is a workaround to that one.)

The silliness was fixed in f2003. I don't recall whether Andy yet
implemented the f2003 form of this statement in g95. In f2003, you just
omit the keyword "module" and it no longer has the silly restriction.
Otherwise, if you are stuck with the f95 form, you have to use some kind
of workaround. Ones that occur to me are

1. Put the interface body for foo1 in the generic interface block in
module b (and then don't USE foo1 from module a).

2. Or put a generic interface block for foo in module a, with just foo1
as a specific. You can then extend the generic in module b.

Yes, I know these workarounds can be awkward in some cases. The f2003
fix is better.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: why doesnt this compile ?
    ... You either have an interface body or use a module procedure statement. ... If you have a procedure whose interface is already explicit, but which is not a module procedure, then this is awkward. ... "module procedure" in the main program is a compiler *extension*, ...
    (comp.lang.fortran)
  • Re: Interface declarations
    ... That is much stronger than being redundant. ... say in the main program - is an interface declaration. ... MODULE PROCEDURE xyz ... SUBROUTINE xyz ...
    (comp.lang.fortran)
  • Re: Vector Algebra Module
    ... transformations, projections, and least squares solutions ... cartesian coordinates, but for determining the interference pattern ... interface operator ... module procedure rotate_3d_point ...
    (comp.lang.fortran)
  • Re: Interface declarations
    ... MODULE PROCEDURE flux_godunov ... This is one of that kind of interface block. ... I haven't yet mentioned the extra oddity in this particular case. ... I personally regard that as very confusing. ...
    (comp.lang.fortran)
  • Re: generic interface question
    ... END INTERFACE ... Cannot change attributes of USE-associated symbol 'foo1' at ... the critical bit here is that foo1 is *NOT* a module procedure. ... Or put a generic interface block for foo in module a, ...
    (comp.lang.fortran)