To: J3 Members J3/17-112r1 From: Van Snyder & Malcolm Cohen Subject: Comments on Clause 14 References: 17-007 Date: 2017 February 13 1. Introduction and discussion (1) In subclause 14.2.2 The USE statement and use association, constraint C1410 "Each use-name shall be the name of a public entity in the module." is limited in effect to R1413 only-use-name, however, use-name also appears in R1411 rename. Obviously this requirement should also apply to R1411 (the other case of R1411 requires use-defined-operator to be a public entity. Comment: We attack this requirement in a very piecemeal fashion, with separate constraints for use-name, use-defined-operator, and generic-spec. Replacing all of them with a single constraint with more robust wording would seem to be appropriate. (2) In R1411 rename, use-name needs to include both generic and nongeneric names (and it does, because without further constraint, "name" does include both). However, in R1412 only, use-name needs to exclude generic names because generic names are already included via generic-spec. That is, as currently written, there is an ambiguous parse for generic names in ONLY clauses. This needs to be fixed. (3) There is a lot of blather about things being public entities of modules. This is misguided and unhelpful; it is the identifiers that are PUBLIC (or not). (4) Paragraph 11 is a continuation of the subject of paragraph 9 (entities imported from another module), and paragraph 10 is unrelated. (5) Somewhat more seriously, paragaph 11 is unchanged from Fortran 2008, and so does not take into account " ", so it needs significant modification anyway. (6) On closer examination, paragraph 11 is unnecessary because the effects of PUBLIC and PRIVATE are described in the Accessibility attribute and statement subclauses. Indeed, there is no discussion of what they do for anything other than entities accessed by use association. This should be deleted. (7) The note in 8.6.1 Accessibility statement, for the module name feature, has a mistake in a comment. We are not re-exporting our own procedures, we are only exporting them. (8) NOTE 14.12 is confused as to whether the USE statement is providing access (first example), or making accessible (other examples). It is never making anything accessible, it s always providing access. The problem with saying it "makes accessible", is that this is what PUBLIC does... 2. Edits to 17-007 [114:8+11] 8.6.1 Accessibility statement, NOTE 8.26, After "re-export m_type and" insert "export", making that comment read: "! We want to use the types and procedures in m1, but we only want to ! re-export m_type from m1, and export our own procedures." {Repair defective comment.} [297:19-20] 14.2.2 The USE statement and use association, C1409 C1409 "Each ..." and C1410 "Each ...", replace both constraints with the following: "C1409 Each , , and in a USE statement shall be a public identifier of the module." {New constraint to cover all the cases at once.} [297:20+] Same subclause, add new constraint "C1410 An shall be a nongeneric name." {Remove parsing ambiguity.} [297:25] Same subclause, C1411 "Each use-defined-operator..." delete entire constraint. {Subsumed into new constraint.} [297:20 C1410] Constraint C1410 ought to apply both to R1411 and R1413. Insert "R1411" before "R1413", using either blank or comma for a separator. [298:22-25] Same subclause, paragraph 11 "The appearance of such a...", Delete whole paragraph. [299:0+2-4] Same subclause, NOTE 14.12, Change "makes all public entities in both MATH_LIB and STATS_LIB accessible. If MATH_LIB contains an entity called PROD, it is accessible by its own name while the entity PROD of STATS_LIB is accessible by the name SPROD." to "provides access to all public identifiers in both MATH_LIB and STATS_LIB. If MATH_LIB contains an entity named PROD, it can be accessed by that name, while the entity PROD of STATS_LIB can be accessed by the name SPROD." {Don't confuse providing access with making accessible. Change "its own name" to "that name" for simplicity. Disentangle "entities" and "identifiers".} [299:0+6] Same subclause, same NOTE, Change "makes public entities YPROD and PROD in STATS_LIB accessible." to "provides access to YPROD and PROD in STAT_LIB." {Don't confuse providing access with making accessible. No need to mention that YPROD and PROD must be public identifiers of STAT_LIB.} [299:0+8] Same subclause, same NOTE, Change "makes all public entities in STATS_LIB accessible." to "provides access to all public identifiers in STAT_LIB." {Don't confuse. "entities"->"identifiers".} 3. Rejected edits [295:16 14.1p3] Replace the paragraph with a note: "NOTE 14.2a It is impossible for a reference to a Fortran main program to appear in any program unit, including itself." RESPONSE: It is not impossible, just not standard-conforming. We rejected this last meeting as well. 4. Question without edit C1406 prohibits a scoping unit to access both nonintrinsic and intrinsic modules of the same name. Is it permitted or prohibited for a nonintrinsic module to access an intrinsic module of the same name as itself? Of the three processors I have, two prohibit it, and one allows it. Either a constraint to prohibit it, or a note to remark it is allowed (or not prohibited), seems to be needed. Does this need an interp? ANSWER: The described scenario violates the scoping rules, as the name of an intrinsic module is a local entity of class (1), and therefore forbidden from appearing in a scoping unit which uses the same name as a global identifier. ===END===