ISO/IEC JTC1/SC22/WG5 N2093 Result of the interpretations straw ballot 11 and J3 letter ballot 35 on Fortran 2008 interpretations N2091 Key for the Result line: Y vote passes unconditionally. C vote passes, subject to minor changes noted below N vote fails. Returned to J3 for further work. F08/ F08/ F08/ F03/ F08/ F08/ F03/ F08/ 0128 0138 0139 0140 0141 0142 0143 0144 Bader N Y C Y Y Y Y Y Chen Y C C Y Y Y C C Clune Y Y Y Y Y Y Y Y Corbett N Y C Y Y Y Y N Kruyt C Y Y Y Y Y C C Long Y C C C C Y C C Maclaren Y Y Y Y Y Y Muxworthy Y C Y Y C Y C C Nagle Y Y Y Y Y Y Y Y Reid Y Y Y Y C Y C Y Shterenlikht Y Y Y Y Y Y Y Y Snyder N Y C Y Y Y Y Y Whitlock Y Y Y Y Y Y Y Y Result N C C C C Y C C Comments and decisions of /INTERP. F08/0128 Reinhold Bader I agree with the answers A1.- A3., except that in A1. "use associated" should be replaced by "use association". I disagree with the suggested edit, because it is too broad. Instead, I suggest the following: [275:9+] 11.2.3 Submodules, "A submodule shall not directly reference its ancestor module by use association. If a submodule indirectly references its ancestor module by use association, every USE statement in its body that causes such a reference shall specify an ONLY option. An entity in the for that option that is not a generic specifier or a renamed operator shall not be specified in the submodule's ancestor module. For an entity that is a generic specifier or a renamed operator, the referenced specific procedure (12.5.5.2) shall not be specified in the submodule's ancestor module." I'm hoping that this not only yields the same answers to the interp, but also permits compile-time checking of any violations, avoiding the complaint made by UTI 151 in 09-007. If this turns out to be unfixably wrong, I'm willing to change my vote to "yes". The rationale for the above suggestion is as follows: Imagine that S(A) is a submodule of A (the ancestor) and wants to access some other module {M} that may be a single module or the beginning of a use-chain of modules. Prior to the interp, the following dependencies are permitted, where (u) stands for use and (h) for host association: -(u)---->{M} / | / (u) / | / v S(A) --(h)---> A With the interp's original edit, the line connecting one (or more) of the modules in {M} and A causes the program to become non-conforming. The alternative edit permits the programmer to avoid this with minimal (if any) overhead. During the London meeting it was pointed out that the dependency could be avoided by restructuring the code and moving dependent parts to an auxiliary module. This is true, but it may involve writing significantly more code, and often also a submodule of the auxiliary module is needed. As a result, the global code structure becomes more difficult to understand. Furthermore, if A implements "core" concepts that many other modules might depend on (pushing code to S(A) wouldn't be needed otherwise), it may well happen that the critical use association M->A gets established later on in the development process, triggering a potentially large amount of code restructuring (multiple submodules could be affected in one fell stroke!). With the alternative edit, the only fallout is that ONLY clauses must be added in S(A) if they're not already there anyway. Robert Corbett Answer A1 states that the example was not intended to be conforming. Paper 09-141, which is cited in the discussion section, begins The prohibition against a submodule accessing or referencing its ancestor module by use association appears to have been wrong-headed in the first place. There appears to be no reason to keep it in any form. I did not attend the meeting during which paper 09-141 was approved, but I find it hard to believe that the committee could have passed that paper without intending to allow such usage. I see no technical objection to implementing the feature as it is currently specified. Paper 09-141 contains remarks to that effect. The comments Reinhold Bader included in his ballot convinced me that the feature is useful, and that its removal will put a burden on users. If the feature is retained, Q2 and Q3 need answers. My reading of the Fortran 2008 standard as written is that the answer to both questions is "yes". On a minor note, the line Note that the "submodule TR", Technical Report 19767 contains, an edit does not conform to the rules of punctuation of American English. In American English, the comma that terminates an appositive phrase appears at the end of the phrase, not after the following verb. Also, the appearance of quotation marks in that line would be considered misuse in American English. It implies that the term "submodule TR" has an unconventional meaning, which I do not think is the case here Erik Kruyt In the light of F08/0142 the examples are incorrect due to the augmented C1113. Change the module in the first example to e.g.: Module m1 Interface Module Subroutine mp1 End Subroutine End Interface Real x End Module Change the module in the second example to e.g.: Module m2 Interface Module Subroutine mp2 End Subroutine End Interface Real, Private :: a Real, Protected :: b ... End Module Van Snyder Upon reflection, I prefer an answer very similar to Option 1 in 15-208. A proposed revision is: {begin revision} DISCUSSION: The prohibition against a submodule accessing its ancestor module by use association 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: 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 accessed by use association (because it is PRIVATE and therefore not accessible by use association, according to the final sentence of the second paragraph of 5.3.2). Therefore, A can still be accessed by host association. An edit is provided to revise the referenced sentence to make it clear that the entity is accessible by use association but not host association, rather than being completely inaccessible. A3. No, the assignment to B is not conforming because, according to the first sentence of the second paragraph of subclause 16.5.1.4, it is accessed by use association, and therefore 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. EDITS: [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] Second paragraph of 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] First paragraph of 11.2.2 The USE statement and use association, 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 (5.3.15).". [443:36-37] Replace the first sentence of the second paragraph of 16.5.1.4 Host Association: "If an entity that is accessed by use association has the same nongeneric name as a host entity, the host entity is not accessed by host association by that name." {end revision} The questions are simplified and combined. I vacillated whether to change the edit for [100:12], viz. "where it is accessed by host association" to "where it is not accessed by use association" to try to make it clearer that construct association is not involved. Ultimately, I did not change it, because both versions might be perversely interpreted in that context. Perhaps some work is needed here. The edit for NOTE 11.7 is revised simply to draw attention to 5.3.15 to refer to it by number instead of repeating material therein. An edit is provided for [443:36-37] to revise the first sentence of the second paragraph of 16.5.1.4p2, to make it clear that the entity B is still accessible, albeit by use association: "If an entity that is accessed by use association has the same nongeneric name as a host entity, the host entity is not accessed by host association by that name." ("... the host entity is inaccessible by that name" could be perversely interpreted to mean the entity is entirely inaccessible by that name, i.e., neither by host nor use association. The problem is the word "entity.") This edit would also clarify the situation wherein a host scoping unit and an internal scoping unit also access the same entity by the same name by use association (no submodules involved). I hope this doesn't need another interp, something like module M1 real, public :: X = 66 end module M1 module M2 use M1, only: X contains subroutine S1 use M1, only: X implicit NONE X = 42 end subroutine S1 subroutine S2 use M1, only: X X = 42 end subroutine S2 subroutine S3 call S2 print *, X end subroutine S3 end module M2 program P use M2, only: S3 call S3 end program P Is the assignment to X in S1 conforming? Assuming the program conforms, what is printed by the PRINT statement in subroutine S3, i.e., is the assignment to X in S2 an assignment to the entity in M1, or is X a local entity in S2? According to 16.5.1.4p2, "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 could be interpreted to mean that the entity X is not accessible in S1 or S2, neither by use association nor by host association. Decision of /INTERP: Returned to J3 for further work. .................................................................... F08/0138 Daniel Chen I agree with David and Bill's comment. Bill Long In the Question, replace "C456 in 007r1 reads" by "C465 in 10-007r1 reads". {Fix typo in the constraint number, and be more precise about the document number - there have been lots of 007r1's.} David Muxworthy In the question, 'C456' should read 'C465'. Decision of /INTERP: Accept the suggested changes. .................................................................... F08/0139 Reinhold Bader I agree with Malcolm Cohen that inserting "containing the external subprograms" after the word "fragment" occurring at the beginning of the "QUESTION" section resolves an ambiguity. Daniel Chen I agree with Malcolm's extra edit. Robert Corbett The keywords "TRANSFER" and "zero-sized scalar" listed in the KEYWORDS line of the header are not appropriate for the topic of the interpretation. Erik Kruyt I agree with Bill Long that this needs a clearer example which illustrates the localness of the procedure name. Bill Long In the Question, replace "Consider the program fragment" by "Consider the program fragment containing the external subprograms". {Clarify that these subprograms could not be internal or module subprograms, with wording suggested by Malcolm Cohen. Alternatively, include a complete program as the example, such as: Subroutine s() Bind(C,Name='Hello') Print *,'Hello' End Subroutine Subroutine s() Bind(C,Name='World') Print *,'World' End Subroutine subroutine sub_hello () interface Subroutine s() Bind(C,Name='Hello') End Subroutine end interface call s() end subroutine sub_hello subroutine sub_world () interface Subroutine s() Bind(C,Name='World') End Subroutine end interface call s() end subroutine sub_world program test call sub_hello() call sub_world() end program test } Van Snyder Even though the title of the interp mentions "external procedure," I agree with Malcolm Cohen that inserting "containing the external subprograms" after the word "fragment" occurring at the beginning of the "QUESTION" section clarifies the question. Decision of /INTERP: Accept, subject to these changes: 1. Change keywords to "binding label, local identifier". 2. In the Question, replace "Consider the program fragment" by "Consider the program fragment containing the external subprograms". .................................................................... F08/0140 Bill Long At the end of Q2, add a line "Is the assignment permitted?" {Since Q2 is not currently an actual "question", the answer is a bit vague about what is "intended to be permitted".} Decision of /INTERP: Accept the suggested change. .................................................................... F08/0141 Bill Long The first Edit should be at [24:11+] (and not at [22:11+]). {And hence in the stated subclause. I assume previous changes have removed or modified the last sentence of the previous paragraph in 10-007r1 "Any standard-conforming Fortran 2003 ... 1539".} David Muxworthy The first edit should be at [24:11+]. John Reid The first edit is for [22:11+]. Decision of /INTERP: Accept the change suggested by Bill Long and David Muxworthy. .................................................................... F08/0143 Daniel Chen I agree with David and Bill's comment. Erik Kruyt The example is in error. Type(t), Intent(Out) x should read Type(t), Intent(Out) :: x Bill Long In the example code of the Question change Type(t),Intent(Out) x to Type(t),Intent(Out) :: x {Syntax rule R501. Agreeing with the comment of Erik Kruyt.} David Muxworthy I agree with John's comment. The interp should include the location of the edit in 10-007r1. John Reid The edit is for [312:23+] which is in Clause 12.7, para. 2. Decision of /INTERP: Accept the changes suggested. .................................................................... F08/0144 Daniel Chen I agree with Erik's comment. Robert Corbett The ANSWER section of the interp states It was intended that nonadvancing input/output not be permitted within a DO CONCURRENT construct. An edit is provided to address this oversight. However, the edit provided allows nonadvancing input/output within a DO CONCURRENT construct in the case of child data transfer statements. The final sentence of Subclause 9.6.2.4 of the Fortran 2008 standard states A formatted child data transfer statement is a nonadvancing input/output statement, and any ADVANCE= specifier is ignored. The answer might be changed to It was intended that nonchild nonadvancing input/output not be permitted within a DO CONCURRENT construct. for which the proposed edit is adequate. I prefer changing the edit to Nonadvancing input/output shall not occur (9.6.4.2) in the range of the loop. I included the subclause citation, because the word "occur" is used in the sense specified in that subclause, not in its conventional sense. I would not object to removing the citation. Erik Kruyt The first WRITE statement with ADVANCE= in the example is (already) not conforming due to C922. Change the list-directed format specification to an explicit one, e.g. write ( *, '(I5)', advance='NO' ) I Bill Long In program P for Q1, replace write ( *, *, advance='NO' ) I by write ( *, '(I5)', advance='NO' ) I {Constraint C922 requires an "explicit format specification". Recommending the alternate version suggested by Erik Kruyt.} David Muxworthy I agree with Erik's comment. Decision of /INTERP: 1. Accept the change suggested by Erik Kruyt and three others: In program P for Q1, replace write ( *, *, advance='NO' ) I by write ( *, '(I5)', advance='NO' ) I 2. In response to the comment of Robert Corbett, make these changes: a. In the title, change "nonadvancing I/O" to "ADVANCE=". b. Change the second paragraph of the answer to "It was intended that the ADVANCE= specifier not be permitted within a DO CONCURRENT construct." Reason: J3 debated the approach suggested by Robert Corbett and chose instead the compile-time-detectable requirement for ADVANCE= not to appear. The changes to the answer make it consistent with the edit. Defined input/output needs its own proper fix, which need not have any connection to the fix for "normal" nonadvancing input/output.