To: J3 Members J3/16-260 From: Van Snyder Subject: Comments on Clause 9 References: 16-007r2 Date: 2016 September 28 1. Edits -------- [130:4 9.3p1] A reference to a named constant is not permitted if its name is not accessible. Insert "literal" before "constant". Replace "; redefinition" with ". A reference to a named constant is permitted if its name is accessible. Redefinition". [131:27 9.4.2p6] Sentence doesn't allow host association. Replace "A ... base object" with "If a structure component is referenced or defined, the declaration of the base object shall appear before the reference or definition, or be accessible by use or host association." There is no statement in 19.5.1.4 comparable to the last sentence of 14.2.2p2, viz. "A use-associated entity is considered to have been previously defined." {"use or" could be left out because Clause 14 says that, but Clause 19 doesn't say that host association implies previous definition or declaration.} [131:28 9.4.2p6] Attributes are not defined. Replace "is defined to have" with "has". {or "is declared to have" but that's more wordy than necessary.} [132:19 9.4.5p2] Before "shall not" insert "is undefined and therefore". [133:0+7 NOTE 9.8] The inquiry "b(10)%kind" is not about an array element. According to NOTE 9.7 (which I presume is supported by normative text somewhere), the inquiry "b%kind" would not be an array. The inquiry "b(10)%kind" is an inquiry about a scalar property of the base object, no matter whether it's a scalar or an array. The comment is misleading. Replace with it "Inquiry about the kind of b". [139:26-27 C945] For consistency with the style of C936, replace "The" with "If an is a coarray, the". After "ISO_C_BINDING" delete "if an is a coarray". [141:39 9.7.1.3p4] After "unsaved" insert "allocatable". Nonallocatable variables have neither allocated nor unallocated allocation status. [142:2 9.7.1.3p5] Replace "created" with "allocated". [142:5-7 9.7.1.3p6] Replace "evaluation" with "execution". After each "allocation status" insert "or pointer association status". Then move the paragraph to [141:19+ 9.7.1.2p9+] because it applies equally well to allocatable and pointer variables. [142:30+2 NOTE 9.21] Append a sentence "When an array pointer is undefined, its bounds are undefined. When a pointer that has deferred length type parameters is undefined, the values of those type parameters are undefined." {I think this is normative somewhere -- maybe Clause 19. If not, it needs to be.} [144:3-4 9.7.3.2p10] Before "those images" insert "each of". After "occurs" insert "on that image". {Otherwise images that stop or fail during the deallocation are required to participate in the synchronization.} [144:12+8 NOTE 9.23] Replace "will be" with "is". [144:12+8 NOTE 9.24] Replace "For example, executing" with "Executing" because the note isn't an example about anything discussed nearby. [144:27-28 9.7.4p3] Replace "one or more images" with "any image of the current team". [145:20 9.7.5p2] Replace "an error condition occurs" with "a nonzero value is assigned to a STAT= variable". After "statement" insert ", or would be assigned if it appeared," because STAT_STOPPED_IMAGE and STAT_FAILED_IMAGE are not error conditions. Presumably, we want a message even in those cases. 2. TEAM_NUMBER -------------- Since Fortran 90, processors have been able to do generic resolution. [137:20 R926] doesn't need two keywords. The distinction between and is obvious, and good enough. [137:20] Replace "TEAM_NUMBER" with "TEAM". [137:22 C928] Delete C928 because it's no longer necessary. [137:28 9.6p3] Insert "" after "TEAM=". [137:30 9.6p3] Replace "TEAM_NUMBER=" with "TEAM=<". 3. Question without edits ------------------------- [131:10 C915] Why is a section subscript list required if an image selector appears? Does this prevent some kind of subtle problem, or does it simply remove a syntactic ambiguity? [136:11 9.5.4p1] Is the third list element different from the first one?