J3/15-208 To: J3 From: Malcolm Cohen Subject: Interp of USE and submodules Date: 2015 August 06 1. Introduction Three options are provided for the answer to this interp: Option 1: Basically what the actual text of the standard says now. Accessing a PROTECTED item by a USE statement will hide the host association, and therefore the item will be protected. Option 2: Continue to allow a submodule to USE its ancestor, but say that PROTECTED has no effect in this case. Option 3: Decide that it was a mistake to allow a submodule to access its ancestor module by use association, and forbid it. 2. The interpretation request ---------------------------------------------------------------------- NUMBER: F08/0128 TITLE: Is recursive USE within a submodule permitted? KEYWORDS: SUBMODULE, USE DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider Module m1 Real x End Module Submodule(m1) subm1 Use m1 End Submodule Q1. The module m1 is referenced from within one of its own submodules. Is this standard-conforming? Note that the "submodule TR", Technical Report 19767 contains, an edit with the normative requirement: "A submodule shall not reference its ancestor module by use association, either directly or indirectly." along with a note which says "It is possible for submodules with different ancestor modules to access each other's ancestor modules by use association." It also contains an edit to insert the direct reference prohibition as a constraint. However, none of this text appears in ISO/IEC 1539-1:2010. The Introduction simply comments that submodules are available, but not that they have been extended beyond the Technical Report that created them. Also, consider Module m2 Real, Private :: a Real, Protected :: b ... End Module Submodule(m2) subm2 Contains Subroutine s Use m2 Implicit None a = 3 b = 4 End Subroutine End Submodule In submodule SUBM2, procedure S references M2 by use association. Use association does not make "A" accessible. Q2. Is "A" still accessible by host association? Also, procedure S attempts to assign a value to B, which is accessed by use association, but has the PROTECTED attribute. Normally, this attribute prevents assignment to variables accessed by use association. Q3. Is the assignment to "B" standard-conforming? DISCUSSION: The requirement appears in the early drafts of Fortran 2008, up to 08-007r1, then it was modified by paper 08-154r1 creating a UTI (because the modification was broken), and finally the requirement was completely removed by paper 09-141. ANSWER OPTION 1: A1. Yes, the example is conforming. An edit is supplied to add this extension to the Introduction, and to add normative text to clause 11 to make this completely unambiguous. A2. Yes, A is still accessible by host association. Subclause 16.5.1.4 paragraph 2 states "If an entity that is accessed by use association has the same nongeneric name as a host entity, the host entity is inaccessible by that name." This does not apply since A is not being accessed by use association (because it is PRIVATE), therefore A can still be accessed by host association. {J3 note: no edit necessary here.} A3. No, the assignment to B is not conforming as it violates constraint C551 which states "A nonpointer object that has the PROTECTED attribute and is accessed by use association shall not appear in a variable definition context..." An edit is provided to add an explanation of this. ANSWER OPTION 2: A1. Yes, the example is conforming. An edit is supplied to add this extension to the Introduction, and to add normative text to clause 11 to make this completely unambiguous. A2. Yes, A is still accessible by host association. Subclause 16.5.1.4 paragraph 2 states "If an entity that is accessed by use association has the same nongeneric name as a host entity, the host entity is inaccessible by that name." This does not apply since A is not being accessed by use association (because it is PRIVATE), therefore A can still be accessed by host association. {J3 note: no edit necessary here.} A3. The assignment to B was intended to be conforming. An edit is provided to correct constraint C551 to permit this. ANSWER OPTION 3: A1. No, the example was not intended to be conforming. Permission for a submodule to access its ancestor module by use associated was a mistake. An edit is provided to correct this error. A2. Moot. A3. Moot. EDITS OPTION 1: [xv] Introduction, p2, first bullet, After "Submodules provide ... for modules." Insert new sentence "A submodule can reference its ancestor module by use association." [100:12] 5.3.15 PROTECTED attribute, insert this text immediately after the word "descendants" (i.e. before the comma) "where it is accessed by host association". [272:23] 11.2.2 The USE statement and use association, p1, After "A module shall not reference itself, either directly or indirectly." Append to paragraph "A submodule is permitted to reference its ancestor module by use association. " [273:2+4] Same subclause, NOTE 11.7, append "If a submodule accesses a PROTECTED entity from its ancestor module by use association, use of that entity is constrained by the PROTECTED attribute, e.g. if it is not a pointer it cannot appear in a variable definition context.". EDITS OPTION 2: [xv] Introduction, p2, first bullet, After "Submodules provide ... for modules." Insert new sentence "A submodule can reference its ancestor module by use association." [100:6] 5.3.15 PROTECTED attribute, C551, After "and is accessed by use association" insert "from a scoping unit that is not within a submodule of the module containing the definition of the PROTECTED entity" {Remove PROTECTED effect from ancestor module variables.} [100:9] same subclause, C552, same edit. {Remove PROTECTED effect from ancestor module pointers.} [272:23] 11.2.2 The USE statement and use association, p1, After "A module shall not reference itself, either directly or indirectly." Append to paragraph "A submodule is permitted to reference its ancestor module by use association. " EDITS OPTION 3: [275:9+] 11.2.3 Submodules, "A submodule shall not reference its ancestor module by use association, either directly or indirectly." {NOTE TO J3: This could be inserted at [272:23] if that is thought to be a better place.} SUBMITTED BY: Malcolm Cohen HISTORY: 15-134 m206 F08/0128 submitted 15-134r1 m206 Revised edits - passed by J3 meeting 15-187 m207 Failed J3 letter ballot 15-159 15-nnn m207 Revised with 3 options ----------------------------------------------------------------------