To: J3 Members J3/16-203r2 From: Van Snyder & Steve Lionel Subject: Comments on clause 7 References: 16-007r1 Date: 2016 June 09 1. Edits Accepted by JOR ======================== [146:16+1-3 NOTE 7.14] Remove the text about INT as it is not relevant and move the note to after Table 7.2. The note should now read: "For example, if X is of type real and J is of type integer, the expression X + J is of type real." [149:7 7.1.5.3p3] Replace "//" with "$x_1 // $x_2" as otherwise one is left to infer that these are the same operands as in p2. [152:41 7.1.6.1p5(5)(a)] After "$d_2$" insert ", respectively", which is apparently necessary in other list items. [154:31 7.1.9.2p1] Before "types" insert "declared". Dynamic types do not participate in generic resolution. [155:38-39 7.1.9.3p4#6] Before the second "expression" insert "kind type parameter of the". Replace "has the" with "is". After "logical" delete "kind type parameter". The sentence now reads: "For an expression x1 op x2 where op is a relational intrinsic operator, the kind type parameter of the expression is default logical." This is consistent with other usage. [156:14 7.1.11p2(4)] Make "use" a hyperlink to 1.3.8.9 (use association) as "host" is already linked. The editor is also requested to generally improve vertical spacing at the bottom of tables. (Table 7.9 at 161:8+7 is an example.) 2. Edits Rejected by JOR, with comments ======================================= [146:16+1-3 NOTE 7.14] NOTE 7.14 begins "For example," but appears not to be an example of any nearby normative text. Delete NOTE 7.14. This note was added in F2008, but JOR can't find any trace of a paper that prompted it. While JOR agrees that the reference to INT seems out of place, the note about the type of X+J is absolutely an example of the table immediately following. [147:16 7.1.5.2.3p1] Replace "In the case of" with "Where" (or "If") and insert "is" before "raised". The standard uses this phrasing in many other places. [149:7-8 7.1.5.3.1p3] "//" is not an operation; it's an operator. Which operand is concatenated on the left and which on the right is ambiguous. Replace "//" with $x_1 // $x_2", insert "on the left" before "concatenated", and move "on the right" to be before "and whose length". Other than replacing "//", JOR doesn't find the rest of the text ambiguous and recommends no other edit. [151:4 7.1.5.5.1p4] It's interpretation of operations, not operators, that's given in Table 7.7. Replace "operators" with "operations". Similar use in Table 7.5. we think it is clear what is meant here. Simply replacing the word doesn't help any. If the interpretation of the operator was separated from that of the operation, as in 7.1.5.4.1, it might be a tiny bit better but would be unnecessarily verbose. [155:25,29 7.1.9.3p4#4] Replace "In the case where" with "Where" (or "If") twice. See 147:16 comment. [155:35-36 7.1.9.3p4#5] Replace "In the case where" with "Where" (or "If"). See 147:16 comment. [155:41 7.1.9.4p2] Replace "In the case where" with "Where" (or "If"). See 147:16 comment. [156:14 7.1.11p2(4)] After "use" insert "(11.2.2)". After "host" insert "(16.5.1.4)". The hyperlink for "host" gives that reference, but an edit to hyperlink "use" is proposed above. [159:5 C714] C714 is incomplete. We cannot allow a section of an assumed-size array in which the final section subscript ends with a colon. After "array" insert "or be a designator of a reference to an assumed-size array in whicn the final section subscript ends with a colon". Already prohibited by C627. [159:22-24 7.2.1.2p1(8)] The use of "corresponding" appears to refer to when it should refer to . Replace the item: "(8) If the variable is of derived type each nondeferred length type parameter of the variable shall have the same value as the corresponding type parameter of , and if the variable is not allocatable or is a coarray, each length type parameter of the variable shall have the same value as the corresponding type parameter of ." This is not an improvement and is a technical change (by adding "nondeferred"). Disagree regarding the use of "corresponding". [165:22 7.2.2.3p3] Replace "dynamic" with "declared". 4.5.7.1p1 specifies that a BIND or SEQUENCE type is not extensible. Plenary discussion indicates that this edit would be incorrect as it does not account for CLASS(*) [166:23 7.2.2.4p6] Before "corresponding" insert "each". Replace "parameters" with "parameter of the pointer object and pointer target". This doesn't add value. [170:34,35,39,40 7.2.4.2.4p2-3] After "order" insert "or simultaneously" four times. This doesn't add value. 3. Questions without edits ========================== JOR did not investigate these. [140:7 C704] Why is a not allowed to be spelt like an intrinsic unary operator? [142:19 C705] Why is a not allowed to be spelt like an intrinsic binary operator? [156:17-18 7.1.11p2(6)] In light of 7.1.11p2(4), is this item necessary? An inner BLOCK construct accesses an outer one by host association. [157:5-8 7.1.11p7] Is there a problem here if a type definition that appears before a specification expression involves a forward reference to a type that is defined after a specification expression that uses an entity of the first type? [162:20 7.2.1.3p13(2) 162:23+8 NOTE 7.41 163:11 7.2.1.4p2(2)(b)] Why are components assigned using defined assignment only if the defined assignment is bound to the type? There was no mention of incompatibility between Fortran 95 (wherein nonpointer components were assigned using intrinsic assignment) and Fortran 2003 (wherein nonpointer components were assigned using type-bound defined assignment). [165:34-35 7.2.2.3p9] Was the requirement that the target be contiguous or of rank one once a constraint? Whether it once was or not, why isn't it one now? [171:4 7.2.4.2.4p4] This appears to prohibit a defined assignment from doing the assignment. [171:25-26 7.2.4.4p2] Should be a constraint.