J3/15-184 To: J3 From: Malcolm Cohen Subject: Editor's report for 15-007r1 Date: 2015 July 15 1. Introduction This is the editor's report for applying the papers passed at meeting 206 to the draft revision. 2. List of papers applied. Papers done completely: 15-106r1, 15-110r4, 15-112r4, 15-113r3, 15-115r1, 15-137r1, 15-140r1, 15-154, 15-155. Paper 15-119r2 was mostly rejected. The feature chosen to incorporate from the draft TS was the extra atomic subroutines. REJECTED COMPLETELY 15-119r1aa 3. Unresolved Technical Issues UTI 005, 010, and 011 were deleted as being resolved. UTI 008 remains. A new UTI 012 was added. 4. Detailed Report 15-154. REJECTED [64:29] 4.5.2.2 Accessibility, p1, insert after the first sentence: "An on the specifies the accessibility of the type name." This edit is wrong, since sentence 1 and the inserted sentence are partly contradictory. ACTION: Try again to work out how this should be done. Either completely reword the first sentence, or better, insert the second sentence into 5.5.2 so it does not contradict 5.5.2. [various] Index "unordered segments"; I made the entry at 190:28-29 bold as well as 190:25 (it's the same page anyway, so non-bold = 2 entries). REJECTED indexing at 496:35 and 497:13, as these are in Annex A which is not normative and is only repeating info from elsewhere. COMMENT: Not sure why we sometimes (frequently) say "blah termination of execution" instead of just "blah termination"; we should make this more consistent, preferably by deleting "of execution" everywhere except in 2.2.whatever. EXTRA EDIT: [34:12] "normal termination" changed bold indexing to nonbold, because this is a use of normal termination not a defn. [34:12-13] After "initiates normal termination" deleted "of the image" because: unnecessary wording. COMMENT: NOTE 8.27 seems unnecessarily vague. COMMENT: "termination of the BLOCK construct"... should this not be "completion of the BLOCK construct"? ditto "termination of the construct"? maybe also "termination of the loop"? (and "terminated"?) similarly "termination of execution" of an i/o stmt. EXTRA EDIT: Indexed the DT edit descriptor. EXTRA EDIT: Indexed the RU, RD, RZ, RN, RC, RP & "round" edit descriptors. EXTRA EDIT: Indexed the DC, DP and "decimal" edit descriptors. EXTRA EDIT: Indexed the "character string" edit descriptor. EXTRA EDIT: Changed the "control edit descriptor" indexing to a range. EXTRA EDIT: "10.8.1 Position editing" -> "10.8.1 Position edit descriptors 10.8.1.1 Position editing" to fix ISO directive nonconformance; changed the reference in clause 9 in the note just before "File storage units" to refer to the new 10.8.1, the other references in clause 10 "Positioning by format control" and Annex A are unchanged so automatically follow 10.8.1.1 now and this seems correct. COMMENT: The opening material in 10.8.1 (now 10.8.1.1) is partially duplicative of the material in 10.8.1.1 and 10.8.1.2 (now 10.8.1.2 and 10.8.1.3). COMMENT: Should NOTE 10.23 not be in the "X editing" subclause? Or just deleted entirely? COMMENT: "The character string edit descriptors provide constant data to be output, and are not valid for input" should be singular and indefinite (singular because we deleted the H edit descriptor). Similarly, in the next paragraph, "except for the characters in the character constants" ->"except for characters in a character constant", or even more simply "except within a character constant". 15-110r4. [24:24-25 1.5p4] Also deleted "is" before "has". [104:8-9 5.5.13p2] Used the first variation "; it may be ...". 15-112r4. [347:34-36] and [347:37-39]: EXTRA EDIT: "this sample" -> "this example". [356:17+] inserted "on a processor that supports command retrieval". [356:43] "The" -> "On a processor that supports command arguments, the". EXTRA EDIT: Indented code 7 spaces. [357:35+] joined code lines instead of using continuation marker. [379:30] Fitted on one line by changing "the value of TO after" -> "its value after". [392:2-] "the result of" -> "the value of", and inserted "the value of" after "and". Deleted UTI 011 as I agree it has been resolved. 15-113r3. [454:1-6] ADDITIONAL: Hyperlinked various terms here and in environs. Note that I hyperlinked "actual argument" when it was talking about the Fortran term, and not when it was the C term since that would be wrong. NEW UTI: Read paragraph 4 whilst hyperlinking and discovered this was equally as bad as paragraph 5 used to be. It requires a total rewrite, not trivial, so added UTI 012. [454:6+1-7] Deleted UTI 005 as this part seems ok. [455:1-] "the Fortran standard" -> "this part of ISO/IEC 1539". 15-115r1. Done without modification. 15-119r2. REJECTED (initially), because - Stringing together if-clauses with otherwise, especially in a single sentence, is hard to read and obscures the fact that these were intended to be disjoint categories (if they are not disjoint that is a different problem for which this paper is not an acceptable fix). - We should not say "Fortran intrinsic type" in the Fortran standard, unless if would be ambiguous or confusing otherwise, and since there is no C concept called "intrinsic type", that would seem to be highly unlikely to be the case. - These edits appear to be making technical changes; if that is unintentional, they are simply wrong, and if intentional, we need them to be called out as Technical Changes and they need to go into the Introduction for the benefit of people using the Interoperability TS. - I appreciate that this text is quite difficult to read as is... and in fact it is already completely wrong and needs to be rewritten from scratch, see UTI 012. - This appears to be adding permission for a standard-conforming program to use a non-standard-conforming feature (viz non-standard values for the type codes). That is not acceptable, and not the way we do things. For example, a standard-conforming processor may provide additional intrinsic functions, but a standard-conforming program is not permitted to use them. SECOND ATTEMPT: [463:7-8] The insertion is ambiguous. Here we are in the middle of a sequence of "If base_addr [condition], then [something]". And this is inserting a requirement. Is this intended to apply to all the "If base_addr [condition]" cases? Or just the immediately preceding one? If all, then it is misplaced as well as ambiguous. The Description probably needs to be split into three cases for base_addr, with a separate paragraph for the common stuff... ...and the claim "the value of \cf{elem_len} is supplied by the processor" seems to be wrong; \cf{elem_len} is a formal parameter whose value is supplied by the user. [465:18-28,44] seems ok, applied. [466:4] seems ok. [Annex A] "in source file" -> "in the source file". Deleted "the order and set of the". The last two additions to this list do not seem right, in fact we have them both already, and better-specified already, and more besides. NOTE: All edits not listed above were rejected. 15-140r1. [386:29] inserted missing "that" before "would be set". Deleted UTI 010 as this now seems ok. 15-106r1. Done without modification. 15-137r1. [global] Actually on further investigation the problem was down to the use of (the default) OT1 font encoding instead of T1. Changed the encoding and also the font (the T1 version of "Computer Modern" is very different and hard to read), to "Latin Modern". This is expected to make minor changes to layout etc., but looks almost the same as before. 15-155, part 1. Done without modification. 15-155 part 2, atomics, *except EVENT_QUERY*. [intro] Rewrote inserted sentence about STAT arguments (for ATOMIC_DEFINE et al) to use the correct verb tense, and to actually mention that the argument is called STAT. "The additional atomic" -> "The new intrinsic", "perform integer blah" -> "perform atomic operations" (we don't need to be more detailed here). [13.1] Modified text to omit the EVENT argument possibility (for now). Deleted "by different images" since "unordered segments" REQUIRES different images! "on the same atomic object" -> "whose ATOM argument is the same object" (we do not *have* "atomic objects"). Deleted "in a single segment ... in the other.", as I cannot work out what it is trying to say; instead "performed completely before the other begins" (I *think* this is what it is trying to get at). "indeterminate" -> "processor dependent". "Which is executed"->"Which execution is performed" (consistency). I left "The sequence ... is specified ...", even though it was, and is, completely unnecessary. "updated" -> "redefined" (that is Fortran terminology!) and "the changes to them are observed by atomic accesses from" ->"they are referenced atomically in" (ditto). Indexed use of "segment". Actually, completely rewrote this as it was horrible (should not use P1 and P2 to mean possibly on different images and possibly unordered!) COMMENT: I don't like "observe", but wordsmithing needs to stop sometime. "For invocation..." this paragraph is completely counterfactual. ATOMIC_REF does not evaluate ATOM atomically? News to me. Rewrote to try to get it right. Probably failed. Folded the result back into the previous paragraph where it belongs, and split the resultant paragraph there. Also rewrote the STAT stuff to be simpler. This will get more complicated again once failed images are added. Rewrote the advertising spiel in the note. SUGGESTION: Delete "the effect is as if" (we are ALWAYS describing semantics, not prescribing implementation techniques!). Moved the atomic subroutine general semantic descriptions into a new subclause 13.5. Deleted "operation" from all the brief descriptions (we do not use this term for any other "operation"). In every STAT argument paragraph, added "It is assigned a value as specified in 13.5." since it is unacceptable to force the reader to grovel through the standard to find the semantics. Added "If an error condition occurs and STAT is not present, error termination is initiated." for the same reason. In ATOMIC_REF, inserted a modified sentence about VALUE becoming undefined into the *VALUE* paragraph! In ATOMIC_DEFINE, inserted a sentence about ATOM becoming undefined... in fact just rewrote it from scratch. Otherwise we have a contradiction! Ditto ATOMIC_REF. Including changing a stray "is defined" to "becomes defined". In both cases, removed the spurious and unnecessary references to the INT intrinsic. Also changed "its type is" to the normal "it is of type". ATOMIC_ADD, changed "ATOMIC_INT_KIND is a" to "...the". I don't know what the thinking behind ATOM+INT(VALUE,...) is, but it does do anything useful. Using INT on an out-of-range VALUE is not conforming, nor does it stop the result from being out of range either. Thus the program will be nonconforming if either VALUE or ATOM+VALUE is not representable in ATOMIC_INT_KIND. So I added these as explicit requirements rather than forcing users to prove theorems via clause 1. It might be argued that we could allow the result in the nonrepresentable cases be that ATOM becomes undefined, or even have a processor-dependent value. However, such a case would almost certainly be a user error, so I think the current definition, allowing the processor to detect that error, is good. I just preferred to have the requirement explicit. Reworded the example sentence for grammar. ATOMIC_CAS. Type logical values are equivalent, not equal. But we don't need to say "value of", so "ATOM is of type integer and equal to COMPARE, or of type logical and equivalent to COMPARE,". "a scalar of the same" -> "scalar and of the same". "It is defined" -> "It becomes defined". Or "is assigned" would be ok. "of ATOM that was used for performing" -> "that ATOM had at the start of". "Z"->"0". Rewrote example into two parts to illustrate the effects when the comparison fails and when the comparison succeeds. In all the atomics so far, "and of type" -> ". It shall be of type" (simplify grammar). Rewrote some of the Annex C guff. Deleted "or undefined", since using undefined semantics makes the program not Fortran. Rewrote substantially in fact. The results are not "unexpected" by anyone who has read about it... Rewrote the unacceptable wording "guaranteed by the standard", and also "It is likely" and "anomalous behaviour", since the former is explicitly forbidden by ISO, the second turns the whole discussion into pointless speculation, and the third is a poor characterisation of behaviour that a number of people expect to be possible. Omitted Example 3 since collective subroutines have not (yet) been added to the standard. ===END===