09-239 To: J3 From: Malcolm Cohen Subject: Editor's report for 09-007r2 Date: 2009 June 22 1. Introduction --------------- This document describes the changes between 09-007r1 and 09-007r2, and in particular the differences between the edits passed at meeting 188 and the edits actually applied to the 007 document. All the previous UTIs have been resolved, but paper 09-167r2 generated 2 new UTIs, and 09-199 generated 1 new UTI. Papers 09-174r1, 09-186r3 and 09-224r4 were rejected. These all seemed to need some more work; we have one more meeting, so rather than insert something wrong plus UTIs it seemed better to send them back to the committee for revision. Finally, I have changed the hyperlinks to ordinary black text the same as everything else. Anyone who wishes to have them in a different colour can build their own version from the LaTeX sources. Note also that the next version of the document will have line numbers turned off. 2. Papers entered with no changes or comments --------------------------------------------- 09-160 09-201r1 09-162 09-203r1 09-165 09-206 09-169r1 09-214r1 09-170r2 09-216r1 09-175r1 09-220r1 09-183r1 09-227r1 09-190r3 09-229 09-198r2 09-232 09-200r1 3. Papers with changes or comments ---------------------------------- 09-158 Deleted UTI 164. 09-161r3 Also singularised sentence at [464:3]. 09-163r1 Added a comma at the end of the insertion. 09-164r2 [450:20+,32+] "BLOCK statement is executed"->"BLOCK construct is entered", twice; execution of a BLOCK construct does not execute the BLOCK statement. [451:22,34] "the object"->"this object", twice, as per the original text and consistent with every other reference in the subclause. [452:25+] Inserted blank between "" and "is". 09-167r2 [11:7-8] This sentence is convoluted and easy to misread: inserted "of" between ", or" and "a dummy procedure" to help avoid that. [161:33-35] Deleted reference to 12.5.2.9, because I cannot see any relevance to the issue at hand: p161 is procedure pointer assignment, and 12.5.2.9 is dummy procedure argument association - which sheds no light on procedure pointer assignment, it's just another use of host instance. Indexed "host instance" as a reference instead of a definition (the definition being in c01). Actually the sentence in the edit is ungrammatical - "becomes" vs. "is". I don't know what the intention was here (whether "becomes" or "is" was the intention), but rather than add a new UTI I just discarded the suggested new sentence and put in one of my own. Someone really ought to check this. [300:2-5] Deleted reference to 7.2.2.4 because it seems totally irrelevant: 7.2.2.4 is procedure pointer assignment - which sheds no light on dummy procedure argument association, it is just another use of "host instance". [311:24] I did this, but I suspect that "All other entities" ought to be written "Saved data objects". And I suspect that in the previous sentence "local unsaved data objects" should be "unsaved local variables". ***THIS NEEDS REVISION***. [311:24+] Resorted the list to put statement functions at the back. And no way do I make single commas obsolescent! "The main program or an external subprogram" ->"A main program or external subprogram". What's a submodule procedure? And submodules also define module procedures, contradicting the earlier sentence? [Not an edit] Note 12.46 seems superfluous and incomplete, but is worded as if it is complete. ***THIS NEEDS REVISION***. UTI 165 added for the "submodule procedure" question plus all the other things that look like they need revision. [456:3-7] "containing scoping unit"->"host scoping unit". In this case the host scoping unit will indeed inevitably be the containing one, but we almost never use the phrase "containing scoping unit" anywhere else (I only found it in Annex C) and the previous wording used "host", so I think it is better. Specifying the associating entity seems only to be done correctly for one of the three cases, unless I am mistaken. For that matter, the same comment applies to host instance. UTI 166 added for the incompleteness of this definition. 09-168r2 [402:12+] Inserted an indefinite article before "reference". 09-179r2 Corrected verb forms and deleted the spurious conjunction/prepositions. 09-187r2 i112 and i122 only i112: Fixed typo "POINTER of"->"POINTER or". Rewrote entire witter from scratch because (a) it seemed awkwardly phrased (in particular, some expressions can have the POINTER attribute, it is just that ones enclosed in parentheses cannot), (b) in F2008 it also needed to mention TARGET. 09-193r2 Done with no changes, though the second edit could have omitted the "with an ACQUIRED_LOCK= specifier" without loss of comprehensibility (possibly easier to read actually). And maybe it ought to say something like "If a lock variable becomes unlocked by execution of an UNLOCK statement on image M, and later becomes locked by execution of a LOCK statement on image T, the segments preceding the UNLOCK statement on image M also precede the segments following the LOCK statement on image T." i.e. reword to be lock-focussed instead of image-focussed. I don't particularly like the "is the next to execute" wording either. 09-199r2 Please count lines within examples in future, so that we can identify the location of edits more unambiguously. [190:23+] "may"->"can" (even if you want to give permission, this is not normative text so you cannot). "calls of"->"calls to". [190:23+] "An execution"->"Execution". This inserted sentence seems to be wrong. Added UTI 167. 09-208r2 [73:12,14] Also made the BNF rules into single lines (the continuation was unnecessary). I also did this for GENERIC which was on the same page. 09-225r1 [155:11-26] Left the list as a numbered list, because the ordering is important. (The list is still too long and complicated, even though it is better than before.) 09-226 [220:13-15] "user-defined derived-type input/output" ->"defined input/output". 09-228r2 [130:15] "implicit"->"an implicit". [133:15] ditto. 09-230r1 [37:14] Already done by 09-169r1. [518:38-519:23] Also fixed error in program: the second function had its type declared in the FUNCTION statement as well as in the body. [535:Annex title] I did this, but I think it would be an improvement to go back to the previous version. There is no real need to have the annex title mention "and constraints" as long as the D.1 title does. 4. Rejected papers ------------------ 09-174r1 REJECTED. The edits in this paper are mostly good, but... there are some missing ones at the very least. [286:13-15] The final sentence ought to be deleted - after making a defined operation a function reference, and the operands into actual arguments, we don't want to say that things apply to the operands "as if they were actual arguments" because they already *ARE* actual arguments. [286:16-17] The opening sentence here duplicates the [286:10] insertion, only wrongly. Instead of the [286:10] insertion, this sentence ought to be modified. That is as far as I got before deciding that the fixes required to this paper exceeded my editorial licence, other glitches might exist. 09-186r2aa REJECTED. As with the other rejections, this paper contains valuable improvements that need to be done to the standard, but has flaws the fixing of which exceed my perceived editorial licence. In [189:18] the reference should be omitted since it is the very next subclause at this level, just two paragraphs later. In [192:5-6], the resulting sentence makes no sense whatsoever. I cannot decide what the best fix is: obvious ones are - break into two sentences and reword the start of the second so it says something like "These two segments" instead of "each of which"; - reword the new text to be more like the text in the [189:18] edit, e.g. "Execution of a SYNC MEMORY statement ends the current segment and begins a new segment; these two segments ...". The first option does keep the objectionable idea that the SYNC MEMORY statement "defines" the boundary - it does not, it is execution of the statement that divides the execution sequence, otherwise what do we make of "IF (condition) SYNC MEMORY". Please Do Not Use The Verb "define" like this, we have enough variation of meaning for that term already. 09-224r3aa REJECTED. Sorry, this is too unpolished. [171:20] Also needs "of control" into the sentence after so that we don't start wittering about "transfers" without at least first using "transfer of control". We don't need all these cross-references to 8.2, branching is a simple context, appears in the TOC and the index, ... [178:20-23] The existing text is already correct, this change might still be correct but it is actually harder to understand. Furthermore, these occurrences of "transfer of control" are correctly not indexed; they are not saying anything interesting about "transfer of control". So even if the edit were to be done, it should not be indexed. [178:22] I will defer to the committee, but I think this edit is totally pointless; throughout the whole standard we say that things happen without saying "oh, but not if the program stops executing in the middle of it". If it's a problem here, I think it is a problem in many places. [188:3-4] "that is labeled by"->"denoted by". The second sentence has a terminal case of commaitis; the commas don't aid parsing, they encourage one to read things like "When a branch occurs in the same scoping unit". I don't see why a branch is not a transfer of control; if it is one, then the existing text saying that should be preserved. The supposed definition doesn't say what a branch is, it says what happens when it "occurs". Since that implies that a branch is an action (not a piece of syntax) that means that it doesn't have any labels in it. And in any case the syntax usually has more than one label so speaking of "the label" is just wrong. Since labels are scoped symbols, after using "denotes" we can drop the stuff about "in the same scoping unit" as that goes without saying. [188:7] Pointless change that avoids "transfer of control" by describing it instead. This does not seem to be an improvement, especially since we describe procedure references in terms of transfer of control - so why Not use the same words here like we always did? [188:16-17] This edit looks fine. [188:23] Looks good but I didn't read the result carefully. [188:31-32] Only the first "Replace" seems to be necessary. [313:29-30] Seems ok. Notes: (1) If CYCLE and EXIT are not to be considered branches (I consider them to be branches, but it loks like the original author of this paper did not) then the extra constraint introduced by 09-228r2 will need extra complication. (2) I would really like subgroup to be *even more modest* when I see the revised version of this paper. ===END===