J3/01-294 Subject: Proposed answer for Interp F90/211 From: Malcolm Cohen To: J3 Date: 6th August 2001 ---------------------------------------------------------------------- NUMBER: F90/000211 TITLE: Multiple MODULE PROCEDURE specs KEYWORDS: MODULE PROCEDURE, generic interface, USE association DEFECT TYPE: STATUS: J3 consideration in progress WG5/N1176 (X3J3/96-007) says [194:21-23]: "Constraint: A in a shall not be one which previously had been specified in any with the same generic identifier in the same specification part." QUESTION: 1. Is it correct that this constraint does not preclude the following? MODULE foo1 INTERFACE generic_spec MODULE PROCEDURE proc1 END INTERFACE CONTAINS SUBROUTINE proc1 END SUBROUTINE proc1 END MODULE foo1 MODULE foo2 USE foo1 INTERFACE generic_spec MODULE PROCEDURE proc1 END INTERFACE END MODULE foo2 Although foo2 clearly violates the uniqueness conditions in 14.1.2.3, it seems that it does not violate a Constraint. (Actual compilers do not seem to detect this form of violation of 14.1.2.3 at compile-time.) 2. If the answer to (1) is YES, wouldn't it be sensible to extend that constraint to cases where a "previous" specification of in a with the same generic identifier in the specification part of an accessible module had occurred, _and_ that and generic-spec have PUBLIC accessibility? Probably the wording might be quite complicated because of the possibility of s if FOO1 and s in FOO2, but the essence should be straightforward... The situation in (1) is very similar to the following example, which _is_ detected as erroneous by the compilers I tried: MODULE foo1 CONTAINS SUBROUTINE proc1 END SUBROUTINE proc1 END MODULE foo1 MODULE foo2 USE foo1, ONLY: proc1 USE foo1, ONLY: proc2 => proc1 INTERFACE generic_spec MODULE PROCEDURE proc1 MODULE PROCEDURE proc2 END INTERFACE END MODULE foo2 In both cases, the specific s (and the ) are accessible in MODULE foo2, and the interfaces are explicit anyway. ANSWER {ALTERNATIVE 1}: (1) Yes, this constraint does not apply to the example. Nor does 14.1.2.3, which only applies between pairs of specific procedures - there is only one specific procedure in this example. Note: However, processors are required to diagnose violations of the requirements of 14.1.2.3 - see 1.5 item 6. (2) Yes, the constraint should be fixed to prohibit the examples. Note: As it stands, the second example is not prohibited either by the constraint or by 14.1.2.3. EDIT: [194:21-23] Replace with "Constraint: A in a shall not specify a procedure that is specified previously in any in any accessible interface block with the same generic identifier." ANSWER {ALTERNATIVE 2}: (1) Yes, this constraint does not apply to the example. Nor does 14.1.2.3, which only applies between pairs of specific procedures - there is only one specific procedure in this example. Note: However, processors are required to diagnose violations of the requirements of 14.1.2.3 - see 1.5 item 6. (2) No, the constraint should not be fixed. The second example is standard-conforming. EDIT: None. SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: submitted Apr. 12, 1996 (first appeared in 96-006r2) WG5/N1452 Suggested answer (two alternatives). 158-mjc-010 m158 ----------------------------------------------------------------------