(j3.2006) request for interpretation
Robert Corbett
Robert.Corbett
Tue Apr 1 02:41:30 EDT 2008
Van Snyder wrote:
> On Mon, 2008-03-31 at 14:05 -0500, Bill Long wrote:
>
>>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.
>
>
> A statement like IMPORT, EXCEPT: <exclude-list> would solve this
> problem. But... IMPORT is to be allowed only in interface bodies.
For that to work, the EXCEPT clause would need to have strange
semantics. It would have to block, not the visibility of the
specific function (although it might do that as well), but its
availability for generic resolution. That is the reverse of
what can be done with ONLY clause, which can block visibility,
but not availablility for generic resolution.
BTW, my request was for an official interpretation. I already asked
the same question informally, and I received a mix of opinions from
committee members.
Bob Corbett
More information about the J3
mailing list