(j3.2006) request for interpretation

Bill Long longb
Mon Mar 31 15:05:54 EDT 2008



Robert Corbett wrote:
> Consider the following program
>
>        MODULE M1
>          INTERFACE SUBR
>            MODULE PROCEDURE SUBR1
>          END INTERFACE
>        CONTAINS
>          SUBROUTINE SUBR1
>          END SUBROUTINE
>        END
>
>        MODULE M2
>          INTERFACE SUBR
>            MODULE PROCEDURE SUBR2
>          END INTERFACE
>        CONTAINS
>          SUBROUTINE SUBR2
>          END SUBROUTINE
>        END
>
>        PROGRAM MAIN
>          USE M1
>          CALL S
>        CONTAINS
>          SUBROUTINE S
>            USE M2
>            CALL SUBR
>          END SUBROUTINE
>        END
>
> Is this program standard conforming?
>   

I tried three compilers and they all said it is not. All gave compile 
time errors that the generic interface for SUBR in subroutine S had 
indistinguishable specifics.

> The program appears to violate the restrictions set out
> in Section 16.2.3 of the Fortran 2003 standard.  

Right.


> It has
> been argued that Section 12.4.4.1 of the Fortran 2003
> standard modifies the requirements of Section 16.2.3.
>   
12.4.4.1 says things like  "The rules in 16.2.3 ensure that there can be 
at most one such specific procedure."

> While that might have been what was intended, I do not
> see how the text of Section 12.4.4.1 has any effect on
> the requirements of Section 16.2.3.
>   

Agreed.

I think the more relevant citation is 12.4.4 (1) (d) that says "A 
procedure name is established to be generic in a scoping unit if that 
scoping unit contains no declarations of that name, that scoping unit 
has a host scoping unit, and that name is established to be generic in 
the host scoping unit."   The point just above in (1)(c) explains how 
generic names become visible through a USE statement. 

The general concept that multiple, visible generic interfaces with the 
same name effectively merge together their lists of specifics is pretty 
fundamental in Fortran.  Trying to come up with some exceptions to that 
concept just to make the program above standard conforming seems like 
the wrong path.

Cheers,
Bill


> Robert Corbett
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>   

-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

            




More information about the J3 mailing list